ERR_CONNECTION_TIMED_OUT Fix: 7 Methods Compared (2026)

Client-Side DNS and Cache Fixes

Start here because these fixes take under two minutes and solve most timeout cases. Your local DNS cache can hold stale or incorrect IP addresses for hours after a site moves or updates.

Flush DNS cache on Windows with 'ipconfig /flushdns' in Command Prompt. On macOS, run 'sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder'. Linux users can restart systemd-resolved or nscd depending on the distribution.

Switch to a public DNS server temporarily to rule out your ISP's resolver. Set 1.1.1.1 and 1.0.0.1 (Cloudflare) or 8.8.8.8 and 8.8.4.4 (Google) in your network adapter settings. If the timeout clears, your ISP's DNS was returning bad data or timing out itself.

Clear your browser cache and disable all extensions. I've seen ad blockers and privacy extensions block tracking domains that sites use for authentication or asset loading, which triggers a timeout when the browser waits for a resource that will never arrive.

Proxy and VPN Interference

Corporate proxies and VPNs add a layer that can time out independently of the actual target server. Check your browser's connection settings (Chrome: Settings > System > Open proxy settings; Firefox: Settings > Network Settings).

If a proxy is configured but unreachable, every request will time out. Disable the proxy and test. VPN clients sometimes fail to reconnect cleanly after sleep or network changes, leaving a half-dead tunnel that drops packets.

Antivirus software with web filtering acts as a local proxy. Symantec, Kaspersky, and Avast all intercept HTTPS by installing root certificates. When their filtering engine crashes or updates, you get timeouts on all sites. Temporarily disable web filtering to test.

Firewall and Security Group Configuration

Firewall rules that DROP packets instead of REJECT produce silent timeouts. The client sends SYN packets into the void and waits until timeout. REJECT sends back a RST, which fails fast with 'Connection refused' instead.

On Ubuntu or Debian, check with 'sudo ufw status verbose'. Look for DENY rules on ports 80 and 443. For iptables, run 'sudo iptables -L -n -v' and check the INPUT chain. A missing ACCEPT rule is the same as a DROP.

Cloud providers use security groups (AWS, GCP) or network security groups (Azure). A common mistake is allowing port 22 for SSH but forgetting port 80 and 443 for HTTP/HTTPS. Log into your cloud console and verify inbound rules for 0.0.0.0/0 on those ports.

• Test external reachability: 'telnet yourdomain.com 80' or 'curl -v http://yourdomain.com'
• If telnet hangs, the firewall is dropping packets; fix the security group or iptables rule
• If telnet says 'Connection refused', the port is blocked at the network level but reachable; the web server might be stopped
• If telnet connects but curl times out, the web server is running but not responding; check application logs

Server-Side Web Service Checks

SSH into the server and verify the web server process is actually running. For nginx: 'sudo systemctl status nginx'. For Apache: 'sudo systemctl status apache2' or 'httpd' depending on the distribution.

A dead process shows 'inactive (dead)'. Restart it and check logs immediately: 'sudo journalctl -u nginx -n 50' or 'sudo tail -n 50 /var/log/nginx/error.log'. Configuration errors usually print there.

If the service is running but connections still time out, check what it's actually listening on with 'sudo ss -tlnp | grep :80'. You might see '127.0.0.1:80' instead of '0.0.0.0:80', which means it only accepts local connections. Fix the 'listen' directive in the web server config.

Application and Resource Timeout Settings

Web servers have their own timeout settings independent of the browser's. Nginx defaults to 60 seconds for 'proxy_read_timeout' and 'fastcgi_read_timeout'. If your PHP script or Node.js app takes longer, nginx closes the connection and the browser sees a timeout.

Check PHP-FPM max_execution_time in php.ini (default 30 seconds) and request_terminate_timeout in the pool config (often 0, meaning unlimited, but some hosts set it to 60). A long-running database query or external API call will hit these limits.

Resource exhaustion produces identical symptoms. Run 'top' or 'htop' and look at CPU and memory. If a process is at 100% CPU or memory is full with swap thrashing, the server is too busy to accept new connections. Check 'dmesg | grep -i kill' for out-of-memory kills.

Network Path and ISP-Level Issues

Sometimes the path between client and server is broken even when both endpoints are fine. Run 'traceroute yourdomain.com' or 'mtr yourdomain.com' to see where packets stop. A hop that shows '* * *' repeatedly is dropping packets.

ISPs occasionally have routing issues or block entire IP ranges. In support, I saw a case where an entire ASN was blacklisted by a large ISP after a spam complaint, causing timeouts for thousands of users. Testing from a mobile hotspot (different ISP) confirmed it.

Geoblocking and rate limiting can produce timeouts instead of proper 403 errors if configured poorly. Check your web server or CDN access logs for the client IP. If there are no log entries at all, the request never reached the server, which points to network-layer blocking.

Browser-Specific Troubleshooting

If one browser times out but another works, the issue is browser state. Chrome and Edge share DNS cache but have separate profile data. Firefox maintains its own DNS cache entirely.

Type 'chrome://net-internals/#dns' in Chrome or Edge and click 'Clear host cache'. For Firefox, type 'about:networking#dns' and clear from there. This is faster than flushing the OS-level cache when you only need to fix one browser.

Extensions can inject delays or block requests silently. Open an incognito or private window (extensions are usually disabled there by default) and test. If it works, disable extensions one by one in normal mode to find the culprit.

Comparison: Which Fix to Try First

For end users without server access: flush DNS, disable VPN, clear browser cache, test in incognito mode. This sequence takes five minutes and solves the majority of client-side cases.

For site owners with server access: verify the web service is running, check firewall rules with telnet, review error logs for crashes or config errors. If the service is up and logs are clean, look at resource usage and application timeouts.

The key differentiator is whether the timeout happens for everyone or just some users. If it's everyone, the server or its firewall is the problem. If it's one user or one network, start with client-side and ISP-level checks. Testing from multiple locations narrows it down fast.