ERR_CONNECTION_RESET: what it means and how to fix it

Chrome shows this one as "This site can't be reached", with "The connection was reset." underneath and ERR_CONNECTION_RESET at the bottom.

That second line is more informative than it looks. A reset is not a refusal and it is not a timeout. The connection opened. Something answered, the conversation started, and then it was cut before the page finished arriving.

Which means a whole category of advice is already ruled out. DNS worked. The server was reachable. Clearing your cache cannot help with a connection that was severed in transit.

What the error actually says

Chrome's internal network error list defines the code as "A connection was reset (corresponding to a TCP RST)", numbered -101. That parenthetical is the whole diagnosis: somebody sent a TCP reset packet, which is the network's way of saying stop immediately rather than closing politely.

The same failure has other names depending on where you meet it:

• Firefox calls it NS_ERROR_NET_RESET, which sits in the network section of Mozilla's own error list.
• Windows, outside a browser, reports WSAECONNRESET, error 10054. Microsoft's socket error table describes it as "Connection reset by peer", and explains it as an existing connection being "forcibly closed by the remote host", listing a peer application that stopped suddenly, a rebooted host, a disabled network interface, or a hard close as the causes.
• Linux and macOS call it ECONNRESET, which the errno manual page defines simply as "Connection reset".

Note the phrase Microsoft uses: an existing connection. That is the part that separates this error from its neighbours.

Reset, refused and timed out are three different things

These three get treated as interchangeable in most advice, and they are not. Each one tells you how far the conversation got before it failed.

So when you see a reset, you already know the server exists, DNS resolved, packets are routing, and something was listening. ERR_CONNECTION_REFUSED covers the case where nothing was listening at all, and this site can't be reached sorts out which of the family you actually have, since Chrome uses that same heading for all of them.

Thirty seconds that decide everything

Before changing a single setting, answer one question: is it one site or every site?

Open two or three unrelated sites. Then load the failing page on your phone over mobile data, with wifi switched off.

That second test is the useful one, because it takes your router, your network and your DNS resolver out of the picture in a single move. If the page loads on mobile data and not at home, the problem is inside your own setup. If it fails on both, the problem is at the site's end or somewhere between you and it.

Everything below splits along that line. Skipping this step is how people end up reinstalling network drivers to fix someone else's web server.

If every site resets

Now your machine really is involved, and there are three causes worth your time.

Antivirus or security software scanning HTTPS. This is the most common cause in this category by a wide margin. Suites that inspect encrypted traffic have to sit in the middle of every TLS connection, and when that goes wrong the connection gets cut rather than refused. Look for a setting called HTTPS scanning, SSL scanning, encrypted connection scanning or web shield, turn it off for one minute, and reload. If the page appears, you have your answer without touching anything else.

A VPN, or a VPN that is half-installed. An active VPN adds an encrypted tunnel that can reset connections when it drops. A VPN that was uninstalled badly can leave a network filter driver behind that does the same thing with nothing visibly running. Disconnect it, and if that is not enough, check whether its adapter is still listed in your network connections.

A proxy that is configured but not working. If your system is pointed at a proxy that no longer answers properly, connections can be opened and then dropped. On Windows this lives under Settings, then Network and internet, then Proxy. It should be off unless you deliberately set it.

One technical cause that is worth knowing because it is almost never mentioned: an MTU mismatch. If your connection advertises a packet size larger than something on the path will carry, small requests succeed and large ones die mid-transfer. The signature is distinctive: pages start loading and then stall, or small sites work while heavy ones reset. It turns up most often behind VPNs and on PPPoE connections. On Windows you can see the current values with:

netsh interface ipv4 show subinterfaces

A standard Ethernet connection should show 1500. A VPN adapter will normally be lower by design, which is fine. The problem is when the figure does not match what the path can actually carry, and lowering it on the affected adapter is the fix.

If one site resets and everything else is fine

Nothing you change locally will repair a server you do not control, but it is still worth knowing which of these you are looking at.

Something in the middle is cutting it

On a work, school or hotel network, a filtering appliance that blocks a site often does it by resetting the connection rather than refusing it, because a reset looks like a network glitch rather than a block. The same behaviour appears on some national filtering systems. The giveaway is that the site loads perfectly on mobile data and resets reliably on that one network.

TLS inspection that cannot cope

Corporate networks frequently decrypt and re-encrypt HTTPS to inspect it. When the appliance cannot handle a particular site's certificate or TLS configuration, the connection is cut mid-handshake. If the site is new, uses an unusual certificate authority, or has recently changed its TLS settings, this is a likely candidate. Related failures show up as ERR_SSL_PROTOCOL_ERROR or ERR_SSL_VERSION_OR_CIPHER_MISMATCH instead, depending on exactly where the handshake dies.

The server is closing connections early

If you own the site, this is where to look. A reset sent by your own server usually means one of:

• It is overloaded. When a server runs out of workers or memory, it stops accepting and tears down connections rather than queuing them. Check whether the error follows your traffic peaks.
• A request exceeded a limit. Upload something larger than the configured maximum and some setups reset rather than returning a clean error. On nginx that limit is client_max_body_size; a well-behaved server returns 413 instead, which is worth knowing because getting a reset here means something is configured unusually.
• A worker was killed mid-response. The same crashes and timeouts that produce a 502 Bad Gateway can instead produce a reset when the connection is cut before any response headers are sent.
• A firewall rule is resetting established connections. Rate limiting and intrusion prevention systems commonly reset rather than drop, specifically so the client fails fast.

On Android and on a phone

The error page is the same on mobile and so are the causes above, but phones add three of their own, and they account for most mobile reports.

A VPN profile that is installed but not working. This is the single most common cause on Android. A VPN app that has lost its session, or a work profile VPN that cannot reach its server, resets connections rather than failing visibly. Check the VPN entry in your network settings and turn it off entirely as a test, not just disconnect it in the app.

Private DNS pointing somewhere unreachable. Android lets you set an encrypted DNS provider for the whole device. If that provider is unreachable or blocking the site, connections can be cut. Setting it back to automatic takes seconds and rules it out.

Public wifi you have not signed into. On a café or hotel network you are connected but not yet authorised, and some portals reset every request until you log in. Open any plain http:// address and see whether a sign-in page appears.

The mobile data test is easier here than anywhere else: switch wifi off, load the page, and you have moved off your router, your network and your DNS in one flick.

What will not help on a phone is clearing the browser's cache and data. The reset happens before any page is fetched.

When it starts right after a server move

If a site was fine yesterday and resets today, and yesterday was when you changed hosting, the new server is almost certainly the thing doing it.

Three versions turn up repeatedly. A TLS configuration that breaks part way through the handshake, so connections open and die. A firewall or security module on the new machine, often one enabled by default, that resets connections it considers suspicious, including ordinary traffic from a configuration it has not learned yet. And a limit on the new server set lower than the old one, so uploads or long responses that worked before now get cut.

This is also the most avoidable version. The whole problem is that you find out when your visitors do, because the only way to test the new server under your real domain used to be changing DNS first. DNS Previewer gives you a link that loads the site on the new server under its real hostname before any record changes, so a reset shows up on a preview link only you can see. The WordPress migration checklist covers the rest of what is worth confirming first, and how long DNS propagation really takes explains why the broken window after a switch lasts as long as it does.

The order I'd work through it

1. Check whether it is one site or every site. Nothing else is worth doing first.
2. Load the failing page on mobile data with wifi off. That rules your own network in or out.
3. Every site failing: turn off HTTPS scanning in your security software, then disconnect any VPN, then check your proxy setting.
4. Every site, and heavy pages fail while light ones work: look at MTU.
5. One site, and it works on mobile data: something on your network is filtering it. On a managed network, that is deliberate.
6. One site, failing everywhere: the problem is at their end and there is nothing for you to fix.
7. The site is yours: check load, request size limits, and whether a firewall or rate limiter is resetting established connections.
8. It started the day you changed servers: start with TLS configuration and the new machine's firewall.

A reset is a connection that was working and got cut. Once you know whether the cutting is happening on your side or theirs, the list of possible causes gets short very quickly.