How to fix a connection timed out error

A "connection timed out" message is different from most other browser errors in one important way: the domain resolved correctly, the browser knew exactly which server to talk to, and it sent the request — it just never got an answer back within the time it was prepared to wait. That distinction narrows down where the fault actually is.

Compare it with a DNS failure, which happens before any connection is even attempted, or a 5xx error, which means the server answered and then failed. A timeout sits between the two: the server was reachable enough to receive a connection attempt, but something stopped it from responding.

What usually causes it, in order

1. The server is overloaded and can't respond in time

This is the most common cause on shared hosting. If a site is receiving unusually heavy traffic, running a resource-intensive script, or waiting on a slow database query, the server can become too busy to accept new connections within the timeout window — typically somewhere between 30 and 120 seconds depending on the browser and any proxy in front of it.

The tell is intermittency: the site loads sometimes, times out other times, especially under load. Check your control panel's resource usage graphs for a spike in CPU or process count around the time of the failure.

2. A firewall or security rule is silently dropping the connection

Some firewalls respond to a blocked request with an outright rejection, which produces "connection refused" quickly. Others are configured to drop the packet with no response at all, which the visitor experiences as a slow, eventual timeout rather than an instant error. If a security rule was recently added — an IP block, a rate limit, a country-level restriction — check whether it might be catching legitimate traffic as well as the traffic it was meant to stop.

3. DNS is pointing at the wrong, or an unreachable, address

If a domain's DNS record still points at an old server — after a migration that wasn't fully completed, for instance — requests are sent to an address where nothing is listening on the expected port, or where the destination itself has since been decommissioned. Confirm what the domain currently resolves to:

nslookup yourdomain.com
dig +short yourdomain.com

Compare the IP address returned against the one your hosting account actually uses, which you can find in your control panel.

4. A network path problem between you and the server

Occasionally the fault is neither the site's nor the visitor's alone, but the network route between them — a problem at an intermediate network, a misbehaving local router, or a VPN that is dropping packets. This explains a timeout that only one visitor experiences, on one network, while everyone else reaches the site normally.

5. A proxy or CDN in front of the site is waiting on a slow origin

If the site sits behind a CDN or reverse proxy, that layer has its own timeout for how long it will wait on the actual server before giving up — and the browser then sees the CDN's timeout response, not the server's. This shows up as a fault that traces back to slow processing on the origin server rather than the network itself. Our guide on diagnosing a slow first byte covers finding what's actually taking the time.

Checking whether it's genuinely the server

A quick way to separate "the server is slow" from "something is blocking the connection outright" is to test the port directly:

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

If this also hangs and times out, the problem is on the server side or somewhere in the network route to it. If it connects but the page takes a long time to actually load content, the server is reachable and simply slow to respond — a performance problem rather than a connectivity one, and a different fix.

What to check on your side of the account

• Recent traffic. Check your control panel's visitor or resource statistics for a spike around the time the timeouts started.
• Recently changed code. A slow database query or an infinite loop introduced by a recent update can tie up server resources long enough to cause timeouts for other requests.
• Scheduled tasks. A cron job or backup running at the same time as the fault is a common, easily overlooked coincidence worth ruling out.

If it keeps happening

Note the exact time of each occurrence, the URL, and whether it happens for every visitor or only some. That pattern — constant versus intermittent, one visitor versus everyone — is the single most useful thing you can hand to support, because it tells us whether to look at server load, a firewall rule, or DNS first rather than checking all three from scratch.