Diagnosing Connection Timed Out: Network or Server?

Your site won't load and after a few seconds the browser says ERR_CONNECTION_TIMED_OUT. Or you SSH in and after waiting a while, you see the message ssh: connect to host x.x.x.x port 22: Connection timed out. This error is different from "Connection refused," and that very difference determines the entire troubleshooting path. In refused, the destination server responds and says this port isn't open; meaning the packet reached the destination. In timed out, no response comes back and you don't know where the packet got lost. So the first task is to find the point of loss, not to change the server config.

The Correct Test Order: From the Bottom Layer Up

Most admins go straight to restarting the service or checking logs. That's a waste of time when you still don't know whether the problem is in the network path or on the machine itself. Follow the order below; each step only makes sense if the previous step has answered.

1. Is domain name resolution (DNS) done correctly?
2. Does the packet reach the destination? (ping and traceroute)
3. Is the specific port open? (nc or telnet)
4. Is the service listening on that port? (ss and service log)
5. Is the firewall or virtual host blocking the request?

Step One: Check DNS Before Anything Else

If the domain name resolves to the wrong IP, all subsequent tests are meaningless. First see what IP comes back:

dig +short example.com A
dig +short example.com AAAA

If the returned IP differs from your server's actual IP, the problem isn't the network; it's the DNS record. The A record must point exactly to the server IP, and if IPv6 isn't enabled, remove the AAAA record. A wrong AAAA causes the browser to try IPv6 first, get no response, and after a timeout fall back to IPv4. To check records and DNS propagation, use the DNS and network lookup tool.

Step Two: What ping and traceroute Prove

ping only says the ICMP packet went and came back. Many servers have ICMP closed and ping doesn't respond while the service is perfectly healthy. So not getting a ping isn't definitive proof. But if ping responds, it means the network path to the destination is open and you should look for the problem in higher layers.

ping -c 4 185.10.20.30
traceroute -T -p 443 example.com
mtr -rwzc 20 example.com

In traceroute, where the stars begin matters. If you see stars up to the last hop and nothing after, the destination firewall is probably dropping ICMP. If stars appear mid-path and then continue, that router just doesn't respond to ICMP and there's no problem. mtr is better than traceroute because it shows packet loss over time; stable loss on an intermediate hop usually means a real problem in the path.

Step Three: Port Testing, Where Most Diagnoses Go Wrong

This is the point where you must distinguish between ICMP and TCP. A firewall can leave ICMP open but close port 443. The reverse is also possible. So do the port test separately:

nc -vz -w 5 example.com 443
nc -vz -w 5 example.com 22
curl -v --connect-timeout 5 https://example.com

If nc also times out on port 443 but port 22 is open, the problem is almost certainly the firewall or Security Group, not the web service. If both ports time out but ping responds, you have a drop rule in the firewall or an upstream ACL. If both ports give refused, the firewall is open and the service isn't listening; here the problem is internal to the server.

This Is Where They Go Wrong

The most common mistake I've seen: the admin opens the port in the server firewall, ufw status also says allow, but they still get a timeout. The reason is that the upstream firewall (cloud Security Group or datacenter ACL) is still closed and traffic never reaches the machine. The sign is that in tcpdump on the server you see no packets for that port. If no packet arrives, any change to the config inside the server is useless.

tcpdump -ni eth0 'tcp port 443 and tcp[tcpflags] & tcp-syn != 0'

If this command gives empty output while you're sending requests from outside, traffic was dropped before reaching the server. Conversely, if you see SYN but no SYN-ACK comes back, the problem is inside the machine: either the service isn't listening or the local firewall is dropping.

Step Four: Is the Service Actually Listening on the Port

ss -tlnp | grep -E ':80|:443'
systemctl status nginx
journalctl -u nginx --since "10 min ago"

Pay attention to the Local Address column. If it says 127.0.0.1:443, the service is only listening on loopback and isn't accessible from outside. It must be 0.0.0.0:443 or [::]:443. I see this a lot on configs that come up after a reinstall or a change to the nginx.conf file.

Symptom Comparison: Which Test Rules Out What

When the Problem Isn't on Your Side

If the tests show that traffic reaches the server, the service is listening, and the firewall is open, but you still get a timeout from outside, the issue is in the international path or filtering on the destination side. Here, changing the server config won't help at all. Run the test from several different geographic locations and give the result to your infrastructure provider's support; the mtr output with the exact hop noted helps the most.

One note about cost: leaving a port open for testing from all IPs is the easiest way, but it must be temporary. If you open a management port like 22 or 3306 to 0.0.0.0/0 for troubleshooting and forget to close it, you'll see automated attacks in the auth log. For testing, restrict it to your own IP with a /32 mask.

If your server runs on a managed Linux host, part of this path (upstream firewall and ACL) isn't under your control and you must ask support to confirm the port status from outside. On a dedicated server you usually have fuller access to these layers and can take tcpdump yourself.

Frequently Asked Questions

What's the difference between Connection timed out and Connection refused?

In refused, the destination server actively responds that this port is closed; meaning the packet reached the destination and the problem is internal. In timed out, no response comes at all and the packet was dropped in the path or on the firewall. This difference determines whether you go after the service or after the network.

Why does ping respond but the site won't load?

Because ping uses the ICMP protocol and the site uses TCP on port 443. A firewall can leave ICMP open and keep port 443 closed. So a successful ping only says the network path to the destination is open, not that the web service is reachable.

How do I tell whether the server firewall or the upstream firewall is to blame?

Take tcpdump on the server and send a request from outside at the same time. If no SYN packet arrives, the upstream firewall dropped the traffic. If SYN arrived but SYN-ACK didn't come back, the local firewall or the service has a problem.

Can an AAAA record cause a timeout?

Yes. If an AAAA record exists but the server isn't listening on IPv6, the browser tries IPv6 first, gets no response, and after a timeout falls back to IPv4. If you haven't set up IPv6, remove the AAAA record.

The next step is clear: first run dig, then mtr, then nc on the port. Until these three have answered, don't touch the server config.