ERR_CONNECTION_RESET

The short version: ERR_CONNECTION_RESET means a TCP RST packet abruptly tore down a connection that was already in progress. If it happens on every website, the cause is local: your network, firewall, antivirus, VPN, or TCP/IP stack. If it happens on one website only, the server or a device in front of it is rejecting the request.

Key takeaways

• ERR_CONNECTION_RESET is Chromium net error -101: a connection that already started was killed by a TCP RST packet. It is refusal, not silence, which is what separates it from a timeout.
• If every website resets, the cause is local (firewall, antivirus, VPN, or a corrupted TCP/IP stack); if only one website resets and it loads elsewhere, a server or a middlebox in front of it is sending the RST.
• The most common single fix is to disable an interfering VPN, proxy, or HTTPS-scanning antivirus, then reset the network stack with netsh winsock reset on Windows.
• A reset is not always a fault: ISPs and corporate filters read the cleartext SNI hostname in the TLS handshake and inject a forged RST to block websites, which looks identical to a server problem.
• Confirm a real RST with curl -v https://yourdomain.com: 'Connection reset by peer' is the signature, and it tells you to stop hunting for slow servers and look for whatever is actively closing the connection.

Error type

Browser / network (TCP connection reset)

Whose side

Either

Fix difficulty

Varies

Common cause

A TCP RST packet from a firewall, antivirus, proxy, ISP, or the server closed the connection mid-transfer

What does ERR_CONNECTION_RESET mean?

Every web request rides on a TCP connection. Your browser sends a SYN, the server answers with SYN-ACK, and data begins to flow. ERR_CONNECTION_RESET means that after this handshake started, one side sent a TCP RST (reset) packet: an explicit, immediate order to tear the connection down. Chrome had a live conversation and it was hung up on, so it surfaces the error and pairs it with the headline This site can't be reached and the line The connection was reset.

The single most useful thing to understand is how a reset differs from a timeout, because the two point at completely different problems. A timeout (ERR_CONNECTION_TIMED_OUT) is silence: your browser sent packets and nothing ever came back, so it gave up. A reset is the opposite of silence: something actively and deliberately answered with a RST to kill the link. Timeout means a packet was dropped or ignored; reset means a packet was refused. That distinction tells you to stop looking for slow or unreachable servers and start looking for whatever is actively closing the door: a firewall rule, antivirus, a proxy, or the server's own software aborting.

A reset is not always a fault. ISPs, corporate firewalls, and national or parental filters often block websites by reading the cleartext SNI hostname inside the TLS ClientHello, and when it matches a blocklist they inject a forged TCP RST to both ends. To your browser this is indistinguishable from a server problem: you get ERR_CONNECTION_RESET even though the real server is perfectly healthy. This is why the same URL can fail on one network (say mobile data or office Wi-Fi) and load instantly on another. If a website resets only on a specific connection, suspect a middlebox before you blame the host.

Resets also come from MTU mismatches (oversized packets get dropped and the path resets), idle connections that a NAT or load balancer ages out and closes with a RST, and a corrupted local TCP/IP or Winsock stack that mangles packets so badly the peer rejects them. Narrowing down the source, your machine, your network path, or the server, is the whole game.

~20%

of new TCP connections to Cloudflare globally see a reset or timeout within the first 10 packets (Cloudflare Radar)

443 / 80

the HTTPS and HTTP ports a firewall or ISP most often resets to block a website

Either side

a RST can be sent by the client, the server, or any middlebox in between, which is why the cause varies

How the ERR_CONNECTION_RESET error appears

The wording changes depending on your browser, device, or server. Here is how this error commonly shows up:

example.com

This site can't be reached

The connection was reset.

ERR_CONNECTION_RESET

• ERR_CONNECTION_RESET Chrome and Edge net error code shown on the error page
• This site can't be reached / The connection was reset. The plain-language headline Chrome pairs with the code
• The connection was reset Firefox wording for the same TCP RST event
• connection reset by peer Server logs and curl wording when the remote end sends RST
• ERR_CONNECTION_ABORTED Closely related Chrome code: the connection dropped, often after data started flowing

ERR_CONNECTION_RESET vs related connection errors

These Chrome errors look similar but point at different layers. Telling them apart saves hours of troubleshooting.

ERR_CONNECTION_RESET: cause, symptom, and who fixes it

Match the pattern you see to the layer sending the RST so you fix the right thing first.

curl exit codes that look like a reset

Running curl -v narrows a reset down to the exact stage it happened; these are the codes you are most likely to see.

What causes ERR_CONNECTION_RESET?

• Firewall or antivirus software treating the connection as a threat and killing it with a RST
• An unstable or congested network (weak Wi-Fi, flaky cabling, packet loss) that drops the session mid-transfer
• A VPN or proxy that is misconfigured, overloaded, or injecting resets of its own
• ISP, corporate, or parental filtering that inspects the SNI hostname and resets connections to blocked websites
• A corrupted local TCP/IP stack, Winsock catalog, or stale DNS cache producing malformed traffic
• The server (or a load balancer or firewall in front of it) actively closing the connection, due to a crash, a blocked IP, an MTU mismatch, or an idle-timeout RST

How to find the cause fast

1. Try the same URL on another network (mobile data, a different Wi-Fi) and another device. If it loads elsewhere, the problem is your original network or a filter on it, not the server.
2. Open the website in an incognito window with extensions disabled. If it works, a corrupted cache, cookie, or extension on the normal profile is the cause.
3. Run curl -v https://example.com from a terminal. A line like 'Recv failure: Connection reset by peer' or 'OpenSSL SSL_connect: Connection reset by peer' confirms a real TCP RST and shows how far the handshake got before it died.
4. Run ping example.com and traceroute example.com (tracert on Windows). If ping succeeds but the page resets, the host is reachable and the reset comes from the application layer or a filter, not basic connectivity.
5. On the server or your machine, list reset counters with netstat -s | grep -i reset (Linux/macOS) or netstat -s (Windows). A rising reset count while you reproduce the error helps confirm where the RST originates.

Terminal

curl -v https://example.com* Recv failure: Connection reset by peer* OpenSSL SSL_connect: Connection reset by peer in connection to example.com:443# A TCP RST tore down the connection mid-handshake, not a timeout

How ERR_CONNECTION_RESET looks from the outside

From the outside, a reset looks like a connection that opens and then dies before a response arrives. An external monitor that runs an HTTP or TCP check will record a failed request with a 'connection reset by peer' style error rather than a clean status code, and a port check on 443 or 80 will show the port accepting then dropping the handshake. Pulsetic checks your website over HTTP, TCP, and ICMP from 15+ locations worldwide every 30 seconds, so if a firewall, load balancer, or filtering middlebox starts resetting connections to your server, the failing checks fire alerts by email, SMS, voice, Slack, Discord, Telegram, or webhook within seconds. Because the checks run from many regions, Pulsetic can also reveal a reset that only affects certain networks or geographies, exactly the SNI- or ISP-level blocking that is invisible from your own desk. Pulsetic tests from outside your server, so it confirms reachability and the reset symptom but does not inspect what happens inside the host.

How to fix ERR_CONNECTION_RESET

For visitors

1. Reload the page and try it on a different network (switch to mobile data or another Wi-Fi) to rule out a local filter.
2. Clear your browser cache and cookies, then retry in an incognito window with extensions turned off.
3. Temporarily disable any VPN, proxy, firewall, or antivirus web shield, then reload. Re-enable it once you know whether it was the cause.
4. Flush your DNS cache and reset your network stack (see the platform steps and commands below), then restart the browser.
5. Restart your router and device to clear a stalled connection or a stuck NAT/keepalive state.

For website owners

1. Check your server, load balancer, and CDN logs for RST or 'connection reset by peer' entries around the failure time to find which layer is closing connections.
2. Review firewall, WAF, and rate-limit rules: an over-aggressive rule or a blocked IP range will reset legitimate visitors. Confirm ports 80 and 443 accept traffic.
3. Verify TLS and SNI are configured correctly and your certificate matches the hostname, since some setups reset on an unrecognized SNI.
4. Test for an MTU or keepalive issue: lower the path MTU or tune TCP keepalive so idle connections are not aged out and reset by a middlebox.
5. Set up external monitoring (see below) so you learn about resets from real-world locations before your visitors report them.

Windows

1. Open Command Prompt as Administrator (right-click, Run as administrator).
2. Reset the stack: run netsh winsock reset, then netsh int ip reset, then ipconfig /flushdns.
3. If only certain websites reset, lower the MTU: netsh interface ipv4 set subinterface "Wi-Fi" mtu=1472 store=persistent (replace Wi-Fi with your adapter name).
4. Restart the computer, then reopen the website.

macOS

1. Flush DNS in Terminal: sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder, then enter your password.
2. Renew the network lease: System Settings > Network > Wi-Fi > Details > TCP/IP > Renew DHCP Lease.
3. Turn off any VPN or content-filter profile and disable third-party antivirus web protection, then retry.
4. Restart the Mac if the reset persists.

Chrome

1. Clear cache and cookies: Settings > Privacy and security > Delete browsing data.
2. Open the website in Incognito (Ctrl+Shift+N / Cmd+Shift+N) to bypass extensions and cached data.
3. Disable extensions at chrome://extensions, especially VPN, proxy, or security extensions.
4. Check chrome://settings/system and your OS proxy settings: make sure no stale or broken proxy is configured.

Still not fixed? Next steps

• Capture the reset on the wire with tcpdump -ni any host yourdomain.com and tcp[tcpflags] & tcp-rst != 0 (or Wireshark filtered on tcp.flags.reset == 1) to see which IP is actually sending the RST.
• If the RST source is your own gateway or an upstream hop, the reset is being injected in the network path; test the same hostname over a different ISP or a mobile hotspot to confirm middlebox filtering rather than a server fault.
• On the server side, correlate the timestamp with WAF, rate-limit, and load-balancer logs: an over-aggressive rule or a blocked IP range will reset legitimate visitors, and the log line names the rule that fired.
• If captures show resets only on large responses, suspect an MTU or path-MTU-discovery problem: lower the interface MTU or clamp the TCP MSS at your edge, then retest.

Code & configuration

Copy-paste starting points. Replace example.com and the paths with your own, and test changes on staging before production.

Confirm the reset with curl

curl -v https://example.com
# A real RST shows: "Recv failure: Connection reset by peer"
# or: "OpenSSL SSL_connect: Connection reset by peer in connection to example.com:443"

Reset the network stack (Windows, run as Administrator)

netsh winsock reset
netsh int ip reset
ipconfig /flushdns
:: then restart the PC

Flush DNS (macOS)

sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

How to prevent ERR_CONNECTION_RESET

Most resets you can prevent: keep firewall, WAF, and rate-limit rules tuned so they do not strangle legitimate traffic, validate TLS and SNI configuration, and tune MTU and keepalive so middleboxes do not age out and reset idle connections. What you cannot prevent is a filter or a load balancer that starts resetting connections without warning, so the real protection is knowing the moment it happens. Pulsetic monitors your website from 15+ global locations every 30 seconds and alerts you across email, SMS, voice, Slack, Discord, Telegram, and webhook the instant checks start failing, and a public or private status page keeps your users informed while you fix it.

Learn how Pulsetic's uptime monitoring detects this from the outside, across 15+ locations.