ERR_CONNECTION_TIMED_OUT Fix for Website Owners

ERR_CONNECTION_TIMED_OUT means the browser opened a TCP connection to your server but never received a response within the timeout period. The request didn't fail immediately — it just sat waiting until the browser gave up.

This is different from ERR_CONNECTION_REFUSED (server actively rejected the connection) or a DNS error (couldn't resolve the domain). A timeout specifically means the server was reachable but didn't respond in time.

Is It Your Server or the User's Connection?

The first thing to establish: is your server actually responding?

# Test from your own machine
curl -I --max-time 10 https://yourdomain.com

# Test response time
time curl -s -o /dev/null https://yourdomain.com

# Test from a different location
curl -I --max-time 10 https://yourdomain.com --resolve yourdomain.com:443:YOUR_SERVER_IP

If curl times out from your own machine or from a different network, the problem is server-side. If it responds fine, the problem is likely the user's network or ISP routing.

Server-Side Causes

Web Server Not Responding

The most common cause: your web server process (Nginx, Apache, etc.) has crashed, is overloaded, or is stuck.

# Check if Nginx is running
systemctl status nginx

# Check if Apache is running
systemctl status apache2

# Check for processes using port 80/443
ss -tlnp | grep -E ':80|:443'

If the process is stopped, restart it. If it's running but slow, check server load:

top
# or
htop

Server Overloaded

Under high traffic, a server can accept TCP connections but be too busy to respond. Check:

# CPU and memory
uptime
free -h

# Active connections
ss -s
netstat -an | grep ESTABLISHED | wc -l

If CPU is pegged or connection counts are very high, the server needs either scaling or investigation into what's consuming resources.

Firewall Blocking Connections

A firewall rule change can cause connections to be accepted then dropped:

# Check UFW status
ufw status verbose

# Check iptables
iptables -L INPUT -n | grep -E "DROP|REJECT"

A timeout (rather than refused) often indicates a firewall that accepts but drops packets rather than one that actively rejects them.

PHP-FPM or Application Process Down

If Nginx is running but your PHP application is down, Nginx will accept the connection and then timeout waiting for PHP-FPM:

systemctl status php8.2-fpm
journalctl -u php8.2-fpm -n 20

Cloudflare-Specific Causes

If your domain is behind Cloudflare, a timeout usually manifests as a 522 (Connection Timed Out) error rather than ERR_CONNECTION_TIMED_OUT in the browser. A 522 means Cloudflare reached your origin server but it didn't respond in time.

If you're seeing the browser-level ERR_CONNECTION_TIMED_OUT, Cloudflare itself may be unreachable from this user's network — an unusual but possible scenario during Cloudflare incidents.

User-Side Causes

If your server is responding fine but specific users report timeouts:

• Their ISP may have a routing issue between them and your server
• Their firewall or security software may be blocking outbound connections
• They may be behind a proxy that's misconfigured
• A VPN may be interfering

Ask them to try: disabling VPN, trying a different network, or using a mobile connection as a test.

Monitoring Timeouts

Intermittent timeouts are the hardest class of problem to diagnose — they happen, resolve themselves, and leave no trace. Without monitoring, you may never know they occurred.

An uptime monitor checking your site every minute from multiple locations catches timeout events and records them with timestamps and response times. Domain Monitor does this from multiple global locations — when a timeout occurs, you see exactly when it started, how long it lasted, and which locations were affected. Create a free account.

Related Troubleshooting

• 521 vs 522 vs 524 Cloudflare Errors: What's the Difference?
• Why Your Website Loads for You but Not for Visitors
• Why Your Website Keeps Going Down at Night
• DNS_PROBE_FINISHED_BAD_CONFIG Fix