Connection Refused

The distinguishing feature is speed. A refused connection fails in milliseconds, because a machine at that address answered the opening packet with a rejection rather than an acknowledgement. Something on the far end is reachable; it simply has nothing listening where the client knocked. That immediacy is diagnostic on its own, and it eliminates several other faults before a single setting is touched.

Immediate rejection versus a slow timeout

Three failures read alike in a newsreader log and mean different things. A refusal returns instantly. A timeout hangs for ten to thirty seconds before giving up, which points to a filter silently discarding packets rather than a host answering them. A resolution failure returns before any packet leaves the machine at all, and the log names the hostname instead of an address. Timing separates the three faster than parsing the message text does.

Where the fault usually sits

Almost always on the local side or somewhere in the path, not at the provider. A news server that is genuinely offline produces failures on every port for every customer at once, and it is visible on the provider's status page within minutes. A refusal on one port while another port on the same hostname connects is conclusive proof the server is running. The usual local causes are a port field carrying 119 on an account configured for encrypted access, an SSL option enabled against a plaintext port, a desktop firewall rule, and a managed network that rejects outbound news traffic openly instead of dropping it.

Working through the ports

1. Try 563 with SSL enabled. Success here means plaintext 119 is blocked or unused and nothing further needs fixing.
2. Try 119 with SSL disabled. Success here, paired with failure on 563, usually means encryption was switched on against the wrong port number.
3. Try whatever alternate ports the provider publishes, commonly 80, 443 or 8080. These exist precisely because some access networks filter both standard news ports.
4. If every port refuses instantly, re-check the hostname against the provider's current documentation. Hostnames inherited from a migrated or rebranded service can still resolve to a machine that no longer answers on news ports.

What a refusal rules out

It is not an authentication problem. No credentials are sent, so an expired account or a mistyped password cannot produce it; those surface after the session opens, as 481 or 502. It is not a connection limit, which also requires a completed handshake first. It is not a certificate or cipher fault, since the refusal precedes the TLS handshake entirely. A log that mentions a certificate, a protocol version or a news response code describes a connection that was established, and the diagnosis lies elsewhere on that page rather than this one.

The rarer provider-side case

One pattern does implicate the provider: every port refuses, another network refuses identically, and the hostname is verified correct. That combination usually means the address behind the hostname has been retired, which happens after infrastructure moves when an old record is left in place. It resolves either when the provider corrects the record or when the client is pointed at the current hostname. It is uncommon enough to be the last hypothesis tested, not the first.