ERR_CONNECTION_TIMED_OUT means your browser found the server's address, sent a connection request, and heard nothing back before it gave up, roughly half a minute of pure silence. Nothing refused the connection and nothing failed loudly. The request simply disappeared into the network and no answer ever returned.
Silence is the hardest symptom to diagnose because almost anything can cause it: a server that is down or drowning, a firewall silently dropping packets, a routing problem between you and the host, or something as small as a bad proxy setting on one laptop. This article gives the silence a structure. First how to tell whether the problem is on your side or the server's, then the fixes for each side in the order that finds the culprit fastest, and finally how site owners make sure they hear about the silence before their visitors start describing it.
Timed out versus refused: two different failures
It helps to know what this error is not. When a server is reachable but nothing is listening on the port, the connection is rejected instantly and Chrome shows ERR_CONNECTION_REFUSED, an active no delivered in milliseconds. A timeout is the opposite: no yes, no no, no evidence that the packets arrived anywhere. That distinction narrows the suspects considerably. Rejection proves the network path works and blames the server's configuration. A timeout implicates the entire path, from your Wi-Fi to the destination's firewall, and the diagnostic job is to find where along that path the packets die. The two errors pair up often enough that we cover the other half in ERR_CONNECTION_REFUSED.
The classic producer of a timeout is a firewall configured to drop traffic rather than reject it. Dropping is a common security default precisely because it wastes an attacker's time, but it wastes a legitimate visitor's time the same way, thirty seconds per attempt, with an error message that points nowhere.
First, establish which side is silent
The one-minute triage is the same as for any connectivity error and it is worth doing before touching a single setting. Try another website: if everything times out, your connection or router is the story, not the site. Try the same site from your phone on mobile data: if it loads there, the site is alive and your network or device is the problem. If the site times out on every network you can reach, the server side is where the failure lives, and if it is not your server, the honest answer is that you wait, because visitors cannot fix a host that will not answer.
One refinement is worth adding. A site can be down for one region and fine for another, because the failure lives in a network path rather than the server itself. That is why a second opinion from a geographically distant checker beats a second opinion from the phone in your pocket, and it is exactly the situation described in Odown's breakdown of what network outages are and why they rarely look the same from two places at once.
Fixes on the visitor's side
Restart the router and modem. Unglamorous and disproportionately effective. Home routers accumulate state, NAT tables, DNS caches, half-dead connections, and a power cycle clears all of it in two minutes.
Check the proxy settings. A stale or malicious proxy configuration sends every request to a middleman that no longer exists, which produces timeouts on everything. On Windows, open the system proxy settings and make sure no unexpected proxy or automatic configuration script is enabled; on macOS, the same check lives in the network settings for the active connection.
Pause the firewall and antivirus, briefly. Security suites that filter web traffic sometimes hold or drop connections they should pass. Disable the web-shield component for one minute and retest. If the site loads, do not leave protection off; add an exception and turn it back on.
Flush DNS and try another resolver. A stale lookup can point you at an address that no longer answers. Run ipconfig /flushdns on Windows or the macOS equivalent, then, if the problem persists, switch the connection's DNS to 1.1.1.1 or 8.8.8.8 so a fresh, independent source supplies the address.
Inspect the hosts file. An old entry pinning the domain to a dead IP produces a perfect, permanent timeout on one site only. The file lives at C:\Windows\System32\drivers\etc\hosts on Windows and /etc/hosts on macOS and Linux; any line mentioning the affected domain should justify its existence or be deleted.
Fixes on the server's side
When it is your site timing out, start by confirming the machine is alive through a channel other than the website: SSH in, or open the hosting provider's console. If you cannot reach it at all, the incident is at the host level and their status page is the next stop. If you can log in, check load and memory first, because a server at the edge of its resources accepts some connections and lets others starve, which users experience as intermittent timeouts long before a full outage.
Next, interrogate the firewall, since it is the most common cause of a server that is running yet silent. Confirm that ports 80 and 443 are open in every layer that has an opinion: the operating system firewall, the cloud provider's security groups or network rules, and any DDoS protection or rate limiter in front. A rule that drops rather than rejects will pass every internal test you run from the server itself while timing out the entire outside world. Then verify that DNS points at the address you think it does, because a record left pointing at a decommissioned server produces timeouts that no amount of debugging on the new server will explain. Ping answering while the website times out is a useful clue here: it means the machine is reachable but the web port specifically is blocked or the web service is not listening.
Common mistakes in fixing ERR_CONNECTION_TIMED_OUT
Assuming the ISP is at fault. The ISP is occasionally the problem and constantly the scapegoat. Run the mobile-data test first; it settles the question in ten seconds.
Treating ping as proof the site is up. Ping tests ICMP, not the web port. A server can answer pings cheerfully while a firewall drops everything aimed at 443.
Opening the firewall wide to test. Disabling the whole firewall does prove the firewall was the problem, at the cost of exposing everything else. Add the specific rule for 80 and 443 instead and keep the rest closed.
Debugging from inside the network. Requests from the server to itself, or from the office that hosts it, skip the layers where the failure usually lives. Always test from an outside network before concluding anything.
Waiting without a signal. If the site is yours and it is timing out, waiting for a customer email to tell you is the most expensive detection method available. External checks exist for exactly this.
FAQ
Why does only one website time out for me?
Because the failure is specific to the path between you and that host: a hosts file entry, a stale DNS answer, a filter on your network, or that site's own outage. If it also times out on mobile data, it is the site; if not, it is your side.
How long does Chrome wait before showing this error?
On the order of thirty seconds, though the exact patience varies by platform and by which stage of the connection stalls. The practical point is that a timeout means sustained silence, not a momentary blip.
Is ERR_CONNECTION_TIMED_OUT my fault or the website's?
Either, and that is the frustration. The triage in this article, other sites, other devices, other networks, assigns the blame in under a minute, which is faster than any individual fix.
Can a website be timed out in one country and fine in another?
Yes. Routing problems, regional CDN failures, and geo-specific blocking all produce exactly that pattern, which is why serious monitoring checks from multiple regions rather than one.
Closing thought
A timeout is the network's way of giving you nothing to work with, so the method matters more than the fix: establish which side is silent, then walk that side's short list in order. Visitors solve their half with a router restart, a proxy check, and a fresh resolver. Owners solve theirs by proving the service is listening and that every firewall layer between the process and the public actually says yes.
The uncomfortable property of server-side timeouts is that the server itself feels fine from the inside. Odown exists for that blind spot: it attempts real connections to your site from 17 locations around the world, around the clock, and tells you the moment the outside world starts hearing silence, with response-time history that shows the slowdown that usually precedes it.
