Connection timed out: why the silence means no reply

Your browser shows ERR_CONNECTION_TIMED_OUT. The page hangs. curl exits with code 28. Node reports ETIMEDOUT. The client sent a TCP SYN packet and got no answer. Silence, not rejection.

This error means the request never reached a destination that could reply. Packets were dropped or lost somewhere on the path, and nothing came back at all.

The fix depends on who you are. If you are a visitor, the issue is likely your local network, DNS, or a VPN. If you own the site, the problem is usually a firewall rule, a downed service, or resource exhaustion. Start by checking the site from an outside network to see if the problem is global or local.

What a connection timed out error actually means

The client sent a TCP SYN packet and received no answer within its time budget. It gave up. This silence is the key diagnostic fact. A timeout means no reply came back. Packets were dropped or lost on the path.

This is distinct from other common errors. ERR_CONNECTION_REFUSED means an active host replied with “nothing listening here.” A 504 Gateway Timeout means the server did reply, but a proxy upstream of the application timed out waiting for the backend. A connection timed out error means nothing came back at all.

The symptom varies by tool, but the root cause is the same. Chrome shows ERR_CONNECTION_TIMED_OUT after roughly 30 seconds. curl exits with code 28 (“Operation timed out”). Node and other runtimes surface ETIMEDOUT.

On Linux, the kernel retries an unanswered SYN six times by default (net.ipv4.tcp_syn_retries=6) with exponential backoff (1+2+4+8+16+32+64s). A raw TCP connect can hang for about two minutes before failing.

There are two flavors of this failure. Connect timeout means the TCP handshake never completes because the server or a firewall is dropping packets. Read timeout means the connection opened, but the response never arrived because the server accepted the connection and then stalled. Identifying which flavor you are seeing determines whether you look at network paths or application health.

Check if the problem is yours or the site’s

Determine whether the timeout originates from your local environment or the remote server. This distinction saves hours of misdirected troubleshooting.

Run AlertKick’s free website down checker. Enter the failing URL. The tool tests the site from an external network with no signup required. It reports up or down status, the HTTP response code, the full redirect chain, and exactly where the delay occurs: DNS lookup, TCP connect, TLS handshake, or time to first byte.

If the external check succeeds, the site is reachable. The problem lives on your side. Your local network, VPN, or DNS cache is likely blocking or delaying the request.

If the external check also times out, the site or its network is the problem. The server is not responding to the internet at large.

Fix local network and DNS issues as a visitor

If the external website down checker shows the site is up, the problem lives on your side. The browser sent a TCP SYN packet and got silence. This usually means your local network, VPN, or DNS cache is blocking or misrouting the traffic.

Switch networks. Connect to a phone hotspot or a different Wi-Fi network. If the site loads there, your primary network or its firewall is the culprit. Corporate proxies and VPN exit nodes are the most common cause of single-user timeouts. Turn off any active VPN or proxy and try again.

Clear your local DNS cache. A stale or poisoned DNS record can point your browser to an IP address that no longer exists or never answers. Use the correct command for your operating system:

• Windows: ipconfig /flushdns
• macOS: sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
• Linux (systemd-resolved): sudo resolvectl flush-caches

Verify what IP your machine is actually using. Run dig +short example.com and compare the result against a public resolver like Cloudflare: dig +short example.com @1.1.1.1. If the local resolution differs from the public one, your local DNS is serving a bad answer.

Restart your router. NAT tables in consumer-grade routers can fill up and silently drop new connections. A reboot clears the state and often restores connectivity.

Check local security software. Antivirus or firewall “web protection” features sit in the connection path and can drop traffic to sites they misclassify. Temporarily disable these features to rule them out. If the site loads with protection off, add an exception for the domain.

Diagnose server and firewall problems as the owner

Reproduce the timeout from an external network first. Run curl -v --connect-timeout 10 https://example.com from a machine outside your office or home network. Where curl stops tells you the failing phase. If it hangs after “Trying …”, the TCP handshake never completes, pointing to a firewall or dead host. If it connects but returns no response, the application is stalled.

Verify the box is up and the service is listening. Run ss -tlnp | grep ':443'. No listener means the service is down or bound to the wrong interface. Check uptime and top to see if the load average is far above the core count. An overloaded server cannot answer the accept queue in time.

Firewalls that DROP packets produce exactly this silence. Unlike REJECT, which sends an immediate error, DROP makes the packet vanish. Check host rules with sudo iptables -L -n or sudo nft list ruleset. Also check the cloud layer: security groups, network ACLs, and any provider edge firewall. A rule that allows only specific source ranges times out for everyone else. This is why “it works from the office” proves nothing.

Check for automated bans. Systems like fail2ban may have blocked the complaining user’s IP. Run sudo fail2ban-client status then sudo fail2ban-client status <jail> to list banned addresses.

Use mtr -rw example.com to trace the path. This shows where packets die. A routing or peering fault mid-path times out identically to a dead server.

If the site sits behind a CDN or load balancer, a timeout at the edge usually means the origin stopped answering. Check the origin directly against its IP, not through the CDN hostname.

On busy boxes, connection-table exhaustion can cause silent drops. Run dmesg | grep -i conntrack. A “table full, dropping packet” message means new connections are dropped until the table drains.

For read-timeout flavors where the connection opens but stalls, look at the app tier. Exhausted worker pools, a database query holding every worker, or a hanging upstream dependency are common causes. Check the slowest layer first with journalctl -u <service> --since -1h for the app, plus slow-query logs on the database.

Catch intermittent timeouts with continuous monitoring

One-off checks answer “is it down NOW”. Timeouts that come and go with load or with a specific region will pass every manual check. A site owner can run curl from their office, see a healthy response, and assume the problem is resolved. The user in a different region or on a different ISP still sees the silence.

Continuous uptime monitoring catches this class of failure. AlertKick checks monitors on a schedule from more than one region (EU and US), so a firewall rule or peering fault that only affects part of the internet still trips an alert, with the failing phase (DNS, connect, TLS, first byte) recorded. The free plan includes uptime monitors with alerts by email, Slack, Telegram, or WhatsApp, and escalation chains for teams.

Set the check interval tighter than your patience: a 1-minute check turns “users tweeted at us for an hour” into a page at minute one.

For deeper visibility, review the checks every server should have on day one. These checks cover the layers where timeouts hide: connectivity, certificate validity, and response time.

When an alert fires, the recorded phase tells you where to look. A DNS timeout points to resolver issues or stale records. A TCP connect timeout points to firewalls, security groups, or dead hosts. A TLS handshake timeout points to certificate expiration or misconfigured SNI. A time-to-first-byte timeout points to application stalls or database locks.