ERR_CONNECTION_TIMED_OUT Error: 7 Fixes That Work (2026)

What ERR_CONNECTION_TIMED_OUT Actually Means

The error means the browser started a TCP handshake with the server but never got the SYN-ACK response back. After waiting through the timeout period, the browser kills the connection attempt and shows you the error screen.

This is different from ERR_CONNECTION_REFUSED, where the server actively rejects the connection. A timeout means the request disappeared into the network void. Either the server never saw it, or the response never made it back.

Three layers can cause this: the client machine (your laptop, phone, local network), the path between client and server (ISP routing, firewalls, DNS), or the destination server itself (web server crashed, firewall blocking inbound traffic, server out of resources). You need to test each layer methodically.

Browser and Local Machine Fixes

Start here because these fixes are fast, safe, and solve about 40% of timeout cases I see in tickets.

Clear your browser cache and cookies. Corrupted cache entries can cause the browser to request stale or broken resources. In Chrome, go to Settings > Privacy and security > Clear browsing data, select Cached images and files, and clear the last 24 hours. In Firefox, Options > Privacy & Security > Cookies and Site Data > Clear Data.

Disable browser extensions. Ad blockers, privacy tools, and VPN extensions can intercept requests and introduce delays or blocks. Open an incognito window (which usually disables extensions by default) and try the URL again. If it loads, go back and disable extensions one by one to find the culprit.

Flush your local DNS cache. Your machine caches DNS lookups, and a stale entry can send requests to the wrong IP or a server that no longer exists. On Windows, open Command Prompt and run ipconfig /flushdns. On macOS, run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder. On Linux, restart systemd-resolved with sudo systemctl restart systemd-resolved or clear nscd cache if you run it.

Try a different browser. If Chrome times out but Firefox works, the problem is browser-specific (likely cache or extension related). If all browsers fail, move to network and server checks.

Network and DNS Troubleshooting

If browser fixes didn't work, the problem is upstream—between you and the server.

Test from a different network. Use your phone's mobile data or a different WiFi network. If the site loads on mobile data but not your home or office network, your local network or ISP is blocking or misrouting the traffic. Check your router's firewall rules and any corporate proxy settings.

Verify DNS resolution. Run nslookup example.com or dig example.com from the command line. Check that the domain resolves to the expected IP address. If you get NXDOMAIN or the wrong IP, your DNS server has stale or incorrect data. Try switching your DNS to 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare) temporarily to rule out your ISP's DNS.

Check your local firewall. On Windows, open Windows Defender Firewall and verify that your browser is allowed outbound on port 80 and 443. On macOS, System Preferences > Security & Privacy > Firewall > Firewall Options, and make sure your browser isn't blocked. On Linux, run sudo iptables -L -n and check for DROP rules on outbound ports.

Test with curl or wget. Open a terminal and run curl -I https://example.com or wget --spider https://example.com. If these succeed but the browser fails, the browser is the problem. If curl times out too, the issue is network or server-side, and you've ruled out the browser entirely.

• nslookup example.com — verify DNS returns the correct IP
• curl -I -v https://example.com — test raw HTTP connection and see SSL handshake details
• traceroute example.com or tracert example.com — find where packets stop along the route
• ping example.com — check basic ICMP reachability (note: some servers block ICMP, so a failed ping doesn't always mean the server is down)

Server-Side Fixes: When the Problem Is on Your Host

If the site times out from every device and network, the server is the problem. This is where hosting customers and support engineers spend most of their time.

Check if the web server process is running. SSH into your server and run systemctl status nginx (or apache2 or httpd depending on your stack). If the service is stopped, start it with sudo systemctl start nginx. Check the logs immediately after starting: sudo journalctl -u nginx -n 50 will show the last 50 lines and often reveal why it stopped (config syntax error, port already in use, permission issue).

Verify the firewall isn't blocking port 80 or 443. Run sudo iptables -L -n and look for rules that DROP or REJECT traffic on ports 80 and 443. If you use ufw, run sudo ufw status verbose. A common mistake is enabling ufw without allowing HTTP/HTTPS first. Fix it with sudo ufw allow 80/tcp and sudo ufw allow 443/tcp, then reload with sudo ufw reload.

Check for resource exhaustion. Run df -h to see disk usage. A full disk (100% on /) will crash the web server or prevent it from writing logs, which causes timeouts. Run free -h to check memory. If you're out of RAM and swap, processes get killed by the OOM killer. Run top or htop and look at load average—if it's consistently above the number of CPU cores, the server is overloaded and can't respond to new requests in time.

Review web server error logs. For Nginx, check /var/log/nginx/error.log. For Apache, /var/log/apache2/error.log or /var/log/httpd/error_log. Look for lines like "too many open files," "upstream timed out," or "cannot assign requested address." These point to misconfigured limits (file descriptors, worker connections, backend timeouts).

Side-by-Side Comparison: Which Fix to Try First

Here's how the three categories compare in terms of likelihood, time to test, and risk.

• Browser/local (40% of cases): Takes 2-5 minutes to test. Zero risk—clearing cache and disabling extensions won't break anything. Start here every time.
• Network/DNS (35% of cases): Takes 5-10 minutes. Low risk—changing DNS servers or testing from mobile data is reversible. Do this second if browser fixes fail.
• Server-side (25% of cases): Takes 10-30 minutes depending on access and complexity. Medium to high risk—restarting services, changing firewall rules, or editing web server configs can break a working site if done wrong. Always verify you have backups before touching production server settings, and test changes in a staging environment when possible.

When to Escalate and What to Tell Your Host

If you've tested from multiple devices and networks, cleared browser cache, flushed DNS, verified the server process is running, checked firewall rules, confirmed disk and memory aren't full, and the error still appears, you're dealing with something deeper—probably upstream routing, DDoS mitigation rules, or an edge case in server config.

Contact your hosting provider with specifics. Don't just say "my site is down." Give them the domain, the exact error (ERR_CONNECTION_TIMED_OUT), the results of your curl test, the output of systemctl status for your web server, and the last 50 lines of the error log. That's what I need to see in a ticket to skip the basic troubleshooting and go straight to the root cause.

If you suspect a DDoS or traffic spike, mention it. Hosts often have rate limiting or IP blocking at the edge that can cause timeouts for legitimate traffic when under attack. They can whitelist your IP or adjust thresholds.

Prevention: Monitoring and Config Hardening

Set up uptime monitoring. Use a service like UptimeRobot, Pingdom, or a simple cron job with curl that alerts you when the site stops responding. Catching a timeout within minutes instead of hours saves customers and revenue.

Configure web server timeouts correctly. Nginx's proxy_read_timeout and Apache's TimeOut directive should match your application's slowest expected response time, plus a buffer. If your backend can take 20 seconds to render a page, set the timeout to 30. Don't set it to 300 because that hides performance problems instead of surfacing them.

Monitor resource usage. Set up alerts for disk usage above 80%, memory usage above 85%, and load average above your core count. These are early warnings that your server is about to start timing out under load.

Keep logs. Rotate them so they don't fill the disk, but keep at least 7 days of history. When a timeout happens, logs are the only record of what the server was doing at that moment.