ERR_CONNECTION_REFUSED, RESET, CLOSED and TIMED_OUT: What Chrome Is Telling You

All four of these mean the same thing at the level that matters: the conversation never got far enough to have a result. Chrome tried to open a connection to a server, and the connection was refused, cut, closed or never answered - so there is no page, no status code, and nothing from the site to read.

That is what separates them from the errors people usually compare them to. A 404 or a 504 means a server answered you, in HTTP, with something. An ERR_CONNECTION_ anything means the exchange failed underneath HTTP, before any of that could happen. Chrome invents these names itself, which is why they look nothing like a status code.

The four differ in how it failed, and that difference is most of the diagnosis.

ERR_CONNECTION_REFUSED

Something answered, and what it said was no.

The machine at that address is reachable, and it actively rejected the connection on that port. Nothing is listening there, or a firewall is turning the connection away immediately rather than silently.

Most common causes, in the order you should check them: the server is not running; it is running on a different port than the one in the address; it is bound to 127.0.0.1 so it only accepts connections from its own machine; or you asked for https on a port serving plain http.

If you are a developer seeing this against localhost, it is almost always one of those four and almost never the browser.

ERR_CONNECTION_TIMED_OUT

Nothing answered at all.

Chrome sent packets into the dark and waited. This is the signature of something dropping traffic silently rather than refusing it - a firewall configured to discard rather than reject, an address that no longer routes anywhere, a VPN sending your traffic somewhere that cannot reach the destination.

The tell is the wait. A refusal comes back instantly; a timeout takes as long as the browser’s patience.

ERR_CONNECTION_RESET

The connection was open, and then it was killed mid-sentence.

Something sent a reset: the server, or more often something between you and it. Corporate proxies that inspect traffic, security software on the machine, an unstable link, or a network device that decided the connection was not allowed after it had already begun.

This is the one most likely to be caused by something other than the site. If it happens on one network and not another, you have found your answer without touching the site at all.

ERR_CONNECTION_CLOSED

Same shape as a reset, ended more politely: the other end closed the connection while the browser was still expecting more.

In practice it points at the server or something in front of it giving up part-way through - a process restarting, a load balancer dropping an idle connection, a protocol mismatch. You will also see ERR_CONNECTION_ABORTED in this family, which usually means the request was cancelled before it finished, sometimes by the page itself navigating away.

Four questions that locate it in about a minute

Whichever of the four you have, the same triage narrows it. Do them in order and stop when one answers.

• Do other sites work? No, and the problem is your connection, not the site.
• Does it work in a private window? Yes, and it is an extension, a cookie or a cached asset rather than the network.
• Does it work on another device on the same network? Yes, and it is that machine - its security software, its proxy settings, its VPN.
• Does it work on mobile data instead of wi-fi? Yes, and it is that network, which is the usual explanation for a reset that only one person is seeing.

Two of those four questions eliminate the site entirely, which is worth knowing before anybody spends an afternoon reading server logs for a failure that never reached the server.

Why these are so badly reported

A connection error produces no HTTP status and often nothing useful in the console. The page either does not load at all, or - much worse to diagnose - loads fine while one request inside it fails this way, so the site looks broken in a specific and inexplicable manner.

That second case is the one that arrives as “the save button does nothing”. No error on screen, no red text, nothing the person can quote back to you. In the network panel it is obvious and it is one line: a request in a failed state, no status, and a host beside it.

Which host matters more than anything else in the report. If the failing requests all name your own domain, it is your infrastructure or their route to it. If they name a payment provider, a maps service or a font host, the page is behaving correctly and something it depends on is not - and the reader can go and check that provider’s status page instead of yours.

The network log in a bug report carries exactly that, which is the difference between this class of bug being reproducible and being a story about something that happened on Tuesday.

The short version

• Refused: something said no, immediately. Usually nothing listening on that port.
• Timed out: nothing said anything. Usually something dropping traffic silently.
• Reset: the connection died mid-flight. Usually the network in between, not the site.
• Closed: the other end hung up early. Usually the server or something in front of it.

And none of the four is an HTTP error, which is why no status code appears next to them and why the server may have no record of the attempt at all.