ERR_CONNECTION_TIMED_OUT: What It Is and How to Fix It

ERR_CONNECTION_TIMED_OUT is the browser reporting silence. It sent the connection attempt, waited, retransmitted per the TCP rules in RFC 9293, and heard nothing back before its patience ran out: no acceptance, and crucially no refusal either. Chrome's page for the error, listed in its connection-error help, appears after roughly half a minute of that.

The recorded lab behind this article stages the contrast that makes the error readable. A connection aimed into the TEST-NET documentation range, which RFC 5737 reserves precisely so packets go nowhere, produced nothing for a full three seconds until the client's own deadline fired. The identical attempt at a closed local port failed in 2 milliseconds with an explicit refusal. Same error page family in a browser, opposite meanings on the wire: refusal proves a machine answered you, silence proves nothing did.

Silence has only a few honest sources. The packets never reach the destination, because a route is broken or the address points at nothing, which the lab's unroutable range models exactly. The destination is off. Or, very commonly on filtered networks, a firewall is configured to drop traffic silently rather than reject it, which manufactures timeouts on purpose. Every fix below is about working out which of those silences you are hearing.

As with every connection-family error, thirty seconds of scoping halves the problem. If every site times out, your machine's path to the internet is broken at the first hops: the Wi-Fi link, the router, the modem, or the upstream provider. If exactly one site times out while the rest of the web loads, your general connectivity is fine and something specific to that destination, or to the path between you and it, is eating packets.

The everything case has an honest, boring fix ladder and it starts at the router. Restart it, and restart the modem if separate, because consumer routing gear genuinely does wedge in states where some or all flows silently die. Test wired if you can, or from another device on the same network: two devices failing identically moves the blame from your computer to the network gear, one device failing alone moves it onto that device's stack or its security software.

The one-site case earns the sharper tools. Test the site from a phone on mobile data: loading fine there means the site is up and the silence lives on your network's path to it or in its treatment of your network's address; timing out on mobile data too means the site or its infrastructure is down for everyone, and waiting beats fiddling. The "for one website" variant of this error is common enough that the cause deserves naming: it is usually a filter, a broken route, or the destination itself, and never your cookies.

First, the router and modem restart described above; it is ranked first because it is free and genuinely fixes the everything-times-out case more often than anything else. Second, check for leftover network middlemen on your machine: an OS proxy entry pointing at a dead intermediary makes requests wait on something that will never answer, and a VPN client that lost its tunnel but kept its routes sends traffic into a black hole, both producing exactly this silence. Turning those off, or fixing their configuration, restores the direct path.

Third, the resolver. A DNS answer pointing at a stale or wrong address sends your connection attempts to a machine that may silently ignore them; flushing the local cache with ipconfig /flushdns and, more durably, switching to a resolver you trust removes that class. Fourth, security software: firewall and web-protection layers that hang mid-inspection convert working connections into timeouts, and briefly disabling the web-protection module isolates that in minutes; re-enable it after the test either way.

Fifth and often skipped: the network you are on may be filtering silently by policy. Offices, schools, and some public Wi-Fi drop traffic to whole categories of destinations, and a drop-based filter presents as timeouts rather than block pages. The diagnostic is the mobile-data comparison; the remedy on a network you do not run is the administrator, not a workaround, exactly as with every managed-network case in this cluster.

Firewalls end conversations in one of two configured styles, and the error you see is the configuration leaking through. A reject rule answers unwanted traffic with an explicit refusal, which surfaces as ERR_CONNECTION_REFUSED in milliseconds. A drop rule discards the packets and says nothing, which surfaces as this error after the browser exhausts its patience. Same policy intent, opposite wire manners.

Read diagnostically, that distinction is a gift. A destination that used to refuse instantly and now times out means a rule changed from reject to drop, or a new silent filter appeared on the path. A timeout that afflicts exactly one port while others on the same host answer, for example the proxy port hanging while the web port loads, means something between you and that port is dropping selectively; the proxy-port guide covers why nonstandard ports attract exactly that treatment on managed networks. And a timeout that appears only from one network while every other network connects fine is as close as networking gets to a signed confession from that network's filtering.

Operators choose drop deliberately because silence is cheaper and reveals less to scanners, which is their right on their own edge. The flip side belongs in this guide's usual boundary: on networks you do not administer, silent filtering is policy, and the legitimate responses are asking the administrator, using a network you control, or accepting the restriction. Reading the silence is diagnosis; routing around someone's firewall is not a fix this site teaches.

The lab's third check stages a subtler failure that users experience identically: a server that accepts the connection and then never says a word. The TCP handshake succeeds, so the connection phase is fine, and then the response never comes; the client's response deadline, not its connection deadline, is what finally fires. In the recorded run the connect succeeded instantly and the silence began afterward, per the socket semantics in the Node.js net documentation.

For a site operator, that shape is a different diagnosis from the pure connection timeout. Connections that never arrive point at routing, DNS, or filtering in front of the machine. Connections that arrive and hang point at the machine itself: an application server with every worker busy, a backend waiting forever on a database or upstream API without its own deadline, or a process wedged after a deploy. The fixes are correspondingly internal: health checks that watch response time rather than port openness, deadlines on every upstream call the application makes, and worker pools sized against real concurrency so overload sheds load quickly instead of hanging everyone.

The general lesson the lab makes concrete: a timeout is not one error but a family, and where the silence begins, before the handshake or after it, tells you which half of the world to debug. Clients that record connect time and first-byte time separately hand you that distinction for free, which is exactly why the collection-pipeline section below insists on both deadlines.

For automated clients, timeouts are not an anomaly to eliminate but a budget line to engineer. Every request needs two explicit deadlines, connect and response, because the lab's two silences are different events: a connect timeout flags path or filtering problems, while a response timeout flags an overloaded or hung source. Cap retries, back off with jitter between attempts, and log the two timings separately so a shift in where the silence starts shows up in your metrics rather than in a 3 a.m. investigation.

Three pipeline-specific rules keep timeout handling honest. First, a timeout is not a rotation trigger: switching exits because a source went silent multiplies load against something that is struggling or filtering, and the stop-or-back-off discipline that applies to explicit refusals applies to silence at least as strongly. Second, timeouts consume budget: a request that burns a 10-second deadline costs more wall-clock than a fast failure, so sources that develop chronic slowness deserve a raised deadline and lowered concurrency, not more parallel attempts. Third, verify the infrastructure before blaming the source: when traffic flows through a proxy, test the exit itself with the proxy checker, because a dead or overloaded exit produces the same silence as a dead destination, and confusing the two wastes a debugging session.

For the wider map of who sits between a client and a destination, and therefore where silence can be born, the proxy fundamentals guide walks the whole chain.