ERR_CONNECTION_RESET: What It Means and How to Fix It

Every guide ranking for this error prescribes the same ritual: restart the router, switch DNS resolvers, clear the cache, reset the browser. Those steps address failures that happen before a connection exists, and this error reports the opposite. ERR_CONNECTION_RESET is Chrome's name for one precise wire event: a TCP segment carrying the RST flag arrived on a connection that already existed. Name resolution worked, the handshake completed, your request went out. Then something ended it.

Under RFC 9293 a reset aborts a synchronized connection immediately: no orderly shutdown, no guarantee that data in flight was delivered. Chromium's network error list defines -101 as a connection reset corresponding to a TCP RST, against -100 for a clean close corresponding to a TCP FIN.

That single fact carries the diagnosis. Sending a reset your system accepts means being party to the connection, with its exact addresses, ports, and sequence state, so a bystander cannot do it. The sender was the server, or something in the path holding one end.

Read that by phase, not by symptom. The first two rows are failures to establish; the last two happen after setup succeeded, which makes them a decision rather than an absence. A closed port also answers with a reset, but before any connection exists, so your system calls it a refusal.

The symptom people describe in forum threads, a page that renders halfway, an image that stops in a band of grey, a download that dies at eighty percent, is this mechanism showing through: a reset can land after the response starts.

A loopback lab reproduces the whole set against one server. Recorded on Node v24.14.0 on 2026-07-29:

node scripts/verify-connection-reset-lab.mjs

PASS  baseline request → 200 complete  (outcome=complete)
PASS  accepted connection reset before response → ECONNRESET  (outcome=ECONNRESET)
PASS  reset mid-response → 200 headers received, then ECONNRESET  (headers=200, outcome=ECONNRESET, bodyBytesKept=44)
PASS  closed port → ECONNREFUSED, a different error at a different phase  (outcome=ECONNREFUSED)

checks passed: 4/4

Read the third line. The response genuinely started: status 200, headers delivered, a declared body of 1000 bytes. Then the reset arrived, the client kept 44 bytes, and the other 956 never came. The line above is the same server resetting before it wrote anything, which yields no status at all; the line below is a port with nothing listening, failing earlier with a different code. Same client, same host, same second: only the peer changed.

How much survives is not fixed, because a reset can make the receiving system discard data it buffered but never handed to the application, so the same URL fails at a different point each time. Get that detail on the site failing you with curl -v, documented in the curl manual: read which line is the last successful one, and whether it fails every time or intermittently.

Start with the participant you can inspect: software on your own machine. On personal devices this is the most common cause, and the one the popular guides never name. The two community answers that actually solved this error landed here, on a VPN client's web-protection feature and on a service running on a restricted network. Neither was a router or DNS fault.

Security products cannot read HTTPS from the side. An antivirus suite with web protection, a VPN client's threat-blocking module, or a corporate gateway installs its own root certificate, terminates your TLS session, and opens a second one to the real server. That is structurally the position a proxy server occupies: two connections, one intermediary holding both ends, which is exactly what lets it reset you.

Three things make it use that ability. A rule matches on category, reputation, or signature, and the product ends the connection instead of serving a block notice. Or it cannot handle what it sees: a certificate chain it refuses, an unfamiliar TLS extension, an unimplemented protocol version. Or it broke in an update, which is why resets that start on one date trace so often to a security product release.

Test it without leaving yourself exposed. Pause the HTTPS-scanning module rather than the whole product, load the one page, then switch it straight back on. If the page loaded while it was paused, the durable fix is an exception rule or a vendor update, not running unprotected. An intermediary you configured yourself is a participant too: verify its exit with the proxy checker, and the proxy versus VPN comparison covers what each sits inside.

If the inspector belongs to your employer or school, stop at the diagnosis: that inspection is deliberate policy on equipment you do not administer, and the reset is the policy working. Send IT the URL and timestamp.

Change one variable at a time before you change any setting.

One site or all sites. Resets everywhere point at something on your machine or network that touches every connection. Resets on one site while the rest of the web loads point at that site, its edge, or a rule naming it.

One browser or all browsers. Chrome, Edge, Brave, and Opera are all Chromium and all read the operating system's proxy configuration by default, so they tend to fail together, while Firefox keeps its own connection settings and certificate store. Failing everywhere puts the cause below the browser. Failing across the Chromium family while Firefox works points at the system proxy configuration, or at an installed root certificate. Failing in one browser alone makes it that profile: retest in a fresh profile with extensions off.

One network, or one device. Put the same laptop on a phone hotspot: working there moves the investigation onto the failing network's equipment and its policy. If a phone on that same Wi-Fi loads the page, your machine's software owns the problem.

Then fix in order of likelihood: inspecting software first, then a stale system proxy entry an uninstalled VPN or security tool left pointing at nothing, then the network. Cache clearing, DNS changes, and browser resets belong last, because none of them changes who sends a reset.

A dual-stack machine has two routes to any site publishing both an A and an AAAA record, and they fail independently. RFC 8305, Happy Eyeballs v2, protects you from a broken IPv6 path by giving IPv6 a short head start and racing IPv4 behind it, so a v6 attempt that fails or stalls costs a fraction of a second.

The gap is that the race only covers setting the connection up. RFC 8305 says so: it handles initial connection failures at the IP layer, while other failures can still affect the connection it picked. If the IPv6 handshake succeeds and the reset arrives afterwards, from a tunnel endpoint, a transition relay, or a firewall that filters v6 differently from v4, no fallback is left. Hence the signature complaint: a few sites reset consistently on one network while everything else is fine.

Two commands settle it, using curl's address-family flags:

curl -4 -sSI https://example.com/
curl -6 -sSI https://example.com/

If IPv4 returns headers and IPv6 resets, you have found the layer, and the IP diagnostic confirms which family a site saw.

Then repair the path, not the symptom. Windows turns on 6to4 tunneling by default whenever an interface holds a public IPv4 address, and Microsoft's IPv6 configuration guidance covers switching those tunnel interfaces off. The same page says disabling IPv6 itself is not recommended, because Windows components depend on it, and points instead at a prefix policy preferring IPv4. Advice that disables a networking service does the same thing indirectly, and repairs nothing.

Two unrelated mechanisms get filed under one complaint on wireless links.

The first is connection state that stopped existing. Routers, office firewalls, and mobile carriers keep a table mapping your connection to a public address, and those entries expire. When one is reaped while your connection sits idle, or your laptop roams and its address changes, your next packet reaches a device with no record of that conversation. The standard answer to a segment matching no connection is a reset. That is why long downloads, video calls, and websockets break on a weak link while ordinary page loads look fine.

The second is other people's equipment. Carrier networks, hotel and airport Wi-Fi, and guest networks commonly run transparent filters and captive portals, which is the previous section again on premises you do not control. An unfinished captive portal sign-in is the most common version, and loading any plain HTTP page usually pulls its screen into view.

That mix is why resetting network settings sometimes appears to work. It clears saved networks, a stale lease, a manual proxy or DNS entry, an on-device VPN, and any configuration profile at once, so if one of those was the cause the symptom vanishes and you never learn which. If none was, you have lost every saved Wi-Fi password for nothing. Do the targeted version first: switch off any VPN or ad-blocking app for one request, since many run as a local VPN by design, then check the network's manual proxy setting, which on Android lives under the saved network's advanced options.

On 127.0.0.1 there is no ISP, no router, and no CDN. There are two participants and you wrote one, which makes this the most solvable version.

First, the server died mid-response, which is exactly what the lab's third check reproduces. An out-of-memory kill, a dev server restarting on a file change, or a process manager recycling a worker after a request limit all abort connections in the middle of answering. Read process exit codes and restart timestamps rather than the request log, because the request rarely got far enough to be logged.

Second, protocol mismatch. Plain HTTP sent to a TLS port, or an https:// URL aimed at a plaintext listener, hands the listener bytes it cannot read as a handshake, and many servers abort instead of answering. If one scheme works on a port and the other resets, that was it. The port and protocol guide covers which listener expects which conversation.

Third, the keep-alive race, the intermittent one that costs teams days. Your client holds a pooled connection open and the server closes it on its own idle timeout. If your client picks that connection at the moment the server's timer fires, the request lands on a socket the server has already discarded. It clusters in quiet periods, when connections idle long enough to time out. Set your client's idle timeout below the server's, and below any proxy between them, then retry an idempotent request once.

Any dev proxy, tunnel, or container port forward is one more participant that can reset, so test the service directly first.

Resets you cause usually leave nothing in the application log. The connection died below your framework or was killed by a layer in front of it, so as far as your code is concerned the request never finished or never existed. The missing line tells you which layer to inspect. Count connection-level failures separately from status codes, because a reset never becomes one.

In rough order of frequency. Workers dying mid-response: out-of-memory kills, a process manager recycling on a request cap, or a deploy that restarts without draining connections in flight. That shows up as a steady small percentage of failures rather than an outage, and the evidence sits in kernel and process-manager logs.

Then TLS termination and limits: a load balancer sending decrypted traffic to a backend that expects TLS or the reverse, an SNI mismatch, a minimum protocol version that cuts off older clients, or a request-size limit that drops the connection instead of returning a status code. The tell for the first three is failure confined to a subset of clients.

Last, a decision rather than a fault. Firewall and anti-abuse products usually let a rule either serve a block response or drop the connection, and dropping is worse for both sides: your visitor gets an unexplained browser error with nothing to act on, and you get no status code to count. If you filter traffic, answer with a status code and a short page naming the policy and a contact.