Short answer. ERR_CONNECTION_TIMED_OUT means your browser sent a request but the server never replied within the allotted window. Unlike "refused," there is no explicit rejection — packets simply get lost on the way, or the server is too overloaded to answer. The main causes are server overload, routing problems, a silently dropping firewall (DROP rule), or an unstable network. The first step is to run ping example.com and traceroute example.com to see where the connection breaks.
What a connection timeout means
A timeout is "silence in response." The browser waits tens of seconds for a TCP handshake reply and, getting none, gives up. This is fundamentally different from ERR_CONNECTION_REFUSED, where the server replies with an instant rejection.
A timeout almost always relates to the network or load: packets don't arrive, are dropped at an intermediate hop, or the server can't process the connection in time.
Main causes
- Server overloaded — high traffic, low resources, slow database.
- Firewall with a DROP rule — packets are discarded without a reply.
- Routing problem — packet loss at an intermediate hop.
- Unstable connection — Wi-Fi, mobile, or a congested link.
- Geo or ISP-level block of traffic to the server.
User-side diagnostics
Determine whether packets reach the server and where they're lost:
ping example.com
traceroute example.com # macOS/Linux
tracert example.com # Windows
curl -I -v --max-time 15 https://example.comIf Ping works but curl hangs, the problem is at the application layer or a firewall. If ping fails, check traceroute for where the path breaks.
User-side fix
- Flush the DNS cache:
ipconfig /flushdns(Windows) orsudo dscacheutil -flushcache(macOS). - Disable VPN, proxy, and your local firewall, then retry.
- Switch to mobile data to rule out your ISP.
- Reboot the router and check Wi-Fi stability.
- Try a different DNS resolver (1.1.1.1 or 8.8.8.8).
Server-side fix
If everyone sees the timeout, check load and the firewall:
# Load and memory
top
free -m
# Is the firewall silently dropping packets?
sudo iptables -L -n -v | grep -i drop
sudo ufw status verboseRaise the web-server worker limits, optimize slow database queries, and make sure the firewall isn't blocking legitimate traffic with a DROP rule.
Causes and solutions
| Cause | Solution |
|---|---|
| Server overload | Scale resources, optimize the database |
| Firewall DROP | Switch to REJECT to diagnose, open the port |
| Network packet loss | Check traceroute, contact the host |
| Unstable Wi-Fi | Use a cable, reboot the router |
| ISP block | Change DNS, test from another network |
How to prevent it from recurring
Timeouts are often intermittent: the site loads, then doesn't. Catching them by hand is nearly impossible — you need continuous monitoring that records slow responses and outages and sends an alert. A multi-region check (RU/EU/US) instantly shows whether the server is globally overloaded or the issue is only in your region.
Check ping and port availability, and the HTTP checker shows the server's response time. If DNS is the culprit, see the DNS lookup. For more, read the monitoring guide.
FAQ
Why does the site load sometimes and time out other times?
An intermittent timeout points to server overload or an unstable network. Under peak load, connections queue up and can't be processed in time.
How long does the browser wait before timing out?
Usually 30–120 seconds depending on browser and OS. That's far too long for a user, so fix the cause rather than wait it out.
Will changing DNS help?
If the timeout stems from slow or broken DNS resolution, yes — try 1.1.1.1 or 8.8.8.8. But if the server is overloaded, changing DNS won't help.
How do I tell a network problem from a server problem?
traceroute shows where the path breaks. A break at the last hop means the server; a break earlier means the network between you and it.