ERR_CONNECTION_RESET in Chrome is one of the trickier network errors because the connection was actually established — the TCP handshake completed, Chrome and the server shook hands — and then the server (or something between you and it) abruptly cut the connection without sending any data. It’s the digital equivalent of someone answering the phone, then immediately hanging up without saying a word. If you want the full context, see our Google Chrome Errors.
This error has more possible causes than most Chrome network errors, which is why it’s also one of the more common ones. The cause could be VPN interference, a server under load, Chrome’s own socket pool in a bad state, an antivirus product breaking HTTPS inspection, or a corrupted TCP/IP stack. The key diagnostic — and the one that tells you where to start — is whether the error appears on one specific site or on multiple sites at once.
Key Diagnostic: One Site or Many?
ERR_CONNECTION_RESET on a single site while everything else loads normally almost always means the problem is on the server’s side, or at least specific to that server’s connection to your network. The server may be overloaded, your IP address may be blocked, or the specific server handling your geographic region may be having issues. Try the site from a different network (phone data) before spending time troubleshooting your own setup.
ERR_CONNECTION_RESET across multiple sites simultaneously means the problem is local — either in Chrome’s configuration, in your network stack, or in something that’s intercepting connections before they reach their destinations. That’s where most of the fixes below focus.
Also worth knowing: ERR_CONNECTION_RESET that appeared immediately after installing a VPN, or immediately after connecting to a VPN, is almost certainly the VPN’s fault. VPN-caused ERR_CONNECTION_RESET is by far the most common cause I’ve seen — if you have any VPN active, that’s Fix 1, not Fix 4.
ERR_CONNECTION_RESET Fix 1: Disconnect VPN and Check Proxy Settings
VPNs cause ERR_CONNECTION_RESET more than any other single factor. The VPN receives the initial connection from Chrome, attempts to forward it to the actual server, and the forwarding fails — the connection gets reset partway through. This is especially common when the VPN server is overloaded, when the VPN protocol being used is incompatible with the connection type the server expects, or when the VPN is set up to handle HTTP but not HTTPS connections correctly.
The fix isn’t just toggling the VPN off within the app. Fully exit the application. Many VPN clients leave background processes running that continue to intercept connections even when you’ve “disconnected” within the UI.
- Completely quit the VPN application from the system tray
- Test the site immediately
- If it loads: try a different VPN server location, or switch the VPN protocol (OpenVPN vs WireGuard vs IKEv2) in the app settings
- Also check Windows proxy settings: Settings → Network and internet → Proxy → confirm “Use a proxy server” is Off
If ERR_CONNECTION_RESET disappears without the VPN but you need the VPN for the specific site you’re trying to reach, contact the VPN provider. The issue is usually a specific server being down or overloaded, and switching to a different server location in the same VPN app resolves it.
ERR_CONNECTION_RESET Fix 2: Clear Chrome’s Socket Pool
Chrome maintains its own pool of pre-established TCP connections (sockets) to speed up connections to frequently visited sites. When these sockets are left in a half-open state — after a network interruption, after Chrome crashes, or after a connection wasn’t properly terminated — subsequent connection attempts to those servers get reset because Chrome tries to reuse a broken socket instead of establishing a fresh connection.
This is a Chrome-specific issue and is worth trying early because it takes ten seconds and has no side effects:
- In Chrome’s address bar, go to chrome://net-internals/#sockets
- Click Flush socket pools
- Also go to chrome://net-internals/#dns → click Clear host cache
- Reload the page showing ERR_CONNECTION_RESET
If this resolves the error temporarily but it returns within a few minutes, the connection is being reset by something external rather than by Chrome’s socket state. Move on to Fix 3 or Fix 5.
ERR_CONNECTION_RESET Fix 3: Disable Chrome’s QUIC Protocol
Chrome uses Google’s QUIC protocol for connections to Google services and a growing number of other sites. QUIC runs over UDP rather than TCP, and some routers and ISPs block or throttle UDP traffic in ways that cause connections to get reset. This shows up specifically as ERR_CONNECTION_RESET on sites using QUIC while standard TCP connections work fine — so if you’re seeing the error on Google services, YouTube, or other Google properties but not on non-Google sites, QUIC interference is a likely culprit.
- In Chrome, go to chrome://flags
- Search for Experimental QUIC protocol
- Change the dropdown from Default to Disabled
- Click Relaunch
- Test the sites that were showing ERR_CONNECTION_RESET
QUIC being blocked is genuinely common on certain consumer routers and ISP connections — particularly older routers that don’t handle UDP well at high throughput. Disabling QUIC forces Chrome to use standard TCP for all connections and is a harmless change if you don’t notice any speed difference, which most users don’t on a typical home connection.
ERR_CONNECTION_RESET Fix 4: Check Antivirus SSL/HTTPS Scanning
Many antivirus products scan HTTPS traffic by acting as a man-in-the-middle — they intercept the encrypted connection, decrypt it to scan the content, and then re-encrypt it to send along. When the antivirus scanner can’t properly re-establish the connection after scanning (which happens on sites using HTTP/2, HTTP/3, or certain cipher configurations), the connection gets reset and Chrome shows ERR_CONNECTION_RESET.
Antivirus-caused ERR_CONNECTION_RESET typically appeared after an antivirus update — the new version introduced changes to how HTTPS scanning works that conflict with connection types the previous version handled fine. If ERR_CONNECTION_RESET started after an antivirus update, this is the likely cause.
- Open your antivirus application and look for SSL scanning, HTTPS scanning, Web Shield, or Web Protection settings
- Temporarily disable it
- Test the site showing ERR_CONNECTION_RESET
- If it loads: check for an antivirus update that addresses compatibility, or add the specific site to the antivirus exclusion list
Don’t leave HTTPS scanning disabled permanently without understanding what you’re giving up. For most home users the risk is low, but enterprise environments where the antivirus is a managed security tool will need IT involvement to address this properly.
ERR_CONNECTION_RESET Fix 5: Reset the TCP/IP Stack
A corrupted TCP/IP stack causes ERR_CONNECTION_RESET across multiple sites and browsers — connections get reset because the TCP layer can’t complete the three-way handshake correctly. This is different from a temporary socket issue in Chrome: it affects everything on the system that uses the network stack, not just Chrome’s connections.
Signs this is the cause: ERR_CONNECTION_RESET in multiple browsers simultaneously, or connections reset even when you’re using applications other than Chrome (email clients, desktop applications, etc.). The fix is a full network stack reset:
- Open Command Prompt as administrator
- Run: netsh winsock reset
- Run: netsh int ip reset
- Run: ipconfig /flushdns
- Restart the PC — this step is required for the Winsock reset to take effect
- Test Chrome after restart
The Winsock reset in particular requires a restart to take effect. Skipping it and just restarting Chrome won’t fully apply the changes.
ERR_CONNECTION_RESET Quick Reference
| When it appears | Most likely cause | Fix first |
|---|---|---|
| One site, others load fine | Server-side reset or IP block | Test on phone data; Fix 2 (sockets) |
| After connecting VPN | VPN forwarding failure | Fix 1 — fully quit VPN |
| Multiple sites in Chrome only | Chrome socket pool issue | Fix 2 — flush sockets |
| Multiple sites in all browsers | Corrupted TCP/IP stack | Fix 5 — reset Winsock |
| After antivirus update | HTTPS scanning conflict | Fix 4 — disable SSL scanning |
| Google services specifically | QUIC protocol blocked | Fix 3 — disable QUIC |
For connection errors where Chrome can’t even initiate the connection, our guide on ERR_CONNECTION_REFUSED covers the “server actively rejected the connection” scenario, which has different causes from a reset. For timeout-related connection failures, ERR_TIMED_OUT covers the case where connections time out rather than being reset. Google’s Chrome support documentation has additional troubleshooting for enterprise environments where proxy configuration and connection policies cause ERR_CONNECTION_RESET on specific internal or external destinations.
There’s a scenario that catches people out: ERR_CONNECTION_RESET appearing only on HTTPS sites while HTTP sites load fine. If you can access http://example.com but not https://example.com for the same domain, the SSL/TLS layer is being reset specifically — which points more to an SSL inspection tool (antivirus, corporate proxy) or to a TLS version mismatch than to a general TCP issue. In this case, Fix 4 (antivirus HTTPS scanning) is the right starting point, not Fix 5 (TCP stack reset). The TCP stack is working fine if HTTP connections succeed; it’s the encrypted layer that’s being disrupted.
Corporate networks add a layer of complexity because connection resets are sometimes intentional. Data Loss Prevention (DLP) tools, web filtering proxies, and firewall rules can all reset connections to certain sites or at certain times. If ERR_CONNECTION_RESET appears only on work equipment or only when connected to a corporate VPN, and specific business-relevant sites are affected, this is more likely a corporate network policy than a technical problem on your machine. In that environment, IT is the right escalation path — the network administrator can check whether the specific connection is being reset by a security policy and either adjust the policy or provide a workaround.
Router-level connection tracking limits are a less common but real cause of ERR_CONNECTION_RESET on home networks, particularly in households with many connected devices. Consumer routers have a finite connection tracking table — a list of all active TCP connections they’re currently managing. When this table fills up (which can happen with many simultaneous streaming, gaming, and background application connections), new connections get reset because the router has no space to track them. The symptom is ERR_CONNECTION_RESET appearing intermittently across multiple devices, often in the evening when household internet usage peaks. The fix is restarting the router (which clears the connection table) and optionally reducing the number of idle long-lived connections from background applications, or upgrading to a router with a larger connection table.
HTTP/2 connection multiplexing is a more technical cause that’s worth mentioning for completeness. HTTP/2 allows multiple requests to share a single connection — which is efficient but means that if that connection gets reset, multiple page resources fail simultaneously and Chrome reports ERR_CONNECTION_RESET in a way that looks like a complete page failure rather than individual resource failures. Some servers, CDNs, and intermediaries handle HTTP/2 multiplexing incorrectly under load, causing connection resets that only affect Chrome (which defaults to HTTP/2) while older clients using HTTP/1.1 experience no issues. If ERR_CONNECTION_RESET appears only in Chrome, only on specific high-traffic sites, and only at peak usage times, HTTP/2 handling under load is a possible cause. There’s no simple fix on the client side for server-side HTTP/2 issues, but you can confirm this theory by disabling HTTP/2 in Chrome’s flags (chrome://flags → search “HTTP/2” → try disabling it) to see if the error stops. If it does, the issue is confirmed to be HTTP/2-related and is a server-side problem for the site owner to address.
If none of the above fixes have resolved ERR_CONNECTION_RESET and the error is specific to one site that works fine on other networks and devices, there’s one more thing worth checking: whether your IP address has been blocked by the server. Some websites implement aggressive DDoS protection that automatically blocks IP addresses sending what it perceives as unusual traffic patterns. If you’ve been making many rapid requests (refreshing aggressively, running automation, or if another program on your network was doing so), your IP may have been temporarily blocked. The reset in this case comes from the DDoS protection layer dropping the connection rather than the actual server. Testing on a different network (phone data) immediately confirms this — if the site loads on mobile data but not your home connection, an IP block is the likely cause. Most temporary IP blocks expire within 15–60 minutes; using a VPN to access the site through a different IP is the only immediate workaround if you need access before the block clears.
Finally: basic reload before anything else. I mention this at the end rather than the beginning because it feels too obvious — but ERR_CONNECTION_RESET caused by a brief network blip, a server hiccup, or a Wi-Fi signal fluctuation often resolves on the very next page load. Press Ctrl + Shift + R for a hard reload that bypasses cached data. If the error appears once and then doesn’t come back, it was transient and needs no further investigation. Only the persistent ERR_CONNECTION_RESET — one that appears consistently on the same site or across multiple sites over multiple attempts — warrants working through the fixes above. See also How to Fix ERR_NETWORK_CHANGED in Chrome for a related case.
