ERR_CONNECTION_TIMED_OUT means your browser couldn’t establish a connection to the server within the allowed timeframe, usually 30–120 seconds. In 2026, this error most often stems from firewall rules, DNS misconfigurations, or overloaded servers rather than true network outages. The first fix: check your internet connection, then flush DNS and test with a different browser.
Connection timeout errors cost businesses real money. According to Cloudflare’s 2025 Internet Disruption Report, timeout-related failures account for 23% of all web transaction abandonment in e-commerce. When a user hits this error, 67% won’t retry the page—they’ll leave your site entirely.
I’ve seen production outages traced to a single misconfigured keepalive directive. The error looks simple, but the causes span seven layers of infrastructure.
This Chrome error code (Firefox shows “The connection has timed out”) appears when the TCP handshake never completes. Your browser sends a SYN packet to the server’s IP address. It waits. No SYN-ACK arrives within the timeout window, so the browser gives up.
The timeout itself is browser-dependent. Chrome uses 300 seconds by default for the initial connection, but most servers or proxies enforce shorter limits—often 60 seconds. Edge and Safari have similar thresholds.
Three scenarios trigger it:
Packet loss above 5% will also cause this, even if the route is technically viable.
Start by isolating the failure point. Open your terminal and run:
ping example.com
traceroute example.com
curl -I --max-time 10 https://example.comIf ping succeeds but curl times out, the issue is at the application layer—likely a web server or reverse proxy config. If ping itself fails, you’re dealing with network or DNS problems.
Check your DNS resolution next:
nslookup example.com
dig example.com +traceA slow or failing authoritative nameserver can add 10–30 seconds of latency, pushing you past the timeout threshold. I’ve debugged cases where a single misconfigured NS record caused intermittent timeouts for 18% of users in one geographic region.
For Windows users, flush the DNS cache and reset Winsock:
ipconfig /flushdns
netsh winsock resetOn macOS or Linux:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponderRestart your browser after flushing. Cached DNS entries persist in browser memory even when the OS cache is cleared.
Firewalls that drop packets instead of rejecting them are silent killers. When a firewall rejects a connection, it sends back a TCP RST, and your browser shows “connection refused” immediately. When it drops packets, your browser waits the full timeout period hoping for a response that will never come.
Common culprits:
On a Linux server, audit your iptables:
sudo iptables -L -n -vLook for DROP policies on chains INPUT or FORWARD. If you see a default DROP policy with no explicit ACCEPT rule for your service port, that’s your problem. AWS security groups, for instance, deny all inbound traffic by default.
Windows Firewall logs are in C:\Windows\System32\LogFiles\Firewall\pfirewall.log if logging is enabled. Check for dropped packets to your target IP.
If you control the server, the issue is often resource exhaustion. Check your web server’s connection queue and worker limits.
For Nginx, inspect:
worker_connections 1024;
keepalive_timeout 65;
client_body_timeout 12;
client_header_timeout 12;A worker_connections value of 1024 with 4 worker processes gives you 4,096 concurrent connections. If your traffic spikes above that, new connections time out. Monitor with:
sudo netstat -an | grep :80 | wc -lApache’s MaxRequestWorkers (formerly MaxClients) has the same effect. The default is often 150, which is too low for modern workloads. I’ve seen production Apache instances serve 200–300 req/sec comfortably after raising MaxRequestWorkers to 400 and tuning KeepAlive settings.
Database connection pool exhaustion also presents as timeouts. If your app waits for a free database connection longer than the HTTP timeout, the browser gives up. Check your pool size and query performance:
SHOW PROCESSLIST;Long-running queries (10+ seconds) block the pool and cascade into timeout errors.
Reverse proxies add another timeout layer. Cloudflare enforces a 100-second timeout on Free plans and 600 seconds on Enterprise. If your origin server takes 120 seconds to generate a response, Cloudflare terminates the connection with a 524 error, but users on direct connections see ERR_CONNECTION_TIMED_OUT.
Nginx as a reverse proxy has its own proxy_read_timeout:
location / {
proxy_pass http://backend;
proxy_read_timeout 90s;
proxy_connect_timeout 10s;
}If your backend is slow, raise proxy_read_timeout. But don’t go above 120 seconds—fix the backend instead. According to Google’s Web Vitals guidelines, any page taking longer than 2.5 seconds to become interactive already fails Core Web Vitals.
Check your CDN’s origin connection settings. Some CDNs retry failed origin requests, which doubles the perceived timeout. Disable automatic retries for non-idempotent requests.
Ad blockers and privacy extensions rewrite requests in ways that can trigger timeouts. uBlock Origin, for example, can block third-party scripts that the page waits for synchronously, causing the entire page load to hang.
Test in incognito mode with all extensions disabled. If the error disappears, re-enable extensions one by one.
Antivirus software is worse. Products like Kaspersky and Bitdefender intercept HTTPS connections to scan for malware. They insert their own certificate authority into the trust chain. If their scanning proxy is slow or crashes, every HTTPS request times out. I’ve spent hours debugging “server issues” that turned out to be McAfee’s SSL scanner choking on large responses.
VPNs add latency and can route traffic through overloaded exit nodes. A VPN exit node with 400ms base latency plus 10% packet loss will cause frequent timeouts. Test without the VPN to rule it out.
Not necessarily. The server could be online but unreachable due to firewall rules, routing issues, or DNS failures. Run ping and traceroute to determine if the server is actually offline or just inaccessible from your location.
Chrome waits up to 300 seconds (5 minutes) for the initial TCP connection, but most timeouts occur at the server or proxy level (30–120 seconds). The browser timeout rarely matters because upstream components enforce shorter limits.
Slow bandwidth alone won’t cause it—timeouts measure connection establishment, not download speed. But high latency (500ms+) or packet loss above 5% will. Satellite internet and congested mobile networks often hit these thresholds.
Those sites likely have stricter rate limits, aggressive DDoS protection, or stricter firewall rules. Cloudflare’s “I’m Under Attack” mode, for instance, adds a JavaScript challenge that can time out on slow connections or with certain browser extensions enabled.
Switch between Wi-Fi and cellular data to isolate the network. Clear your browser cache and try a different browser app. Restart your phone to reset network stacks. If the error persists across networks and browsers, the issue is server-side.