ERR_CONNECTION_TIMED_OUT: what it means and how to fix it

ERR_CONNECTION_TIMED_OUT is Chrome’s way of saying “I sent a packet to the server and nothing came back.” Not a rejection. Not an error response. Silence. The browser waits about 30 seconds for any sign of life from the other side, gives up, and shows the error page. Firefox shows “The connection has timed out.” Safari shows “Safari can’t open the page because the server where it is located isn’t responding.”

This is one of the most commonly reported web errors because it can be caused by a dozen unrelated things – a firewall that silently drops traffic, a VPN, a browser extension, an overloaded server, a broken route five hops away from you, a misconfigured antivirus, or a DNS record pointing at the wrong IP. The fix depends entirely on which cause applies, and the diagnostic path is about cutting the problem space from “something went wrong” to “this specific thing went wrong” as quickly as possible.

This guide walks through timeout vs refused vs reset (the three connection-failure modes that get conflated), the server-side and client-side causes in order of frequency, and a clear diagnostic workflow using ping , nc , traceroute , curl , and tcpdump to identify which layer is actually failing.

Timeout vs refused vs reset: what each one means#

Three distinct TCP failure modes look similar in the browser but have completely different underlying behaviour. Recognizing which one you have instantly narrows the diagnosis.

• ERR_CONNECTION_TIMED_OUT (this article). Browser sent a SYN packet (the first step of a TCP connection), no response came back. The packet was silently dropped, either by the server being offline, a firewall configured to DROP instead of REJECT, or a network-layer routing failure. The browser waits ~30 seconds and gives up.
• ERR_CONNECTION_REFUSED. Browser sent a SYN, got back a TCP RST (reset) packet immediately. Something is listening at that IP but either nothing is on the port, a firewall is actively rejecting the connection, or the service has crashed. The failure is fast – no waiting involved.
• ERR_CONNECTION_RESET. Browser sent a SYN, got a SYN-ACK back, began the handshake or started sending data, and then the connection was killed mid-flight with a TCP RST. Different from refused because the initial connection was accepted. ERR_CONNECTION_RESET: what it means and how to fix it covers this one specifically.

The practical shortcut: timed out = silence, refused = fast rejection, reset = started then killed. Every timeout cause below produces silence. If you see a fast error instead, you are looking at a different class of problem.

A quick diagnostic to decide server-side vs client-side#

Before going deep on causes, answer one question: does the problem happen for everyone, or just for you? This halves the diagnostic work in about 30 seconds.

• Try the site on your phone over mobile data (disconnect from Wi-Fi first). If it works, the problem is on your network or device. Focus on the client-side causes below.
• Try the site through an online uptime checker like uptimerobot.com, isitdown.live, or downforeveryoneorjustme.com . These test from data centres around the world. If they say the site is unreachable, the problem is at the server or in its network path. Focus on the server-side causes below.
• Try the site from a different browser on the same device. If Chrome times out but Firefox works, the problem is likely a Chrome-specific extension or profile setting, not the server.
• Try from a VPN. If the site works over VPN but not without, your ISP is routing the traffic badly or is blocking something. If the opposite (works without VPN, times out with), the VPN provider is the problem.

Any of these that changes the behaviour narrows the cause dramatically. Start with the two minutes of lateral testing before digging into configs.

Server-side causes#

These affect every visitor, not just you.

Cause 1: Firewall configured to DROP instead of REJECT

The most common server-side cause of ERR_CONNECTION_TIMED_OUT specifically. A firewall can respond to unwanted traffic in two ways:

• REJECT: send a TCP RST packet back to the sender. The client immediately sees “connection refused.”
• DROP: silently discard the packet. The client sees no response at all, waits the full timeout, and shows “connection timed out.”

DROP is the default for most public-facing firewalls because it hides the server from port scanners – if every probe to a closed port gets dropped, an attacker cannot easily enumerate what is running. The tradeoff is that legitimate users who somehow ended up blocked (their IP got flagged, their country is geo-restricted, they are accessing the wrong port) also see a timeout, and the error gives them no hint about why.

Common scenarios:

• The server’s firewall policy blocks the visitor’s IP or country. The visitor sees timeouts on every request. The server has no record of them hitting it because the packets never made it past the firewall.
• The firewall blocks the specific port. Port 443 is open, port 8080 is not. A request to :8080 times out silently.
• An IDS/fail2ban banned the IP after too many failed attempts (SSH, WordPress login, API abuse). The ban usually drops rather than rejects. The banned visitor sees endless timeouts.
• Cloud security groups are misconfigured. AWS Security Groups and GCP/Azure equivalents all default to DROP. If port 80/443 is not explicitly allowed, the server is reachable on SSH but times out on HTTP.

How to confirm:

# From the affected client
nc -zvw 5 example.com 443

If this times out, the port is either closed or dropped. If it says “connection refused,” the port is closed but the firewall is REJECTing (different problem).

From a different network (phone, VPN, uptime checker):

nc -zvw 5 example.com 443

If the other network works, the server is fine – your IP or your network is being dropped specifically. Contact the server operator, or check whether you are on a blocklist.

If both networks time out, the server itself has a firewall issue, is down, or the port is not listening.

How to fix (if you operate the server):

• Check iptables -L -n -v or nft list ruleset for DROP rules. Review the rule order – a permissive rule below a restrictive DROP never runs.
• Check ufw status on Ubuntu/Debian servers that use ufw as a frontend.
• Check cloud provider security groups if you are on AWS/GCP/Azure.
• Check fail2ban-client status and fail2ban-client status <jail> to see banned IPs. If a legitimate user is banned, fail2ban-client set <jail> unbanip <ip> .

Cause 2: Server overloaded – TCP backlog full

The server is technically running but so overwhelmed it cannot accept new connections. When the Linux kernel’s accept queue for a listening socket fills up, further SYN packets are dropped silently. From the client’s perspective, this is indistinguishable from a DROP firewall or a dead server: silence, then timeout.

This typically happens when:

• Traffic spike overwhelms the server (viral post, DDoS, misconfigured bot)
• Backend service is stuck and not accepting requests, so nginx’s worker pool saturates waiting for it, then the accept queue fills
• A memory leak has the server swapping so heavily it cannot process connection accepts at their normal rate

How to confirm (if you have server access):

# Check for SYN queue drops
ss -s

# Look at the Summary line. Large numbers after "tcpext" under "Listen queue of a socket overflowed" point to backlog full
netstat -s | grep -i "listen queue"
netstat -s | grep -i "times the listen queue"

# Load average
uptime

# Connection counts
ss -s | head -5

If the listen queue is overflowing, the server is dropping incoming connections because it cannot process them fast enough.

How to fix:

• Short term: restart the overloaded service ( systemctl restart nginx , etc.) to clear the backlog.
• Medium term: increase the backlog. In /etc/sysctl.conf : net.core.somaxconn = 1024 (default is often 128 or 4096 depending on distro). Also check the application’s listen() backlog – nginx’s listen 443 backlog=2048 for example.
• Long term: figure out why the server saturates. Missing cache layer, slow database queries, too-low PHP worker count for traffic, abusive bot traffic. The 504 gateway timeout in nginx guide covers the overlap between timeout-type errors and backend saturation.

Cause 3: Server is genuinely offline

Power failure, reboot in progress, network outage at the data centre, hypervisor problem on a VPS – the machine simply is not running. Every incoming packet goes nowhere because nothing is there to respond.

How to confirm:

# Can you ping it?
ping -c 4 example.com

# Can you reach the IP directly?
ping -c 4 203.0.113.50

If neither the domain nor the IP responds to ping, the server (or something very close to it) is down. If the IP responds to ping but the web port times out, the server is up but the web service is down or firewalled.

Note: many hosts disable ICMP (ping) at the edge. A failed ping does not always mean the server is down – it might just mean ping is blocked. Use nc -zvw 5 on port 443 as a more reliable aliveness check for web traffic.

How to fix:

• Check your hosting control panel or cloud provider dashboard for the server’s status.
• Check the provider’s status page for outages in your region.
• If the server is down, bring it back up. If the provider reports an incident, wait for them.

Cause 4: Routing issue between client and server

Both endpoints are fine, but something in the network path is broken. An ISP backbone router dropped a BGP route, an intermediate transit provider has a DDoS mitigation that is dropping traffic, or an ISP is doing geographic filtering.

How to confirm:

traceroute example.com    # Linux/Mac
tracert example.com       # Windows

Read the output from top to bottom. Each hop is a router in the path. You should see a chain of IPs with increasing response times. If the trace stops (shows <em> </em> * repeatedly) at a specific hop and never reaches the destination, that is the broken hop.

• First 1-2 hops are usually your local network (your router, your ISP’s gateway)
• Middle hops are ISP and transit providers
• Last few hops are the destination’s hosting provider

If traceroute stops at an ISP hop and the server is reachable from other networks, your ISP has a problem – there is nothing you can do except wait or use a different network. If it stops close to the destination and the site is down for everyone, the hosting provider’s network has a problem.

How to fix:

• If it is your ISP’s issue: wait, call support, or use a VPN to route around the broken path.
• If it is the destination’s provider: wait for them to fix it.
• If you operate the destination, check with your hosting provider about upstream routing issues.

Cause 5: DNS returning the wrong IP

The DNS record for the domain points to an old IP where nothing is listening (maybe you moved hosts and the propagation is still in progress), or your local DNS cache still has a stale record.

The symptom is specifically timeouts, because the client connects to an IP that has no service at that port. If the old IP is completely dead, ping may also fail. If the old IP belongs to another tenant who has their own firewall, you just get dropped.

How to confirm:

# What IP is your system resolving for this domain?
dig +short example.com
nslookup example.com

# Clear the local DNS cache and try again
# Linux (systemd-resolved)
sudo systemd-resolve --flush-caches
# Mac
sudo dscacheutil -flushcache
# Windows
ipconfig /flushdns

Then check from an external location (your phone’s DNS, or dig @8.8.8.8 +short example.com to query Google DNS directly). If the external result differs from your local result, your local DNS is stale.

For a fully external view of DNS, SiteProbe’s DNS lookup tool resolves the domain from Google DNS and Cloudflare DNS – if they return the right IP and your local DNS does not, your DNS resolver is the problem.

How to fix:

• Flush local DNS cache (commands above).
• Switch to 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google) as your DNS server temporarily to confirm it is a local DNS issue.
• If the authoritative DNS is wrong (an actually wrong A record), fix it at your DNS provider. Propagation can take up to the TTL plus some intermediate caching – usually under an hour on modern setups.

Client-side causes#

These affect only you (or only users on your network).

Cause 6: VPN or proxy interference

Your VPN client is routing traffic through a server that cannot reach the destination, the VPN itself is down, or the destination is blocking traffic from the VPN’s IP range (common for streaming services and paywalled content).

Test: disconnect the VPN and try again. If the site loads, the VPN is the problem. If it still times out, the VPN is not the cause.

Some corporate VPNs and privacy VPNs also do their own traffic filtering. A corporate VPN may block “personal” sites during work hours. A privacy VPN may have broken its routing with a bad update. Connecting to a different VPN server location often resolves this.

Cause 7: Antivirus or endpoint security intercepting traffic

Many antivirus products include HTTPS scanning, which man-in-the-middles your TLS connections to look for malware in encrypted payloads. When this works, you see no difference. When it breaks – expired interception certificate, version mismatch, rule engine hung – your traffic times out because the antivirus accepted the browser’s connection but cannot complete its own connection to the destination.

Common culprits: Kaspersky, ESET, Bitdefender, Norton, McAfee with “web shield” or “SSL inspection” enabled.

Test: temporarily disable the antivirus or its web-protection module. If the site works, the AV is the cause.

Fix: update the antivirus (the certificate or signature database may be stale), or disable SSL inspection if the product allows it and you accept the reduced protection.

Cause 8: Browser extension interfering

An extension that modifies network requests – an ad blocker, a privacy extension, a proxy extension, a VPN extension, a dev tools extension – can break connections to specific sites if its rules incorrectly match the domain.

Test: open the site in an incognito/private window. Most extensions are disabled in private browsing by default. If the site works in private mode, an extension is the cause.

Fix: disable extensions one at a time until the culprit is identified. Whitelisting the domain in the extension is usually the permanent fix; uninstalling the extension is the nuclear option.

Cause 9: HOSTS file override

The /etc/hosts (Mac/Linux) or C:\Windows\System32\drivers\etc\hosts (Windows) file lets you override DNS locally. If this file maps the domain to an IP where nothing is running – common after local development work, after changing staging environments, or after a malware installation – you will time out while everyone else connects fine.

Test:

# Linux/Mac
grep example.com /etc/hosts

# Windows (admin PowerShell)
Select-String example.com C:\Windows\System32\drivers\etc\hosts

If there is an entry and it points to something other than the real IP, remove the line.

Cause 10: Browser-specific profile or cache issue

Rare but real: a single Chrome profile has accumulated a state that breaks connections to specific domains. DNS pre-fetching cache, HSTS enforcement with the wrong policy, or a saved QUIC session that is broken.

Test:

• Open the site in an incognito window (bypasses most profile state).
• Open the site in a different browser on the same machine.
• Clear Chrome’s DNS cache: open chrome://net-internals/#dns and click “Clear host cache.”
• Clear HSTS for the domain: open chrome://net-internals/#hsts , query the domain, and delete the HSTS/HPKP entries.

Cause 11: ISP throttling or blocking

Some ISPs throttle or block specific destinations – sometimes for legal/regulatory reasons, sometimes for commercial disputes, sometimes by accident in a misconfigured BGP filter. Your packets get dropped somewhere in the ISP’s network.

Test: connect through a VPN (changes your apparent ISP) or tether through your phone’s mobile data. If the site works via either, your home ISP is the problem.

Fix: permanent workaround is to use the VPN or change ISPs. If this is widespread among your ISP’s users, social media complaints usually get the ISP to fix the BGP misconfiguration within a day or two.

The related error: ERR_CONNECTION_ABORTED#

ERR_CONNECTION_ABORTED is a distinct Chrome error that looks similar but has a different cause. It means the connection was successfully established (so it is not a timeout), but the browser or the server aborted the connection mid-request before receiving a complete response.

Common causes:

• The user clicked away or navigated before the page finished loading
• The server’s nginx client_header_timeout or client_body_timeout elapsed while the browser was still uploading
• A keepalive connection got reset after the idle timeout

If you see ERR_CONNECTION_ABORTED consistently while uploading large files, the server’s upload timeout is probably too short. For nginx, increase client_body_timeout and client_max_body_size . For Apache, adjust LimitRequestBody and Timeout . The error is specifically about mid-flight aborts, not initial connection timeouts – they are different problems with different fixes.

"A TLS error caused the connection to fail"#

Some permutations of ERR_CONNECTION_TIMED_OUT appear in Chrome/Edge with the subtext “A TLS error caused the connection to fail” or similar. This variant usually means the TCP connection succeeded but the TLS handshake that followed timed out. Possible causes:

• The server accepts TCP on port 443 but is not serving TLS (e.g., it is running HTTP-only there by mistake)
• A broken intermediate box (middleware, corporate proxy) is interfering with the handshake
• Server’s TLS implementation is hanging – bug in the version, certificate loading issue, OCSP stapling lookup timing out

For a deep dive on TLS-specific errors (including when a handshake fails with different errors), see ERR_SSL_PROTOCOL_ERROR: what it means and how to fix it.

If your client-side diagnosis narrows to “port 443 TCP succeeds, but the TLS handshake times out,” the server operator needs to check their TLS configuration, OCSP stapling health, and whether any middleware is intercepting the handshake.

The diagnostic workflow in order#

When you hit ERR_CONNECTION_TIMED_OUT, run these in order. Each step either confirms the problem or points to the next step.

Step 1: Is it just you?

Try the site from a different network (your phone on mobile data) or through an uptime checker. If others can reach it, the problem is client-side. If nobody can, it is server-side.

Step 2: Does ping work?

ping -c 4 example.com

• Ping works: the network path is fine, the IP is up, something is wrong at the port level. Move to step 3.
• Ping fails: either ICMP is blocked (common on modern firewalls) or the server is down. Use nc to confirm.

Step 3: Does the port accept connections?

nc -zvw 5 example.com 443
nc -zvw 5 example.com 80

• Both ports time out: the server is down or a firewall is blocking everything. Check from another network to confirm.
• Port 80 works, 443 does not: the server is up but TLS/port 443 specifically has a problem. Check TLS config.
• Both ports work: the TCP layer is fine. The error is likely TLS-level or application-level – you probably should not be seeing a connection timeout at all. Run curl -v to see what is actually happening.

Step 4: Trace the network path

traceroute example.com      # Linux/Mac
tracert example.com          # Windows

Watch where it fails. If it stops partway, note which hop – that is where to focus.

Step 5: Verify DNS is resolving correctly

dig +short example.com
dig @8.8.8.8 +short example.com

If your local resolver returns a different answer than 8.8.8.8, your local DNS is stale.

Step 6: Check with curl for more detail

curl -v --connect-timeout 10 https://example.com/

curl -v shows the connection attempt, TLS handshake, and HTTP request step by step. The first thing that fails tells you which layer has the problem.

Step 7: Capture traffic if needed

If you still cannot tell what is happening after the above, capture actual packets (requires root/admin):

sudo tcpdump -i any -n host example.com -c 50

Then reproduce the request. You will see the SYN packets going out. If there is no response at all, confirms silent drop. If there is a RST or ICMP unreachable, the error was misdiagnosed – it is refused/rejected, not timed out.

Common mistakes#

• Restarting the router as the first step. A restart only helps for about 1% of timeout cases (local ARP cache corruption). Faster to run nc -zvw 5 example.com 443 from a different network first.
• Blaming the DNS for every timeout. DNS causes specifically NAME_NOT_RESOLVED more often than TIMED_OUT. A timeout usually means DNS resolved to something, it just is not answering.
• Disabling firewalls without understanding what they are blocking. “I disabled my firewall and it worked” is not a fix – it is a clue that the firewall was blocking something specific. Find the specific rule.
• Assuming the server is the problem because it is timing out for you. Always check “does it work for other people” first. If yes, the server is fine and you are chasing the wrong thing.
• Using browser cache clearing as a diagnostic for timeouts. Browser cache is for content the browser already received. A timeout means the browser never got anything. Clearing the cache cannot affect that.
• Ignoring tcpdump because it seems hard. sudo tcpdump -i any -n host example.com -c 50 captures the next 50 packets and shows them. That is usually enough to tell you whether packets are leaving your machine at all.
• Trying fixes one at a time across days. The reproduction window for some timeouts is small. Run the full diagnostic sequence once, quickly, while the problem is active. Post-mortem debugging of a timeout you can no longer reproduce is almost impossible.

How Hostney handles connection timeouts#

On Hostney, the common server-side causes of ERR_CONNECTION_TIMED_OUT are handled at the platform level rather than left for each site to configure. The firewall uses REJECT for “legitimately blocked” traffic (WordPress brute-force IPs, malicious bots that have been scored high enough for a ban) and DROP only for the noisiest automated scanner traffic, so legitimate users who end up on the wrong side of a rule see fast rejections rather than silent timeouts. The net.core.somaxconn and per-service listen backlogs are set well above the defaults so traffic spikes up to the account’s tier do not overflow the SYN queue, and nginx worker pools scale with the site’s plan so the “backend saturation leads to accept-queue overflow” scenario is rare.

For traffic that hits the edge Cloudflare layer (a common setup), a timeout between Cloudflare and the origin results in a 520 or 521 error shown to the visitor rather than a generic ERR_CONNECTION_TIMED_OUT – because Cloudflare serves its own error page instead of leaving the visitor with a raw browser timeout. This is useful diagnostically: if visitors are seeing 520/521 rather than connection timeouts, the problem is at the Cloudflare-to-origin link and you can narrow the diagnosis to that specific hop.

When a site running on Hostney is unreachable for a specific user, the fastest sanity check is nc -zvw 5 <site>.com 443 from a different network, which rules out the user’s ISP/network/VPN/antivirus in one command. SiteProbe’s website speed test also includes a connectivity check – if the speed test completes but a specific user cannot reach the site, the problem is definitively on the user’s side, not the server. For SSH-specific connection timeouts (different port, different failure modes), SSH connection refused: what it means and how to fix it covers the port 22 equivalent.

Summary#

ERR_CONNECTION_TIMED_OUT means the browser’s packets disappeared into the void – nothing came back within about 30 seconds. The error has three rough classes of cause: server-side (firewall DROP, backlog overflow, server offline, routing path broken, DNS pointing at a dead IP), client-side (VPN, antivirus intercepting TLS, browser extension, HOSTS override, ISP throttling), and in-between (intermediate network path broken). The diagnostic path is always the same: cross-check from a different network first, then ping → nc -zvw 5 → traceroute → curl -v → tcpdump if needed, narrowing each step. Do not guess at fixes – each cause has a specific fix and applying the wrong one (like disabling your entire firewall, or clearing your browser cache for a network-level problem) wastes time without getting closer. If you cannot even tell whether the problem is client-side or server-side, the 30-second test is trying the site on your phone over mobile data: works = client-side, still broken = server-side.