400 Service Discontinued

This is the one code in the set a server sends on its own initiative rather than in reply to something the client asked for. Everything else in the 4xx range answers a command. A 400 arrives as an announcement that the connection is ending, and the client finds out about it either as that line or simply as a socket that closed. That difference in origin is what makes its timing the whole diagnosis.

The idle timeout, which needs no action

Newsreaders open several connections and keep them open, but a queue does not always have work for all of them. A connection that sits without issuing a command for the server's idle period gets closed, and the server is polite enough to say so first. Idle timeouts on public news servers are commonly measured in minutes rather than hours. The client notices, reconnects when it next has a segment to fetch, and the transfer continues with no data lost. A log showing a scattering of 400 lines during quiet periods, at the end of a queue, or after a long pause is showing normal housekeeping. Nothing in the client should be changed in response to it, and lowering the connection count to avoid it achieves nothing except a slower queue.

When the timing rules out a timeout

A 400 arriving a second or two after connecting cannot be an idle timeout, because nothing was idle. That pattern has a small number of explanations. The server may be shutting down for maintenance and refusing to start new work. The account may be in a state the server resolves by hanging up rather than by issuing a specific refusal. Something between the two endpoints may be terminating sessions: a firewall or router with an aggressive connection table, a middlebox interfering with the port in use, or a saturated link. Repeated immediate closes across every connection, with no successful transfers between them, is a connectivity or provider condition rather than a client misconfiguration.

What the log pattern assigns fault to

The distribution over time is the evidence. Occasional closes mixed with steady successful downloading is the provider's timeout doing its job and the fault is nobody's. A dense run of them starting at one moment and stopping later, with normal behavior on either side, is a maintenance window or a restart on the provider side, and waiting is the only action available. Immediate closes that persist across a client restart, a reboot, and a change of port point at the network path or at equipment on the local side of it, which is worth testing by connecting from a different network entirely. A single client showing this while another client on the same machine works normally is the rarest case and indicates something in that client's session handling rather than anything upstream.