You click a link, the tab spins for about half a minute, and then Chrome gives up with "This site can't be reached — ERR_CONNECTION_TIMED_OUT". Nothing on the page tells you whose fault it is, which is exactly why this error wastes so much time.
The single most useful thing you can do is stop guessing and find out which side is broken first. This guide gives you a two-minute test that splits the problem into "my device / my network" versus "the server", and then the fixes that actually apply to each side. It finishes with a table of the errors that look almost identical but mean something completely different.
What This Error Actually Tells You
A timeout is not a refusal. When a server actively rejects you, the connection fails instantly and you get a different message. ERR_CONNECTION_TIMED_OUT means your browser sent a request, waited the full timeout window, and never heard anything back at all — silence, not "no".
That distinction narrows things down a lot. Silence usually means the packets are being dropped somewhere in the middle rather than answered: a firewall discarding them without a reply, a server too overloaded to accept a new connection, a route that goes nowhere, or a machine that is simply switched off.
Two Minutes to Find Out Whose Fault It Is
Do these three checks before changing a single setting. They cost almost nothing and they decide which half of this article you actually need.
- Open the same site on mobile data with Wi-Fi turned off. Loads fine? The server is healthy and the problem is your network. Still fails? The problem is more likely the server or the route to it.
- Open any other website. If everything else loads normally, this is about one specific site rather than your connection.
- Check the site from outside your network with a "is it down" service, or ask someone in another country to open it. If it works for them and not for you, you are looking at a local block, a bad DNS entry, or a geographic routing problem.
If the Problem Is on Your Side
Work down this list in order. It is arranged so the quick, harmless fixes come first and the ones that need more care come last.
- Restart the router. Unplug it for 30 seconds rather than just pressing reboot — this clears the NAT table and re-establishes the connection to your ISP. It genuinely fixes a large share of these cases.
- Turn off any VPN or proxy, then reload. A VPN with a dead exit node produces exactly this symptom, and so does a proxy configured for a network you are no longer on.
- Flush the DNS cache. On Windows run "ipconfig /flushdns" in Command Prompt; on macOS run "sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder"; on Android and iOS, toggle airplane mode on and off.
- Switch your DNS to 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare). Some ISP resolvers hold stale or blocked records long after the real ones have changed.
- Temporarily disable your firewall or antivirus web-shield and reload once. Security suites regularly block whole IP ranges by mistake. Turn protection back on immediately afterwards — this is a test, not a fix.
- Check the hosts file for a leftover entry pointing the domain at the wrong IP. It lives at C:\Windows\System32\drivers\etc\hosts on Windows and /etc/hosts on macOS and Linux. Developers do this to themselves constantly.
- Try a different browser or an incognito window. If incognito works, an extension is interfering — disable them all, then re-enable one at a time.
If the Problem Is on the Server Side
If the site fails from every network you try, the fixes above will not help — you need to look at the server itself, or wait for whoever runs it.
- Check whether the server is running at all. If it is your own VPS, log in through the provider console rather than SSH: a machine that is off or out of memory will not answer either one.
- Check the firewall rules on the server. A firewall that DROPs traffic causes a timeout, while one that REJECTs it causes an instant refusal. If you recently added a rule, that is your first suspect.
- Look for a per-IP rate limit or brute-force blocker. Tools such as CSF, fail2ban and DirectAdmin's brute-force monitor ban an IP for making too many connections too fast, and the ban usually looks exactly like this — every port dead from one address while the site works fine for everyone else.
- Check whether the web server process is up. Apache, Nginx or LiteSpeed can crash while the machine itself stays online, so the server pings but nothing listens on port 80 or 443.
- Check server resources. A machine that has run out of RAM or hit its CPU limit will accept connections so slowly that they time out before completing.
- Confirm the DNS record points at the IP the site is actually hosted on. A record that still points to an old server after a migration produces a timeout that no amount of local troubleshooting will fix.
Errors That Look the Same but Are Not
These get mixed up constantly, and chasing the wrong one wastes hours. The useful question is always: how far did the connection get before it failed?
| Message | How far it got | Most likely cause |
|---|---|---|
| ERR_CONNECTION_TIMED_OUT | No answer at all | Firewall dropping packets, server down, IP banned |
| ERR_CONNECTION_REFUSED | Server answered "no" instantly | Nothing listening on that port, or the service has stopped |
| ERR_NAME_NOT_RESOLVED | Never got past DNS lookup | Domain does not exist, expired, or DNS is misconfigured |
| DNS_PROBE_FINISHED_NXDOMAIN | Never got past DNS lookup | Same family as above — DNS could not find the domain |
| 504 Gateway Timeout | Reached the server, which then timed out upstream | Backend or PHP process too slow; the front-end server is fine |
| ERR_CONNECTION_RESET | Connection opened, then was cut mid-way | Middlebox, unstable link, or the server killed the connection |
Tired of your site timing out under load?
Cloud VPS with dedicated CPU and RAM, NVMe storage and a 99.9% uptime guarantee — from ฿150/month.
Frequently Asked Questions
Why does this only happen on one site while everything else works?
Usually one of three things: your IP has been banned by that server's security software, your DNS is returning a stale address for that specific domain, or a firewall rule is blocking that one destination. Test the site on mobile data — if it loads there, your home network or IP is the one being blocked.
Does restarting the router really help, or is that just something people say?
It genuinely helps, and often. Unplugging it clears the NAT translation table and forces a fresh connection to your ISP, which resolves stuck sessions and stale routes. Pull the power for a full 30 seconds — pressing a reboot button does not always clear the same state.
I got banned by the server. How long does that last?
Most brute-force blockers apply a temporary ban of roughly 10 to 30 minutes and lift it automatically. Repeat offences escalate to permanent bans. The tell is that ping still works while every TCP port times out — ICMP is usually allowed through while TCP is dropped.
Could my own website be doing this to visitors without me knowing?
Yes, and it is more common than people expect. An overloaded shared-hosting account, a firewall rule added during an emergency and forgotten, or a security plugin banning legitimate visitors will all produce timeouts that you never see yourself, because your own IP is whitelisted. Check the site from mobile data or a different country before assuming it is fine.
How do I know if it is time to move to a better server?
If timeouts appear when traffic rises and clear up when it falls, you are hitting a resource ceiling rather than a configuration bug. Shared hosting is the usual culprit, since your account competes with everyone else on the machine. Moving to a VPS with dedicated CPU and RAM removes that particular failure mode entirely.
GUIDES
Related articles
Keep reading on similar topics
504 Gateway Timeout — And Why Raising the Timeout Is the Wrong Fix
A 504 means the backend was reachable but too slow to answer in time. The instinctive fix — raise the timeout — turns a fast error into a slow one and solves nothing. This guide covers what actually causes 504s and how to fix the cause instead of the symptom.
Read more
My Website Is Down — A Step-by-Step Checklist
When a site goes down the instinct is to start changing things, which usually makes the diagnosis harder. This checklist runs in order: confirm it is actually down, read what the screen is telling you, check the four things that break most often, then look at what changed.
Read more
How to Fix DNS_PROBE_FINISHED_NXDOMAIN (Site Won't Load)
Getting DNS_PROBE_FINISHED_NXDOMAIN and the site won't load? This article covers the causes and step-by-step fixes — flush DNS, change DNS to 8.8.8.8/1.1.1.1, restart, check the hosts file, and check the domain/hosting side — for every device: Windows/Mac/Android/iOS/Chrome.
Read more