MTU Issue

Of the connection faults, this is the one most often misdiagnosed, because every early signal says the configuration is correct. The hostname resolves, the port opens, the certificate validates, the credentials are accepted, and the group list may download without trouble. The failure waits for the first large response, so readers tend to suspect the provider or their own account long after both have been proven fine.

The stall has a recognizable shape

Small NNTP exchanges are a few hundred bytes and fit inside any packet size, so commands and responses complete normally. An article body arrives in full-sized packets. When those exceed what some link along the path will carry, they are dropped; the sender waits, retransmits the same oversized packet, and waits again. The result is a download sitting at zero bytes per second with connections still shown as active and connected. A transfer that starts fast and gradually slows is a different problem entirely, because an MTU fault never transfers bulk data at all.

Why nothing reports the drop

The mechanism designed to handle this, path MTU discovery, depends on a control message traveling back to the sender to say the packet was too large. A great many firewalls and access routers block those messages indiscriminately, so the notification never arrives and the sender never learns to send anything smaller. That is why the fault presents as a silent hang rather than an error: the protocol's own diagnostic has been filtered out of the path.

Links where this appears

Anything that adds encapsulation overhead. PPPoE on DSL reduces the usable size to 1492 bytes against the Ethernet default of 1500. VPN tunnels take considerably more, commonly leaving something in the 1400s or lower depending on the protocol in use. Mobile tethering and satellite links vary as well. The classic history is a setup that worked on one connection and stalls on another after a VPN was enabled, a router was replaced, or the service moved to a different access technology.

Finding a size that works

1. If a VPN is active, disable it briefly. A transfer that runs normally without the tunnel and hangs with it confirms the diagnosis in one step.
2. Set the MTU on the router's WAN interface where possible rather than per device, so everything on the network benefits. 1492 is the correct value on most PPPoE links.
3. Where a VPN client exposes an MTU setting, lower it in steps. Values around 1400 clear most tunneled cases; going lower than strictly necessary costs a little efficiency but breaks nothing.
4. Many routers offer MSS clamping, sometimes presented as clamping to path MTU. Enabling it lets the router negotiate a workable segment size on every device's behalf and fixes the symptom without touching individual clients.

Separating it from its lookalikes

A download that stops at the same point on the same file every time points at a missing or incomplete article, not MTU. A stall that clears when the connection count is lowered points at the router or the account allowance. MTU faults are indifferent to connection count and indifferent to which file is requested: every bulk transfer over that path hangs, and every small exchange over it succeeds.