ERR_CONNECTION_TIMED_OUT: find where your packets disappear

Short answer: ERR_CONNECTION_TIMED_OUT means your browser sent a connection request to the server and got no reply at all before your operating system gave up. A firewall silently dropped the packets, a stale DNS record sent them to the wrong IP, or the server is down or too overloaded to answer. Chrome words it as example.com took too long to respond, Firefox as The connection has timed out. Find the point where your packets stop and you have found the cause.

# 1. From your computer: does the port answer at all?
curl -sv --connect-timeout 10 -o /dev/null https://example.com/
Test-NetConnection example.com -Port 443      # Windows PowerShell

# 2. Does the domain point where you think it does?
dig +short A example.com
dig +short AAAA example.com

# 3. On the server, via the provider's console: does it answer locally?
curl -sI http://127.0.0.1/

# 4. On the server: do your packets arrive? (198.51.100.7 = your IP)
sudo apt install -y tcpdump      # if it is missing
sudo tcpdump -ni any 'tcp port 443 and host 198.51.100.7'

When nothing answers, curl gives up once the 10 seconds set by --connect-timeout have passed and exits with code 28, its timeout code, and Test-NetConnection prints TcpTestSucceeded : False. Skip ping as a test: many servers filter ICMP, so a failed ping proves nothing about port 443.

How is a timeout different from a refusal?

Loading a page starts with a TCP handshake. Your machine sends a SYN packet and waits for a SYN-ACK. If the server answers with a reset instead, Chrome shows ERR_CONNECTION_REFUSED (net error -102) at once. If nothing comes back, your system resends the SYN a few times with growing gaps, gives up, and Chrome reports ERR_CONNECTION_TIMED_OUT (net error -118). Silence means a packet was dropped somewhere, or never reached a running machine.

Chrome also has a plain ERR_TIMED_OUT (net error -7), without the word connection. It is a broader timeout: Chrome uses it, for example, when the whole connection setup, TLS handshake or proxy included, runs past its time limit. If curl -v prints Connected to and then hangs, the TCP path and the firewall are fine. Look at TLS, at any proxy in between and at the application instead.

Do your packets reach the server?

This one test splits the problem in half. You may not be able to SSH in if SSH times out too, so open your provider’s console. Find your own public IP (run curl -4 ifconfig.me on your computer), start the tcpdump from the box above on the server, and repeat the request. Test with curl -4 --connect-timeout 10 https://example.com/ rather than the browser: a browser on a network with IPv6 may connect over IPv6, and a filter on your IPv4 address would then show nothing even though the packets arrive.

• Nothing appears: the packets never reach the server. The DNS record points elsewhere, a firewall in front of the server drops them, your own network blocks the port, or the server has no working network.
• Flags [S] arrives, no Flags [S.] goes back: the server receives your SYN and stays silent. tcpdump sees packets before the firewall does, so this is the host firewall dropping them, or a listen queue so full that the kernel drops new connections.
• [S] in, [S.] out, and the browser still times out: the reply gets lost on the way back. That is rare: usually a routing mistake on a server with several addresses, or a firewall on your side.

Cause 1: a firewall on the server drops the port

This is the most common cause on a new server, and on one where someone just enabled a firewall. ufw’s default policy for incoming traffic is deny, and deny means drop: no answer, so a timeout. A port you forgot to allow looks exactly like a dead server.

sudo ufw status verbose        # "Default: deny (incoming)" and is 80/443 listed?
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# hand-written rules: look for a drop policy or drop rules
sudo nft list ruleset | grep -i drop
sudo iptables -S INPUT

Two variations catch people out. fail2ban, CrowdSec and similar tools add rules for single addresses, so the site works for everyone except you, often after a script hammered a login page or a jail that bans every port caught your mistyped SSH passwords. Whether a ban shows up as a timeout or as a refusal depends on the tool’s ban action and on your operating system. Check sudo fail2ban-client status and the jail it names. Docker is the opposite trap: it writes its own iptables rules that bypass ufw, so ufw’s list does not tell you what a container exposes. docker ps does.

Why does a Windows server time out instead of refusing?

Windows Defender Firewall blocks unsolicited inbound connections unless a rule allows them, and it drops them silently. On top of that, its stealth mode, on by default, sends no reset for a port where nothing listens. So on a Windows VPS a missing firewall rule and a stopped web server both show up as a timeout. Check both:

# is anything listening on 443?
Get-NetTCPConnection -State Listen -LocalPort 443

# is there an inbound rule for it?
Get-NetFirewallPortFilter | Where-Object { $_.LocalPort -eq 443 } | Get-NetFirewallRule

# allow it
New-NetFirewallRule -DisplayName "HTTPS in" -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow

Cause 2: a firewall in front of the server

If the host firewall allows the port, the IP is right, and tcpdump still shows nothing, look upstream. Many clouds filter traffic in a security group or network firewall configured in their control panel, and new instances often allow only SSH. A server at home or in an office needs a port forward on the router, and cannot be reached at all if your ISP puts you behind carrier-grade NAT, where the router has no public IPv4 address of its own. Some residential ISPs also block inbound port 80.

Cause 3: DNS sends visitors to the wrong IP

After a migration, or when a typo slipped into the record, the domain resolves to an address where nothing answers. Compare what DNS says with the IP in your provider’s panel, and ask your DNS host’s own nameservers as well as public resolvers, because caches can still serve the old answer until its TTL runs out:

dig +short NS example.com                    # who is authoritative?
dig +short A example.com @ns1.your-dns-host.example
dig +short A example.com @1.1.1.1
dig +short A www.example.com @1.1.1.1        # www is a separate record

Check the AAAA record too. If it points to an IPv6 address the server does not actually serve, browsers on IPv6 networks usually fall back to IPv4 after a short delay, but apps, scripts and uptime checks there can hang until they time out. Fix the IPv6 setup or delete the record. On your own computer, clear the caches after a change: ipconfig /flushdns on Windows, and chrome://net-internals/#dns then Clear host cache in Chrome. Also look in your hosts file (/etc/hosts, or C:\Windows\System32\drivers\etc\hosts) for an old test entry.

Cause 4: the server is too busy to answer

A listening socket has a queue of finished handshakes waiting for the application to accept them. When the app is too slow and the queue is full, Linux drops new connection attempts by default instead of resetting them, so visitors time out while the server looks “up”. For a listening socket, ss shows the current queue in Recv-Q and its limit in Send-Q:

ss -tln '( sport = :443 )'                      # Recv-Q near Send-Q = queue full
nstat -az TcpExtListenOverflows TcpExtListenDrops # counters that keep rising = drops
sudo dmesg -T | grep -i 'table full'              # "nf_conntrack: table full, dropping packet"
uptime; free -h                                   # load and memory

A full queue is a symptom: the real problem is CPU, memory or too few PHP-FPM or app workers. VPS high CPU usage shows how to find the process that eats the box. Once that is fixed, you can give nginx a longer queue with listen 443 ssl backlog=4096; (set it on one listen line per address and port). The kernel caps it at net.core.somaxconn, which defaults to 4096 on current kernels; nginx itself asks for 511 on Linux. If dmesg reports the conntrack table full, raise net.netfilter.nf_conntrack_max with sysctl, or stop tracking traffic you do not need to.

If the load is real traffic rather than a bug, the server is simply too small. Match the next plan to how your stack uses the CPU. A PHP-FPM pool with many workers spreads across cores, so it wants more vCores and RAM, such as a larger Standard KVM plan. A single-threaded Node process leans on one core, which is what the Hi-CPU KVM line on AMD EPYC with ECC memory is built for. If the flood is an attack rather than visitors, note that every VMHeaven server and hosting plan comes with always-on DDoS mitigation in whichever location it runs.

Cause 5: the server is down, or its network is

If SSH times out too, look at the server’s screen in the console. A stopped machine, one stuck in emergency mode after a bad /etc/fstab line, or one whose network config has a typo all look the same from outside. Log in on the console and check:

ip -br addr          # the public IP should be on an UP interface
ip route             # there should be a "default via ..." line
ping -c 3 1.1.1.1    # can the server reach out at all?

SSH connection timed out covers this side in more depth, from netplan typos to fail2ban bans on port 22.

Cause 6: the route between you and the server

When packets leave your network but never arrive, and the server and its firewall are fine, the route is the suspect. mtr in TCP mode tests the path with the same kind of packet the browser sends:

# install: sudo apt install -y mtr-tiny (Debian, Ubuntu) or brew install mtr (macOS)
sudo mtr -rwc 50 -T -P 443 example.com     # from you to the server
sudo mtr -rwc 50 -T -P 443 198.51.100.7    # from the server back to you, if you can

No machine at the far end to run the second command on? Our looking glass runs MTR from Amsterdam to your address, which shows the route towards you from outside your network.

Read it from the bottom. Loss shown on a middle hop but not on the hops after it is just a router that rate-limits its answers to probes; ignore it. Loss that starts at one hop and carries on to the last line is real. On Windows, tracert -d and pathping give a rougher picture. If the loss sits outside your network and the server’s, send both reports to your provider: routing is theirs to fix.

How do I keep it from happening again?

• Allow before you enable. Add rules for SSH, 80 and 443 first, then turn the firewall on, and test from outside before you close the console.
• Lower the DNS TTL a day before a migration, so a wrong or old record lives minutes instead of hours.
• Monitor from outside. An external check on 443 sees firewall, DNS and routing problems that a check on the server never will.
• Exempt your own fixed IP in fail2ban’s ignoreip, so a typo does not lock you out.
• Keep a way in that does not need the network. Every VMHeaven KVM plan has a browser VNC console in the panel that reaches the machine even when its network is broken, so a bad firewall rule costs minutes, not a reinstall.

Frequently asked