---
title: "How to Fix err_connection_reset (Connection Reset by Peer)"
description: "err_connection_reset means an open connection to the site was cut by a reset signal. How to find who cut it and fix it on a computer, a phone and in code."
url: https://proxynet.io/blog/err-connection-reset
date: 2026-10-06
author: "Acar Diveroli"
category: "Tutorial"
lang: en
---

# How to Fix err_connection_reset (Connection Reset by Peer)

You are halfway through an order. You click the button, the tab spins for a second, and Chrome shows "This site can't be reached" with "The connection was reset." under it and `ERR_CONNECTION_RESET` at the bottom. Firefox says it in one line: "The connection was reset". Other sites open fine, and a minute later this one might too.

Below: what a reset is, who can send one, how to find where yours came from, the fixes on a computer and a phone, what to check if the site is yours, and the same error in code, where it is called "connection reset by peer", `ECONNRESET` or `WinError 10054`.

> **Note: Short answer**
>
> `ERR_CONNECTION_RESET` means a connection to the site was open and then something ended it at once with a TCP reset (RST) signal. The sender can be the site's server, security software on your computer, a browser extension, a VPN or proxy, or a filter on the network, and the browser cannot tell which. Reload once, then try a private window, another browser and your phone over mobile data; where it works shows where the reset comes from. If one site fails only on one network, a device on that network is cutting it, and no setting on your computer changes that.

## What does ERR_CONNECTION_RESET mean?

Before a page loads, your browser and the site's server open a connection, a two-way line that stays open while data goes back and forth. A reset ends that line in the middle. Chromium's [list of network errors](https://chromium.googlesource.com/chromium/src/+/HEAD/net/base/net_error_list.h) describes code -101 as a connection that "was reset (corresponding to a TCP RST)". Chrome, Edge, Brave and Opera share that list, so they show the same code.

The difference from its neighbours is timing. With `ERR_CONNECTION_REFUSED` the line never opened; with `ERR_CONNECTION_TIMED_OUT` nothing answered. A reset comes after the line was working. The other codes on this grey screen are compared in [This Site Can't Be Reached](/blog/this-site-cant-be-reached).

## How does a connection get reset?

TCP, the protocol that carries web pages, can end a connection two ways: a polite close that finishes sending first, or a reset that stops everything now. [RFC 9293, section 3.5.2](https://www.rfc-editor.org/rfc/rfc9293.html#section-3.5.2) lets a program issue a reset at any time, and TCP sends one itself when a packet arrives for a connection the machine no longer knows.

1. Your browser opens a connection and, on `https://` sites, sets up encryption (TLS).
2. It sends the request and starts reading the answer.
3. Somewhere on the route, a program decides the connection must end, or a machine gets a packet for a connection it has forgotten. It sends a reset.
4. Your computer drops the connection the moment the reset arrives, and Chrome shows the error.

A reset carries no reason and looks as if the site sent it, but a device in the middle can send one in the site's name. Researchers at ICSI and UC Berkeley documented [forged TCP resets](https://www.icir.org/vern/papers/reset-injection.ndss09.pdf) from traffic control products used by internet providers, anti-virus systems and national filters. The browser can say "reset", never "reset by whom".

## Who can send the reset?

| Who | Why | Typical sign | First step |
|---|---|---|---|
| The site's server | Restart, crash, connection limit | Fails for everyone, comes and goes | Reload later |
| Security software | "Web protection" or "HTTPS scanning" | Every browser on one computer | Pause web protection for one test |
| A browser extension | VPN, proxy or ad-blocking add-on | One browser; private window works | Turn extensions off |
| A VPN or proxy | Tunnel dropped, idle connections closed | Only while it is on | Turn it off |
| A network filter | A rule at work, school or the provider | One site, every device on one network | Ask the administrator |
| Router or line | Brief fault | Several sites for a few minutes | Restart the router |
| Load balancer in front of the site | Idle timeout, protection rule | Long-open pages, big uploads | The owner's settings |

A wrong MTU setting, the largest packet size a link carries, is often blamed too, but it usually makes pages hang rather than reset: oversized packets vanish without any signal.

## Is the problem the site, your device or the network?

Five checks, quickest first. Stop at the first one that changes the result.

1. **Reload once.** A single reset after a server restart or a Wi-Fi change clears by itself.
2. **Try another browser.** If Firefox opens what Chrome cannot, the cause is inside Chrome: an extension or a setting. A reset in every browser points to something the whole computer shares.
3. **Open the site on your phone with Wi-Fi off.** If it loads over mobile data, the site is up and the problem is your network or computer. If not, the site has the problem.
4. **Try another device on the same Wi-Fi.** If that one works, look at the first computer: security software, a VPN, a proxy setting.
5. **Every device on this Wi-Fi fails on this one site.** The cut happens on the route: the router, the provider or a filter.

## How do you fix ERR_CONNECTION_RESET on a computer?

Reload after each step.

1. **Rule out extensions.** In Chrome, select **More > New Incognito window**. Extensions run there only if you turned on **Allow in Incognito** for them, so a page that opens here points to an extension. Go to **More > Extensions > Manage Extensions** and switch them off one at a time, VPN and proxy add-ons first. In Firefox, **Help > Troubleshoot Mode…** starts it with add-ons off.
2. **Turn off a VPN or proxy app.** Then look for a proxy you never set: in Windows 11 open **Settings > Network & internet > Proxy** and, under **Manual proxy setup**, select **Set up** next to **Use a proxy server**. If it is on and you did not turn it on, switch it off and select **Save**. Chrome opens the same page from **Settings > System > Open your computer's proxy settings**. Firefox's own setting should read **No proxy** or **Use system proxy settings** unless you chose a proxy on purpose.
3. **Test your security software.** Pause only its "web protection" or "HTTPS scanning" for a minute. If the site opens, turn protection back on, update the program and add the site to its exceptions. Do not switch the firewall off.
4. **Restart the router.** Unplug it for 30 seconds; do not press the reset pinhole, which restores factory settings.
5. **Reset the network settings, last.** Only when every site resets on this computer and other devices on the Wi-Fi work: **Settings > Network & internet > Advanced network settings > Network reset**, then **Reset now** and **Yes**. VPN software may need to be set up again afterwards.

Chrome's **Try:** list on the error screen points the same way: "Checking the proxy and the firewall" and "Running Windows Network Diagnostics".

### On Android and iPhone

- **Switching networks.** A phone that hops from Wi-Fi to mobile data drops open connections; reload after a few seconds.
- **VPN and ad-blocking apps.** Many route traffic through a VPN profile and reset connections when they fail. On Android open **Settings > Network & internet > VPN** and turn it off; **Always-on VPN** keeps one running in the background. On iPhone, installed profiles are under **Settings > General > VPN & Device Management**; leave work or school profiles alone.
- **Café and hotel Wi-Fi.** These networks can cut connections until you sign in on their login page.

## Why does only one website reset the connection?

If one site fails on every device on your network but opens over mobile data, a filter on the network is the likely sender. On `https://` sites the content is encrypted, but the site's name travels readable at the start of the connection. A filter that inspects traffic, a method called deep packet inspection (DPI), can match that name against a list and send a reset in the site's name. [What Is Deep Packet Inspection?](/blog/what-is-deep-packet-inspection) explains how that inspection works.

Such filters run on office and school networks, on routers with parental controls, and at internet providers where a block is ordered by law. On a work or school network, ask the administrator. If the block sits at your provider, nothing on your device fixes it, and this guide does not cover ways around it.

The other one-site case is the site itself, whose protection may reset an address that opens too many connections at once. Wait a few minutes, or send its support the time and the exact code.

## Advanced: test the connection outside the browser

You can skip this section. One command in PowerShell on Windows 10 or 11 shows whether the reset depends on the browser:

```powershell
curl.exe -sS -o NUL https://example.com/
```

Put the failing address in place of `example.com`. curl uses no extensions and no browser settings. Against a local test server that sends a reset, once during the secure setup and once after the request, curl 8.21.0 on Windows 11 printed:

```text
curl: (35) Recv failure: Connection was reset
curl: (56) Recv failure: Connection was reset
```

No output means curl loaded the page, so the cause is inside the browser. A `Connection was reset` line means something outside it cut the connection: security software, a VPN, the network or the site.

## If it's your site: where do resets come from?

Visitors may see resets that never show up in your application's logs. Look at the layers around it:

- **Restarts without draining.** A deploy that kills the server process resets every open connection. Stop accepting new connections and let running requests finish first.
- **Idle timeouts that disagree.** AWS documents that its Network Load Balancer drops idle TCP flows after 350 seconds by default and answers later data with a reset. For its Application Load Balancer it recommends an application idle timeout longer than the balancer's.
- **Protection rules.** Firewalls, DDoS filters and connection limits often reset instead of answering. Search their logs for the visitor's address and time.

## If you see "connection reset by peer" in code

"Peer" means the other end of the connection, and as in the browser it may be a device on the way. Each tool names the event differently. We triggered the Windows and Node.js cases on Windows 11 against a local server that sends a reset:

| Where | What you see |
|---|---|
| Python on Linux | `ConnectionResetError: [Errno 104] Connection reset by peer` |
| Python on Windows | `ConnectionResetError: [WinError 10054] An existing connection was forcibly closed by the remote host` |
| Python Requests | `requests.exceptions.ConnectionError: ('Connection aborted.', ConnectionResetError(10054, ...))` |
| Requests, cut mid-download | `requests.exceptions.ChunkedEncodingError: ("Connection broken: ConnectionResetError(10054, ...)", ...)` |
| Node.js `http` | `Error: read ECONNRESET` |
| Node.js, closed before a response | `Error: socket hang up` (code `ECONNRESET`) |
| Node.js `fetch` | `TypeError: fetch failed`, `cause.code` is `ECONNRESET` |

Windows prints its part in the system's display language; the English text is from Microsoft's [Winsock error list](https://learn.microsoft.com/en-us/windows/win32/winsock/windows-sockets-error-codes-2), which lists the causes of 10054: the remote program stopped, the host rebooted, or the other side used a "hard close". The Linux line is that system's standard text for error 104.

The usual causes in code:

- **A reused connection the server just closed.** Clients keep connections open between requests (keep-alive). If the server closes an idle one as you send on it, you get a reset. Node's documentation on [`request.reusedSocket`](https://nodejs.org/api/http.html#requestreusedsocket) describes this race and suggests retrying exactly that case.
- **Too many connections at once.** A server or its firewall may cut a client that opens dozens in parallel. Lower the concurrency, respect `429` and `Retry-After`, and use the site's API where one exists. Rotating IP addresses to get past a limit is not a fix.
- **The TLS handshake.** A reset there can mean the server or a filter rejected what the client offered, such as an old TLS version; update the client library first.
- **A proxy in the middle.** A proxy closes idle tunnels and passes on resets from the site. In our tests Requests labelled such a reset `ProxyError('Unable to connect to proxy', ConnectionResetError(...))` although the site had sent it; when the proxy closed our side gracefully, Python reported `RemoteDisconnected` or, during the handshake, `SSLEOFError`. Send the request once with and once without the proxy to see which hop cuts. [Max Retries Exceeded With URL](/blog/max-retries-exceeded-with-url) shows how to read the whole error chain.

### Retry with backoff, only where it is safe

A reset does not tell you whether the server already acted on your request. Retry automatically only requests that are safe to repeat, such as `GET`, wait longer each time and stop after a few attempts:

```python
"""GET a URL through a proxy and retry connection resets with exponential backoff."""
import random
import time

import requests

PROXY = "http://user:pass@pr.proxynet.io:8000"
PROXIES = {"http": PROXY, "https": PROXY}

def was_reset(exc):
    """True if a ConnectionResetError is wrapped anywhere inside the exception."""
    stack, seen = [exc], set()
    while stack:
        e = stack.pop()
        if id(e) in seen:
            continue
        seen.add(id(e))
        if isinstance(e, ConnectionResetError):  # RemoteDisconnected is a subclass
            return True
        inner = (*e.args, e.__cause__, e.__context__, getattr(e, "reason", None))
        stack.extend(x for x in inner if isinstance(x, BaseException))
    return False

def get_with_retry(session, url, attempts=4, base=1.0, cap=30.0):
    """GET is safe to repeat; wait about 1, 2, 4 s (plus jitter) between attempts."""
    for attempt in range(1, attempts + 1):
        try:
            return session.get(url, proxies=PROXIES, timeout=(5, 30))
        except (requests.exceptions.ConnectionError, requests.exceptions.ChunkedEncodingError) as exc:
            if not was_reset(exc) or attempt == attempts:
                raise
            delay = min(cap, base * 2 ** (attempt - 1)) + random.uniform(0, base / 2)
            print(f"attempt {attempt}: connection reset, retrying in {delay:.1f} s")
            time.sleep(delay)

if __name__ == "__main__":
    with requests.Session() as s:
        s.headers["User-Agent"] = "example-crawler/1.0 (+https://example.com/bot)"
        r = get_with_retry(s, "https://example.com/")
        print(r.status_code, len(r.content), "bytes")
```

- It retries resets only; a wrong password, a refused port or a certificate error is raised at once. Requests hides the reset two or three layers deep, hence the search. `RemoteDisconnected` ("Remote end closed connection without response") is a subclass of `ConnectionResetError`, so it counts too.
- The wait doubles each time, plus a random part (jitter) so parallel workers do not retry in step, and each attempt opens a fresh connection.

We ran it on Python 3.13 with Requests 2.34.2 through a local test proxy with `user:pass` authentication, against a test server that resets the first two connections:

```text
attempt 1: connection reset, retrying in 1.2 s
attempt 2: connection reset, retrying in 2.3 s
200 3 bytes
```

Against a server that resets every time, it gave up after four attempts with the `ProxyError` above. With a [Residential Proxy](https://proxynet.io/residential-proxy) in rotating mode, each retry opens a new connection and may leave from a new IP address; for a signed-in session that must keep one address, use a sticky session (1 to 60 minutes) and keep the retries inside it.

## Where people run into it

- Shop and bank pages that stop at the payment step on an office or school network.
- Large uploads that stop at the same point each time.
- Scraping, monitoring and API jobs that run for hours behind proxies and load balancers.

## Common mistakes

- **Clearing the cache and cookies.** The page never arrived, so nothing stale caused it.
- **Switching the firewall or antivirus off for good.** Pause one feature for one test.
- **Retrying a payment or form submission in code.** The server may have processed it before the reset.
- **Raising the retry count to 20.** A reset that happens every time is a decision, not bad luck.

## Decision guide

| Situation | What to do |
|---|---|
| One reset, then the page works | Nothing; it was a passing event |
| Only Chrome fails, Incognito works | Turn extensions off one at a time |
| Every browser on one computer fails | Check the VPN, the proxy setting and web protection |
| Every device on your Wi-Fi fails on one site | A filter or the provider; ask the administrator |
| Every network fails on that site | The site's problem; wait or contact it |
| Your own site resets visitors | Check restarts, idle timeouts and firewall logs |
| Your script gets `Errno 104`, `10054` or `ECONNRESET` now and then | Retry safe requests with backoff, lower the concurrency |

## Frequently asked questions

### Is ERR_CONNECTION_RESET my problem or the website's?

Either. Open the site on your phone over mobile data: if it loads, the problem is your network or computer; if it fails everywhere, it is the site's.

### Why does ERR_CONNECTION_RESET appear in all browsers?

The cause is something they all share: security software, a VPN, the system proxy setting, the router or a network filter. Extensions and browser settings are ruled out.

### Will clearing the cache fix ERR_CONNECTION_RESET?

Rarely. The connection was cut before the page arrived, so the cache holds nothing that caused it.

### What is the difference between a reset and "unexpectedly closed the connection"?

A reset (`ERR_CONNECTION_RESET`) ends the connection at once. "Unexpectedly closed the connection" (`ERR_CONNECTION_CLOSED`) means the other side closed it the normal way, but before the page was complete. Both are checked the same way.

### What does "connection reset by peer" mean?

The other end of the connection, the peer, sent a reset. Linux reports it as error 104, Windows as 10054 and Node.js as `ECONNRESET`. The peer can be the server or any device in between.

### How do I fix ECONNRESET or "socket hang up" in Node.js?

Both mean the connection was cut, "socket hang up" before any response arrived. Retry idempotent requests on a fresh connection, especially when `req.reusedSocket` is true, and lower the concurrency.

## Summary

`ERR_CONNECTION_RESET` and "connection reset by peer" name the same event: an open connection ended by a reset signal from the site, your computer, a VPN or proxy, or the network between. Find the sender by changing one thing at a time: browser, private window, device, network. A block on the network is not something your device can change. In code, retry only safe requests, with growing pauses and a fresh connection. If you use proxies for that kind of work, [our proxy page](/proxy) explains which types exist and what each is for.