Connection timed out error

What a timeout is

A connection timed out message means the client sent a request, waited for the open or the response, and the network gave up before an answer arrived. Unlike a connection refused error, where the server answered "no", a timeout means silence. The inevitable phrase in the browser is ERR_TIMED_OUT or ERR_CONNECTION_TIMED_OUT, and the fix cannot be guessed; it has to be traced.

Three timeouts that look alike need different fixes:

Read the timeout

A timeout has a length. Some browsers wait around 30 to 60 seconds before reporting the timeout, but the server has its own timeout too: max_execution_time in PHP and proxy_read_timeout in nginx, to name two. The fix differs because a client side timeout needs a network fix, while a server side timeout needs a code or database fix.

The test that separates them is curl, which reports where it stopped. Run it and read the exit:

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

If it ends with Could not connect, the TCP handshake itself failed. If it connects and then hangs, the problem is the server. Compare the two paths:

curl --connect-timeout 8 https://example.com/  # connect attempt
curl --max-time 20 https://example.com/         # full page with long answer

Trace the route

When the connect phase fails, walk the route. A ping tests the host; traceroute (Windows: tracert) shows each hop and where packets stop. A frequent story is the last hop to the datacenter dropping while the rest of the path is clean, which points to a firewall or an edge filter, not to your laptop.

1. Ping the domain, then the IP directly: ping 203.0.113.10 after nslookup example.com. If the IP answers but the name does not, DNS is set.
2. Run tracert example.com and compare paths from two different networks, e.g. your phone on mobile data.
3. Test the destination port specifically: Test-NetConnection example.com -Port 443 (Windows) or nc -zv example.com 443 or curl -v https://example.com/.
4. Probe an alternate IP, like a relay host or a CDN, to say whether the block is at the host or at the network.

The common findings: a firewalled server drops SYN before the handshake, so the external test times out; the ISP's transit is the weak link; or the origin's IP is blocked by an IP allowlist from a stale office network.

Server side time out

If the route reaches the server but the response never completes, the timeout is an app or database problem. A page that answers nothing for 60 seconds and then dies is the classic signal of a slow query holding the connection. Fixes:

• Check the load and the slow query log: a locked table or a dozen heavy queries.
• Fix the origin's own timeout so misbehaving requests fail fast instead of piling up: set proxy_read_timeout or the app keep-alive lower.
• Raise the request limit only when the work genuinely needs a minute, not to hide a slow query.
• Read the connection pool: too many waits against MySQL or Redis push the wait past the timeout.

Prevention

• Alert on the timeout itself, not the page: a monitoring probe that fails after 60 seconds has to alert at 15 seconds to catch a slow grind.
• Set connect and response timeouts to sensible values in curl and the server. A misfired page-feed keeps retrying not only the browsers but also search engines and uptime bots.
• Retain the error in the server log; a timeout well in the past with no correlation is entries for a later session.