'Connection timed out' vs 'Connection refused': what's the difference when your site won't respond

Anyone managing a website will eventually see one of these two messages: "Connection timed out" or "Connection refused". They look like the same thing — the site won't open — but they tell two completely opposite stories, and understanding which one you're seeing immediately narrows the possible causes from ten down to two or three.

Connection refused: someone said no

The browser or terminal sends a SYN packet to open a TCP connection. If it reaches a live machine but no process is listening on that port, the destination operating system responds immediately with an RST (reset) packet. The client translates that response into the message "connection refused". The key point is that this is an active response: the IP address is correct, the route works, the host is reachable. The problem is isolated: either no service is accepting connections on that port, or a firewall is explicitly refusing it.

Connection timed out: nobody answered

Here the client sends the SYN, retransmits it a couple of times, and after a waiting period gives up: this is exactly how a protocol timeout works. The client received no valid response before the time limit expired. Unlike refused, timeout tells you nothing certain about the server: it could be switched off, the address could be wrong, or — most commonly — something along the path is silently dropping packets: a firewall, a cloud security group, or a misconfigured NAT.

Why one is instant and the other makes you wait

The difference in behaviour comes from the firewall rule intercepting the traffic. A REJECT rule drops the packet but sends an error back (RST or ICMP), while a DROP rule discards the packet without responding, leaving the client waiting until timeout. A measurement from an iptables technical guide shows the concrete difference in response times:

Firewall rule	Error reported	Response time
-j DROP	Connection timed out (ETIMEDOUT)	133.5 seconds
-j REJECT (default)	Connection refused (ECONNREFUSED)	less than 0.001 seconds
--reject-with tcp-reset	Connection refused (ECONNREFUSED)	less than 0.001 seconds

This explains why most firewalls exposed on the internet use DROP as the default policy: an instant refusal confirms to anyone port-scanning that the machine exists and is actively refusing, whereas a timeout leaves doubt about whether there's anything behind that address at all.

Most common causes, port by port

Port / service	Refused usually means	Timed out usually means
22 (SSH)	sshd is not running, or listening on a different port	a security group or firewall is blocking that IP
80 / 443 (HTTP/HTTPS)	the web server is stopped	a firewall is preventing the traffic from arriving
3306 / 5432 (MySQL, PostgreSQL)	the database is listening only on localhost	the database was never exposed, or there's a firewall in between
25 (SMTP)	no mail server listening	often the ISP blocks the outbound port

Initial checks, even without being a sysadmin

Before contacting your provider's support, two checks can be done with tools already on any computer:

• Ping to the domain or IP: if it doesn't respond at all, the problem is upstream (DNS, routing), not necessarily on the server.
• Telnet or nc on the specific port (e.g. telnet domain.com 443 or nc -zv domain.com 443): if the connection is refused instantly it's a refused, if it hangs for tens of seconds it's a timeout. This test alone tells you whether to look for "service stopped" or "firewall/network".
• Provider control panel: many hosting providers and VPS services show the cloud firewall (security group) state separately from the operating system firewall; a block can be at either level, not necessarily both.

If the test shows refused, the first thing to check is whether the service is actually running (e.g. systemctl status nginx or your hosting panel showing the web server status). If it shows timeout, focus your search on firewall rules, the cloud provider's security group, or any IP blocklists in place.