ERR_CONNECTION_TIMED_OUT: Causes and the Fix

ERR_CONNECTION_TIMED_OUT is the browser giving up after total silence. It sent a connection request, waited twenty or thirty seconds, and heard nothing back. That silence is itself the clue: a machine that is up and refusing would have said so, so something is dropping packets rather than answering them.

Silence means dropped, not rejected

Firewalls have two ways to say no. REJECT sends a reset back, and the browser reports a refused connection immediately. DROP says nothing at all, and the browser waits out its timeout. Most firewalls default to dropping, which is why a timeout is by far the more common of the two and why it points at a firewall before it points at a stopped service.

The other possibility is that the address is simply not reachable from where you are - a routing problem, or a server that no longer exists at that IP.

Other browsers describe the same failure in their own words - Firefox, for instance, says "The server at … is taking too long to respond." However it's worded, the connection to the server timed out before anything answered, and the steps below apply unchanged.

Step 1: test the port, not the host

This is where most time gets wasted. Ping uses ICMP; your website uses TCP on port 443. They are governed by different firewall rules, so ping succeeding tells you almost nothing about whether the site should work.

ping -c 4 yourserverip                  # routable? (ICMP only)
nc -zv yourserverip 443                 # is the port actually reachable?
curl -sS -m 10 -o /dev/null -w '%{http_code}\n' https://yourserverip -k

A ping that answers and an nc that hangs is the signature of this error, and it means the machine is alive and something is dropping traffic to that specific port.

Step 2: work out which network you are on

Before touching the server, check whether the problem follows you. Load the site on a phone with Wi-Fi off, on mobile data.

• It works on mobile data - your current network is dropping the traffic. Corporate firewalls, campus networks and some ISP filtering all do this, and there is nothing to change on the server.
• It fails everywhere - the drop is at or near the server. Continue.

Step 3: check both firewall layers

On a cloud VPS there are two independent firewalls, and either one can drop the packet. Checking only the one you remember is the classic way to spend an hour on this.

The operating system:

ufw status verbose
iptables -L INPUT -n -v --line-numbers
csf -l                          # cPanel servers

ufw allow 80/tcp && ufw allow 443/tcp
firewall-cmd --permanent --add-service={http,https} && firewall-cmd --reload

The provider's network firewall: security groups on AWS, cloud firewalls on DigitalOcean, network security groups on Azure. These sit in front of the operating system, so a packet they drop never reaches UFW at all - and UFW will happily report the port as open. Check the provider's console directly.

A fresh VPS is the most common context for this. Many images ship with a default policy that permits SSH and drops everything else, so the site is installed, running, and unreachable from the moment it is deployed.

Step 4: confirm something is listening

If both firewalls are open and it still times out, verify from the server itself that there is anything to reach:

ss -tlnp | grep -E ':(80|443)\s'
curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1

A service bound to 127.0.0.1 rather than 0.0.0.0 answers locally and is invisible from outside. That normally produces a refusal rather than a timeout, but with a dropping firewall in front of it you get silence instead - two problems stacked, and fixing only the firewall leaves you no better off.

Step 5: rule out load

A server under real pressure stops accepting new connections while still appearing up. The accept queue fills, new requests are dropped, and from outside that is indistinguishable from a firewall.

uptime
free -h
ss -s | head -5

A load average well above the core count, or memory exhausted with heavy swapping, is your answer - and the fix is capacity or a runaway process, not a firewall rule. Check what is consuming it with top before adding resources, because a single stuck process is cheaper to kill than a resize.

Step 6: check you are talking to the right machine

After a migration or an IP change, a stale record sends you to an address that may no longer route anywhere at all - which times out exactly like a firewall drop.

dig +short yourdomain.com @1.1.1.1
dig +short yourdomain.com @8.8.8.8
curl -sS https://api.ipify.org; echo        # run this ON the server

If the public resolvers agree with each other but disagree with the server's own address, the domain is pointing somewhere else and the machine you are debugging is not the one being asked.

Keeping it from recurring

• Whitelist your own address in CSF before locking down a new server, so you do not firewall yourself out of it.
• Keep the provider's security group rules noted alongside the OS firewall rules. The two drift apart after any quick fix, and the gap between them is where this error lives.
• Monitor with a request to the actual site over HTTPS rather than a ping. A ping check stays green through exactly the failure described on this page.
• After a migration, update DNS and let it settle before decommissioning the old machine, so a cached record does not point at an address that has stopped routing.