Connection Refused vs Connection Timed Out

"Connection refused" and "connection timed out" are both TCP connection failures, and they point at different causes. Refused means a host received the connection request and answered it with a reset: it is reachable, but nothing is listening on that port. Timed out means no answer came back at all, usually because a firewall dropped the request or the host is unreachable.

Picture a developer deploying an API to a new server. From their laptop, curl https://api.example.com fails. Treating every failure as "the server is down", they restart the server twice, and nothing changes, because the error was telling them where to look.

The symptom. One of two messages. "Connection refused" appears instantly. "Connection timed out" appears after a long pause, often more than a minute, during which the client sends the request again several times.

Why it happens. A client opens a TCP connection by sending a SYN segment. A host that receives a SYN for a port with no listening program replies with an RST, a reset, and the client reports the refusal at once. A firewall set to drop traffic sends nothing back, and neither does a host that is switched off or an address nobody has, so the client waits, sends the SYN again with growing gaps, and gives up.

What it costs. Misreading the error sends the investigation to the wrong layer: restarting a server that is fine, or editing firewall rules when the program has crashed.

What to check. For refused, the host is reachable: check that the program is running and listening on the expected port and address, with ss -tlnp on Linux. A server that listens only on 127.0.0.1 refuses connections from other machines. For timed out, look at the path: firewall rules, cloud security groups, the address itself and routing. One exception blurs the line: a firewall configured to reject rather than drop sends a reset itself, so a refusal can come from a firewall too.