ERR_CONNECTION_RESET: What It Means & How to Fix It

What Is ERR_CONNECTION_RESET?

ERR_CONNECTION_RESET is the error Chrome, Edge, Brave and other Chromium browsers show when a connection to a website was open and then forcibly cut. The page reads "This site can't be reached. The connection was reset." Inside Chromium it is net error -101, and the source code describes it in one line: "A connection was reset (corresponding to a TCP RST)." (net_error_list.h)

A TCP reset (RST) is the network's hang-up button. A normal connection ends politely with a FIN packet after the data is delivered. A reset ends it instantly, with no goodbye, and whatever was half-loaded is thrown away. Your browser got as far as reaching the server: DNS worked and the connection was established. Then something in the path decided to kill it.

That "something" is the whole puzzle. It can be your own computer (antivirus, VPN, a broken network stack), your router or ISP, a firewall in front of the site, or the web server process itself. The fixes below are ordered to find out which, fastest first.

How This Error Looks in Other Browsers

The wording changes from browser to browser, but they are all reporting the same TCP reset.

If Firefox shows PR_CONNECT_RESET_ERROR on a "Secure Connection Failed" page instead, the reset happened during the HTTPS handshake. The causes overlap heavily with this guide, especially antivirus HTTPS scanning and network filtering.

Our PR_CONNECT_RESET_ERROR guide covers the Firefox-specific fixes, such as its separate proxy setting and Troubleshoot Mode.

What Causes ERR_CONNECTION_RESET?

Every reset has a sender. Working out who sent it tells you who can fix it.

The first five are on your side and you can usually fix them in minutes. The last two are on the website's side: no amount of cache clearing will help, and the only fix is for the owner to resolve it, or for you to wait.

Step 1: Is It You or the Website?

Spend 60 seconds on this before changing any settings. It tells you which half of this guide applies to you.

• Try another network. Turn Wi-Fi off on your phone and open the same page on mobile data. If it loads, the reset is happening on your device or your home/work network.
• Try another site. If every HTTPS site resets, suspect your VPN, proxy or antivirus. If only one site does, suspect filtering or that site's server.
• Test the site from outside. The Website Down Checker loads the page from 11 places. If it loads for them but resets for you, the problem is between you and the site: your device, your network, or a block on your IP. The Port Checker answers a narrower question: is anything accepting connections on port 443 at all? For a site behind Cloudflare, an open 443 only shows that Cloudflare answers.
• Trace the route. A traceroute from 8 cities shows each network hop to the server, which helps you tell a dead server apart from a broken path.

Fix 1: Reload, Then Try an Incognito Window

A single reset is often a one-off: a router rebooting, a server restarting during a deploy, a Wi-Fi handoff. Press Ctrl + R (Mac: Cmd + R) after a few seconds.

If it keeps happening, open the page in an Incognito window (Ctrl + Shift + N, Mac Cmd + Shift + N). Incognito runs without your extensions and without saved cookies. If the page loads there, an extension or a corrupted cookie is to blame: disable extensions one by one, or clear that site's data: View site information at the left of the address bar → Cookies and site data → Manage on-device site data → delete.

Fix 2: Turn Off Your VPN and Check Proxy Settings

VPNs and proxies sit in the middle of every connection, and when their server is overloaded, blocked, or has an idle timer that is too short, they reset connections. Disconnect the VPN completely (don't just switch servers) and reload.

If Chrome shows ERR_TUNNEL_CONNECTION_FAILED instead, the proxy couldn't open a connection to the site for you. See ERR_TUNNEL_CONNECTION_FAILED.

• Windows 11: Settings → Network & internet → Proxy. Leave Automatically detect settings on, and under Manual proxy setup click Set up (or Edit) and turn Use a proxy server off.
• macOS: System Settings → Network → select Wi-Fi or Ethernet → Details… → Proxies. Turn off every proxy you didn't set up on purpose.
• Chrome uses the system proxy unless an extension has taken it over: chrome://settings/system then reads "Chrome is using proxy settings from an extension", and turning that extension off removes the proxy.

# Windows also has a separate system-service proxy (WinHTTP).
# Run in an elevated Command Prompt or PowerShell:
netsh winhttp show proxy
netsh winhttp reset proxy

Fix 3: Pause Antivirus HTTPS Scanning or Firewall

Many antivirus suites decrypt and inspect your HTTPS traffic. The feature has names like HTTPS scanning, Web Shield, SSL/TLS protocol filtering or Scan encrypted connections. When the scanner can't handle a site's certificate or protocol, it resets the connection rather than let it through.

To test, turn the HTTPS-scanning option off, not the whole antivirus, and reload. If the page loads, either keep scanning off for that site (most products allow an exclusion) or update the antivirus. Third-party firewalls can do the same thing, so test with them paused too.

Fix 4: Reset the Windows Network Stack (Winsock)

Windows keeps a catalog of network components called Winsock. VPN clients, old antivirus products and some malware add entries to it, and a damaged catalog produces resets on every site. Resetting Winsock and the TCP/IP stack puts both back to defaults. Open Command Prompt as administrator, run these, then restart the PC (the Winsock reset needs a reboot to apply):

netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew
ipconfig /flushdns

On Windows 11 there is also a one-click version: Settings → Network & internet → Advanced network settings → Network reset. It removes and reinstalls every network adapter and restarts the PC, so you will need to reconnect to Wi-Fi and reinstall any VPN afterwards.

Fix 5: Flush DNS and Try a Different DNS Resolver

DNS doesn't send resets itself, but some ISP and workplace resolvers point blocked domains at a filtering server that resets the connection. A stale cached address can also send you to a server that no longer hosts the site. Flush the cache first. Our flush DNS guide has the command for every system:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Chrome's own cache: open chrome://net-internals/#dns and click "Clear host cache"

Then compare what your network returns with a neutral answer. Run the domain through DNS Robot's DNS Lookup and resolve it on your computer (nslookup example.com). Big sites on CDNs give different addresses in different places, so a mismatch alone proves nothing, but 0.0.0.0, 127.0.0.1 or an address owned by your ISP or a filtering service (check it with IP Lookup) means your resolver is redirecting you. Switch to a public resolver like Cloudflare (1.1.1.1) or Google (8.8.8.8). Our DNS Speed Test shows which one is fastest from where you are.

Fix 6: Lower the MTU If Big Pages Fail and Small Ones Load

A classic pattern: simple pages load, but large pages, file downloads or logins reset. That points to an MTU problem. Packets are too big for one link in the path (common with VPNs, PPPoE DSL and some mobile hotspots), and a device that should report the problem silently drops them instead, so the connection stalls and then fails.

Find the largest packet that gets through without fragmenting. 1472 bytes of data plus 28 bytes of headers equals the standard 1500 MTU. On Windows, -f means don't fragment and -l sets the size; on a Mac, -D and -s do the same. If Windows answers "Packet needs to be fragmented but DF set" (macOS: "frag needed and DF set", or "Message too long" when the packet is bigger than your own connection allows), or the pings simply time out, the packet is too big: lower the size until replies come back. Then set the MTU to the largest working size plus 28 (the last Windows line below sets 1400):

# Windows
ping example.com -f -l 1472
netsh interface ipv4 show subinterfaces
netsh interface ipv4 set subinterface "Wi-Fi" mtu=1400 store=persistent

# macOS
ping -D -s 1472 example.com

Fix 7: Flush Chrome's Socket Pools and Reset Chrome

Chrome keeps connections open to load pages faster, and it already retries on a fresh connection when a reused one is reset. After you switch networks or a VPN drops, flushing them clears every old connection at once: open chrome://net-internals/#sockets and click Flush socket pools, then reload.

Still failing only in Chrome while Firefox works? Go to chrome://settings/reset → Restore settings to their original defaults. This disables extensions and clears temporary data, but keeps bookmarks, history and saved passwords.

Fix ERR_CONNECTION_RESET on Android and iPhone

Phones hit this error for the same reasons, plus one extra: a Private DNS setting on Android that points to a filtering or unreachable server.

• Android, Private DNS: Settings → Network & internet → Private DNS → set it to Automatic (on Samsung: Settings → Connections → More connection settings → Private DNS). Our guide to Private DNS on Android explains what each option does.
• Android, reset network settings: Settings → System → Reset options → Reset Bluetooth & Wi-Fi, plus Reset Mobile Network Settings if mobile data is affected (on Samsung: Settings → General management → Reset → Reset Wi-Fi and Bluetooth settings).
• iPhone and iPad: Settings → General → Transfer or Reset iPhone → Reset → Reset Network Settings. This forgets saved Wi-Fi networks and passwords, and removes VPN settings that weren't installed by a configuration profile.
• Both: turn off any VPN or ad-blocking app (many work as a local VPN), switch between Wi-Fi and mobile data, and update the browser app.

For Website Owners: Find What Is Resetting Your Visitors

If visitors report ERR_CONNECTION_RESET and your site fails from several networks, the reset is coming from your stack. Work from the outside in:

• Reproduce it from outside. Run curl -v https://yourdomain.com from a machine outside your network, or load the page with the Website Down Checker. Note whether the reset comes before the TLS handshake, during it, or after the request was sent.
• Check your security layer. Firewalls and ban tools like fail2ban or CrowdSec block IPs in different ways: an iptables REJECT --reject-with tcp-reset rule shows up as ERR_CONNECTION_RESET, fail2ban's default ICMP reject usually as refused, and a DROP rule as a timeout. Check whether the reporting user's IP is banned before anything else.
• Look for crashes and restarts. A process that dies mid-request takes its open connections with it. Check journalctl -u your-service, pm2 logs, or sudo dmesg -T | grep -i "killed process" for the Linux out-of-memory killer.
• Check TLS. Some firewalls, load balancers and servers reset the connection when Chrome's TLS greeting, larger since it turned on post-quantum key exchange in 2024, arrives in more than one packet (tldr.fail); update them. The SSL Checker shows your certificate chain and expiry, and the HTTP Header Checker shows what a real request gets back.
• Check the CDN. If you're behind Cloudflare or another CDN, read its security event log for the visitor's IP or country before you touch the origin server.

# Is the visitor's IP banned by fail2ban? (lists the jails that ban it)
sudo fail2ban-client banned 203.0.113.7
sudo fail2ban-client unban 203.0.113.7

# Did the OOM killer end your app?
sudo dmesg -T | grep -i "killed process"

ERR_CONNECTION_RESET vs Refused vs Timed Out vs Closed

These four errors look alike on screen but describe different things on the network, and each points to a different fix. The codes are Chromium's own net error numbers.

Full guides for the neighbours: ERR_CONNECTION_REFUSED, ERR_CONNECTION_TIMED_OUT and ERR_CONNECTION_CLOSED. If your network is blocking secure DNS as well, see this network is blocking encrypted DNS traffic.