Chrome displays ERR_CONNECTION_RESET when a TCP connection that was already open gets forcibly terminated before the page finishes loading. You see a blank white page with the message “The connection was reset” and no content at all. Unlike ERR_NAME_NOT_RESOLVED, which means DNS could not find the server, or ERR_CONNECTION_REFUSED, which means the server actively declined the connection, ERR_CONNECTION_RESET means the connection was established and then abruptly severed mid-session.
The reset can come from three directions: the remote server sending a TCP RST packet to terminate the session, an intermediate network device such as a firewall, VPN, or deep-packet inspection appliance injecting a RST packet, or the local machine sending a RST because its network stack is in a corrupted state. Identifying which of these three directions is responsible determines the fix.
This guide covers the complete set of causes with a diagnosis approach for each and exact fix steps for Windows and Mac. It covers the network-level explanation most guides skip, the MTU mismatch problem that only appears on specific network configurations, the antivirus HTTPS inspection conflict that affects millions of users but is rarely documented clearly, and the server-side causes that require site owners to investigate their own infrastructure.
If the error appears only on one specific site and not on any other site, the cause is more likely server-side or CDN-side than local. If the error appears across multiple different sites, the cause is almost certainly local: your network stack, VPN, antivirus, or proxy configuration.
What ERR_CONNECTION_RESET Means at the Network Level
Every web page load starts with a TCP handshake: your browser sends a SYN packet, the server replies with SYN-ACK, your browser confirms with ACK, and the connection is established. Data transfer begins. ERR_CONNECTION_RESET means that at some point after this handshake, either during the TLS handshake for HTTPS sites or during actual data transfer, one party sent a TCP RST packet.
The RST flag in a TCP packet is an emergency signal. It means: abort this connection immediately, discard all buffered data, do not wait for an orderly FIN-ACK handshake. The receiver must terminate the connection at once. Chrome interprets an incoming RST packet as ERR_CONNECTION_RESET.
Understanding which device sent the RST packet is the key to diagnosing the cause. The RST can originate from the web server itself, from a proxy or CDN between you and the server, from a firewall doing deep packet inspection on your network, from an antivirus product intercepting your HTTPS traffic, from your ISP’s network infrastructure, or from your own machine’s TCP/IP stack in a corrupted state.
| Who Sent the RST | Likely Cause | Affected Scope | Starting Fix |
| Web server | Server overload, misconfigured TLS, server firewall rule | Only that specific site | Test from different network/VPN |
| CDN or proxy | CDN rate limiting, WAF rule, blocked IP range | Only that specific site | Clear DNS cache, try different DNS |
| Antivirus (local) | HTTPS/SSL inspection intercepting the TLS handshake | Multiple HTTPS sites | Disable SSL inspection in antivirus |
| Corporate/ISP firewall | DPI rule, port blocking, content filtering | Category of sites blocked | Contact network admin or test via mobile |
| VPN/proxy software | Misconfigured tunnel, overloaded VPN server | Many sites via VPN | Disconnect VPN, test direct connection |
| Local TCP/IP stack | Corrupted Winsock, bad network driver, MTU mismatch | Multiple or all sites | Winsock reset, netsh int ip reset |
Diagnose Before You Fix: Three Questions That Identify the Cause
Running fixes without knowing the cause wastes time and can introduce new problems. These three questions narrow the cause to a category before you touch any settings.
Question 1: Does the error appear on multiple sites or just one?
Load three or four completely different sites. If ERR_CONNECTION_RESET appears on all or most of them, the cause is local: your network stack, antivirus, VPN, or proxy configuration. If the error appears only on one specific site or domain, the cause is either server-side, CDN-side, or your ISP blocking that specific destination.
Question 2: Does the error disappear on a mobile connection?
Enable the hotspot on your phone and connect your computer to it instead of your home network, or test directly on your phone. If the site loads on mobile data but not on your home network, the problem is either your home network hardware (router or modem), your ISP’s network, or your computer’s network configuration. If the error appears on mobile data too, the problem is either server-side or related to your computer’s browser or antivirus configuration.
Question 3: Does the error disappear in incognito mode or a different browser?
Try loading the page in an incognito window and in Firefox or Edge. If the page loads in Firefox but not Chrome, the issue is in Chrome’s configuration. If the page loads in incognito but not regular Chrome, the issue is an extension or Chrome-specific cached data. If the page fails in all browsers, the issue is network-level and not browser-specific.
Test the failing URL with a command-line tool that bypasses the browser entirely. On Windows, open Command Prompt and run: curl -I https://thesite.com. On Mac or Linux, the same command works in Terminal. If curl returns data, the connection works at the network level and the issue is in the browser. If curl returns a connection reset error, the issue is at the network or system level.
Fix 1: Restart Your Router and Flush DNS
A router reboot clears its connection state tables and DNS cache. Routers running for weeks or months accumulate stale connection state entries that can cause TCP resets for new connections. This is the first fix to try because it takes under two minutes and resolves a significant portion of ERR_CONNECTION_RESET cases.
- Unplug the power cable from your router and modem (if separate devices)
- Wait 30 seconds
- Plug in the modem first, wait for it to fully connect, then plug in the router
- Wait for the router to finish its startup sequence before testing
After rebooting the router, flush the DNS cache on your computer as well. Chrome maintains its own internal DNS cache separate from the operating system cache. Flush both:
| # Windows: flush OS DNS cache (Command Prompt as Administrator):
ipconfig /flushdns
# Then flush Chrome’s internal DNS cache: # Type in Chrome address bar: chrome://net-internals/#dns # Click the ‘Clear host cache’ button
# Mac: flush OS DNS cache (Terminal): sudo dscacheutil -flushcache sudo killall -HUP mDNSResponder |
Fix 2: Disable VPN and Proxy, Check Proxy Settings
VPNs and proxy servers route your traffic through intermediate servers. When the VPN server is overloaded, experiencing a connection issue, or is geographically far from the destination server, it can introduce connection resets. A misconfigured proxy setting in Windows or Chrome redirects all traffic through a proxy that may not exist or may be refusing connections.
To check proxy settings in Chrome:
- Click the three-dot menu and select Settings
- Click System in the left sidebar
- Click Open your computer’s proxy settings
- In Windows: ensure Use a proxy server is toggled Off unless you specifically require one
- In Mac: ensure all proxy protocol checkboxes are unchecked unless required
To check proxy settings via the Windows registry if the above approach does not reflect the actual setting:
| # Open Command Prompt and check current proxy settings:
netsh winhttp show proxy
# If a proxy is listed and you do not need one, reset it: netsh winhttp reset proxy
# Also check via Registry Editor: # HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings # Look for ProxyEnable: should be 0 (disabled) # If set to 1 and no proxy is needed, change it to 0 |
Some malware configures a proxy server in Windows settings to intercept browser traffic. If you find a proxy enabled that you did not set, disable it and run a malware scan before re-enabling any network settings. This proxy interception produces ERR_CONNECTION_RESET when the malware’s proxy server is not running or is blocking specific connections.
Fix 3: Disable Antivirus HTTPS Inspection
This is the most underdiagnosed cause of ERR_CONNECTION_RESET. Several major antivirus products include a feature called HTTPS scanning, SSL inspection, or web shield that works by inserting the antivirus software between your browser and the web server as a man-in-the-middle. The antivirus decrypts your HTTPS traffic, inspects it for malware, and re-encrypts it before passing it to the browser.
When this inspection process encounters certain TLS configurations, server-side TLS session resumption, or specific cipher suites, it can corrupt the SSL handshake. The server sees a malformed handshake and terminates the connection with a RST packet. Chrome reports ERR_CONNECTION_RESET. The problem typically affects only HTTPS sites, only certain sites with specific TLS configurations, and only the browser while the antivirus is active.
The affected antivirus products and where to disable the feature:
- Avast and AVG: Settings, Protection, Core Shields, Web Shield, Enable HTTPS scanning. Uncheck this option.
- Kaspersky: Settings, Additional, Network, Encrypted connections scanning. Change from Scan encrypted connections to Do not scan encrypted connections.
- ESET: Setup, Internet Protection, Web Access Protection, URL Address Management. Look for HTTPS filtering and disable it.
- Bitdefender: Protection, Online Threat Prevention, Encrypted Web Scan. Turn off the toggle.
- Norton: Settings, Firewall, Traffic Rules. Look for HTTPS scanning options.
After disabling HTTPS inspection, test whether ERR_CONNECTION_RESET clears. If it does, the antivirus HTTPS scanning was the cause. You can add the affected sites to the antivirus exclusions list rather than disabling HTTPS scanning entirely. Each product has a URL exclusion list where you can whitelist specific domains from HTTPS interception.
Fix 4: Reset the TCP/IP Stack and Winsock Catalog
The Windows TCP/IP stack is the system software layer that manages all network connections. Over time, corrupted entries in the Winsock catalog or TCP/IP settings can cause the stack to send malformed packets. Servers receiving malformed packets respond with a RST to terminate the connection. Chrome reports this as ERR_CONNECTION_RESET, often intermittently and across multiple sites.
The fix is resetting these components to their default state. This does not affect any user files or browser data. Run all of these commands in a Command Prompt opened with administrator rights (search for cmd in the Start menu, right-click, select Run as administrator):
| # Reset the Winsock catalog to its default state:
netsh winsock reset
# Reset TCP/IP stack to factory defaults: netsh int ip reset
# Flush DNS resolver cache: ipconfig /flushdns
# Release and renew IP address: ipconfig /release ipconfig /renew
# Restart the computer after running all commands. # The reset only takes effect after reboot. |
On Mac, the equivalent commands for resetting network configuration are:
| # Flush DNS cache on Mac:
sudo dscacheutil -flushcache sudo killall -HUP mDNSResponder
# Renew DHCP lease: # System Settings > Network > select interface > Details > TCP/IP > Renew DHCP Lease
# Or via Terminal on newer macOS: sudo ipconfig set en0 DHCP # Replace en0 with your active interface (check with: ifconfig) |
Fix 5: Adjust the MTU Size
The Maximum Transmission Unit (MTU) is the largest packet size a network connection will transmit without fragmenting it. The standard MTU for Ethernet is 1500 bytes. VPNs, PPPoE connections (common in DSL and some fiber setups), and certain corporate networks use a lower MTU because the VPN or PPPoE headers add extra bytes to each packet, leaving less room for actual data.
When Chrome sends packets that exceed the effective MTU for your connection, the packets get fragmented. Some network equipment, particularly certain firewalls and routers, drops fragmented packets rather than reassembling them. The server never receives the complete request and the connection times out or resets. This manifests as ERR_CONNECTION_RESET specifically on larger data transfers: loading images, downloading files, or submitting forms.
To check your current MTU on Windows:
| # Check current MTU for all interfaces:
netsh interface ipv4 show subinterfaces
# The MTU value appears in the first column. # Standard Ethernet: 1500 # VPN connections often: 1400-1460
# If suspected MTU issue, try setting to 1400 for Wi-Fi: netsh interface ipv4 set subinterface ‘Wi-Fi’ mtu=1400 store=persistent
# Replace ‘Wi-Fi’ with your adapter name from the show command above. # Test increasing values: 1400, 1450, 1472 until stable. |
The method to find the exact optimal MTU for your connection is the ping test with the Do Not Fragment flag. This finds the largest packet that passes through your network without fragmentation:
| # Windows: ping with Don’t Fragment flag and test sizes:
ping -f -l 1472 8.8.8.8 ping -f -l 1400 8.8.8.8 ping -f -l 1300 8.8.8.8
# Start at 1472 and work down until ping succeeds. # Add 28 bytes to the successful value to get optimal MTU. # Example: ping succeeds at 1452, optimal MTU = 1452 + 28 = 1480
# Mac equivalent: ping -D -s 1472 8.8.8.8 # If fragmentation message appears, reduce -s value until ping succeeds. |
MTU issues are most common on computers that connect through a VPN or on DSL internet connections using PPPoE. If you do not use a VPN and have a cable or fiber connection, MTU is unlikely to be the cause of ERR_CONNECTION_RESET. Skip this fix if the previous ones have not pointed toward a network-level issue.
Fix 6: Change DNS Server
Stale or incorrect DNS cache entries can route Chrome to a server IP address that is no longer serving the site, triggering a connection reset when Chrome tries to connect. Public DNS servers maintained by Google and Cloudflare have faster propagation of DNS changes than most ISP-provided resolvers, meaning they are less likely to return cached records pointing to decommissioned servers.
To change DNS on Windows:
- Press Win+R, type ncpa.cpl, press Enter to open Network Connections
- Right-click your active network adapter and select Properties
- Double-click Internet Protocol Version 4 (TCP/IPv4)
- Select Use the following DNS server addresses
- Enter 8.8.8.8 as Preferred DNS and 8.8.4.4 as Alternate DNS (Google), or 1.1.1.1 and 1.0.0.1 (Cloudflare)
- Click OK and close
To change DNS on Mac (macOS Sonoma or Ventura):
- Open System Settings and click Network
- Click the active connection and select Details
- Click the DNS tab
- Click the + button and add 1.1.1.1, then add 1.0.0.1
- Remove the existing DNS entries if they are from your ISP
- Click OK
Fix 7: Disable or Reconfigure Firewall Rules
Windows Firewall and third-party firewalls can block outbound connections to specific ports or IP addresses and send a RST packet to terminate the blocked connection. This produces ERR_CONNECTION_RESET rather than ERR_CONNECTION_REFUSED when the firewall sends the RST actively rather than silently dropping the packet.
To test whether the Windows Firewall is the cause, temporarily disable it:
| # Disable Windows Firewall for testing (Command Prompt as Admin):
netsh advfirewall set allprofiles state off
# Test the failing site. If it loads, the firewall has a blocking rule.
# Re-enable immediately after testing: netsh advfirewall set allprofiles state on
# To add a permanent allow rule for Chrome instead of disabling firewall: netsh advfirewall firewall add rule name=’Chrome Allow’ dir=out action=allow program=’C:\Program Files\Google\Chrome\Application\chrome.exe’ enable=yes |
Never leave the firewall disabled after testing. Re-enable it immediately. The test only requires a few seconds to confirm whether the firewall is blocking the connection. If disabling the firewall resolves the error, re-enable it and then investigate which specific rule is blocking Chrome rather than disabling the firewall permanently.
Fix 8: Clear Browser Cache and Disable Extensions
While ERR_CONNECTION_RESET is primarily a network-level error, browser cache corruption can contribute to it by sending malformed request headers that cause the server to reset the connection. Extensions that modify request headers, inject scripts, or proxy browser traffic can also trigger server-side resets when their modifications conflict with the server’s expectations.
To clear the Chrome cache:
- Press Ctrl+Shift+Delete in Chrome
- Set the time range to All time
- Check Cached images and files and Cookies and other site data
- Click Clear data and restart Chrome
To test whether an extension is the cause, open an incognito window. Extensions are disabled in incognito by default. If the page loads in incognito but not in a regular window, disable all extensions via chrome://extensions and re-enable them one at a time to identify which one triggers the reset. Network-modifying extensions including VPN helpers, ad blockers with network filtering, privacy tools, and developer proxies are the most common culprits.
Fix 9: Update Network Adapter Drivers
Outdated or corrupted network adapter drivers can produce ERR_CONNECTION_RESET through malformed packets that trigger RST responses from servers. This is more common after a Windows Update that included a driver update which introduced a regression, or on systems where the network driver has not been updated in a long time.
To update network adapter drivers on Windows:
- Press Win+X and select Device Manager
- Expand the Network adapters section
- Right-click your network adapter (look for entries containing Wi-Fi, Ethernet, or the adapter manufacturer name such as Intel, Realtek, or Broadcom)
- Select Update driver
- Choose Search automatically for drivers
- If Windows reports the best driver is already installed, visit the laptop or motherboard manufacturer’s website to download the latest driver directly
If a recent driver update coincided with the start of the ERR_CONNECTION_RESET errors, roll back the driver instead: right-click the adapter in Device Manager, select Properties, go to the Driver tab, and click Roll Back Driver if the option is available.
Server-Side Causes of ERR_CONNECTION_RESET (For Site Owners)
When multiple visitors report ERR_CONNECTION_RESET on your site while it works fine for others, the cause is in your server configuration, not in the visitors’ devices. The server or an upstream component is sending RST packets for specific requests.
Server overload and TCP backlog exhaustion
When a server receives more connection requests than it can handle, the operating system’s TCP accept queue fills up. New connection requests that arrive when the queue is full are either dropped silently or, depending on the kernel configuration, answered with a RST. Chrome interprets the RST as ERR_CONNECTION_RESET. The fix is reducing server load through caching, increasing the TCP backlog size in the server configuration, or upgrading server capacity.
| # Check current server load on Linux:
top free -h
# Check TCP connection state counts: ss -s
# In Nginx, increase the accept backlog: # In /etc/nginx/nginx.conf, worker_connections directive: events { worker_connections 1024;Â # increase from default 512 }
# Also increase the system backlog in /etc/sysctl.conf: net.core.somaxconn = 1024 net.ipv4.tcp_max_syn_backlog = 2048 # Apply: sudo sysctl -p |
SSL/TLS misconfiguration producing connection resets
Misconfigured TLS settings on the server cause the TLS handshake to fail and the server to send a RST. Common causes include an expired or revoked SSL certificate, TLS protocol version mismatches where the server supports only TLS 1.0 or TLS 1.1 which Chrome no longer accepts, unsupported cipher suites, and SSL certificate chain problems where intermediate certificates are missing.
To test SSL configuration from the command line:
| # Test the TLS handshake directly:
openssl s_client -connect yourdomain.com:443
# If the handshake fails with ‘connection reset by peer’, # the TLS configuration is causing the reset.
# Check which TLS versions the server supports: openssl s_client -connect yourdomain.com:443 -tls1_2 openssl s_client -connect yourdomain.com:443 -tls1_3
# Also run through SSL Labs for a full certificate and configuration check: # https://www.ssllabs.com/ssltest/ |
CDN or WAF rate limiting and IP blocking
A CDN or Web Application Firewall that has flagged a visitor’s IP address as a threat, or that is rate-limiting requests from a shared IP range, sends RST packets for blocked connections. The affected visitor sees ERR_CONNECTION_RESET while other visitors on different IP addresses see the site normally. If you are using Cloudflare, check the Firewall Analytics section of the dashboard for blocked requests and verify that the WAF rules are not triggering false positives for legitimate traffic.
Quick Reference: Match Symptom to Fix
| Symptom Pattern | Most Likely Cause | Fix to Apply |
| Error on all sites, all browsers | Local network: TCP/IP stack or MTU | Netsh winsock reset, router reboot, MTU adjustment |
| Error on all sites, Chrome only | Chrome settings or extension | Clear cache, disable extensions, reset flags |
| Error on HTTPS sites only | Antivirus HTTPS scanning | Disable SSL inspection in antivirus settings |
| Error disappears on mobile hotspot | Home network or ISP issue | Router reboot, change DNS, contact ISP |
| Error on one specific site only | Server-side or CDN blocking your IP | Test via VPN, clear DNS cache, check SSL Labs |
| Error started after installing software | New VPN, proxy, or antivirus installed | Disable the new software and test |
| Error on file downloads or large pages | MTU mismatch causing packet fragmentation | Adjust MTU size, ping MTU test |
| Error started after Windows Update | Network driver regression | Roll back network adapter driver |
| Error disappears in incognito | Browser extension conflict | Disable all extensions, identify offender |
| Error with proxy found in settings | Malware-set proxy | Remove proxy, run malware scan |
Advanced Diagnosis: Using Wireshark to Find the Source of the RST
When none of the standard fixes resolve ERR_CONNECTION_RESET and the error persists across different networks and devices, using a packet capture tool identifies exactly which device is sending the RST packet. This is the definitive diagnostic for persistent or unusual cases.
Wireshark is a free, open-source packet analyzer. The process:
- Download and install Wireshark from wireshark.org
- Open Wireshark and select your active network interface
- In the filter bar, enter the following filter to capture only traffic to the affected site, replacing the IP address with the site’s actual IP (found by running nslookup sitename.com in Command Prompt):
| # Wireshark capture filter to find RST packets for a specific host:
# In the Wireshark filter bar, type: host 203.0.113.42 # Replace 203.0.113.42 with the actual IP of the failing site
# To filter specifically for RST packets: tcp.flags.reset == 1
# Combine both filters: host 203.0.113.42 && tcp.flags.reset == 1 |
- Click Start Capture
- Reproduce the ERR_CONNECTION_RESET error by loading the failing page
- Stop the capture and look for packets with the RST flag set
- The Source column of RST packets tells you which IP sent them. If the source is the web server’s IP, the reset is server-side. If the source is your router’s IP, the router is sending the RST. If the source is a different IP entirely, an intermediate device or antivirus is injecting RST packets.
You do not need to understand all of Wireshark’s output to use this diagnostic. The single key piece of information is: which IP address appears in the Source column of any packet with RST in the Flags column? That IP identifies who terminated the connection.
Frequently Asked Questions
What causes ERR_CONNECTION_RESET in Chrome?
ERR_CONNECTION_RESET appears when a TCP connection between Chrome and a server is forcibly terminated by a RST packet. The RST can come from the web server itself, from an intermediate network device such as a firewall or VPN, from antivirus software intercepting HTTPS traffic, from a corrupted local TCP/IP stack, or from an MTU mismatch causing packets to be dropped. Identifying which of these is the source determines the correct fix.
How is ERR_CONNECTION_RESET different from ERR_CONNECTION_REFUSED?
ERR_CONNECTION_REFUSED means the server received a connection request and explicitly rejected it, usually because nothing is listening on that port. The server sends a RST in response to the initial SYN packet. ERR_CONNECTION_RESET means the connection was established successfully and then abruptly terminated mid-session, after the TCP handshake completed. The RST arrives during the TLS handshake or data transfer phase rather than during connection setup.
Why does ERR_CONNECTION_RESET happen on only one site?
When the error is limited to a single site, the cause is almost certainly on the server side or involves the CDN or WAF protecting that site. Possible causes include the server being overloaded and sending RST packets for connections it cannot handle, a WAF rule blocking your IP address or request pattern, a TLS configuration problem on the server, an expired or misconfigured SSL certificate, or your ISP specifically blocking connections to that server or IP range. Test by connecting through a different network (mobile hotspot) or VPN to confirm whether the block is IP-specific.
Can a VPN cause ERR_CONNECTION_RESET?
Yes. VPN software adds a network hop between your browser and the destination server. If the VPN server is overloaded, uses an incompatible MTU, has a routing issue to the destination, or has a kill-switch or firewall rule that blocks certain connections, Chrome will receive RST packets and report ERR_CONNECTION_RESET. Disconnect from the VPN and test directly. If the error clears without the VPN, the VPN configuration is the cause. Try switching to a different VPN server location or adjusting the VPN’s MTU settings.
Does antivirus software cause ERR_CONNECTION_RESET?
Yes, when the antivirus has HTTPS scanning or SSL inspection enabled. Products including Avast, AVG, Kaspersky, ESET, and Bitdefender intercept HTTPS connections by acting as a man-in-the-middle between your browser and the web server. When this interception corrupts a TLS handshake, the server sends a RST. The error typically affects HTTPS sites and often only specific sites or TLS configurations, not all HTTPS traffic. Disabling HTTPS scanning in the antivirus settings is the fix. Most products allow you to add specific sites to an exclusion list rather than disabling HTTPS scanning entirely.
What is the Winsock reset and is it safe?
The Winsock reset command (netsh winsock reset) restores the Windows Sockets API catalog to its default configuration. Winsock is the Windows software layer that handles all network communication between applications and the TCP/IP stack. Corruption in the Winsock catalog can cause malformed packets and connection resets. The reset is safe: it does not affect user files, browser data, or installed applications. It does require a computer restart to take effect. After the restart, the network stack operates from clean default settings.
My ERR_CONNECTION_RESET only happens on large downloads or specific pages. Why?
This pattern strongly suggests an MTU mismatch. Large pages and file downloads generate larger TCP packets than simple text pages. When the effective MTU on your connection is lower than the packet size Chrome is using, the packets get fragmented. Some network devices drop fragmented packets rather than reassembling them, causing the connection to reset on large transfers while working fine for small requests. The fix is finding the correct MTU for your connection using the ping with the Do Not Fragment flag method and setting the MTU accordingly.
How do I fix ERR_CONNECTION_RESET if I am a site owner?
If multiple visitors report ERR_CONNECTION_RESET on your site, check these in order: run your domain through ssllabs.com/ssltest to identify any TLS configuration problems that would cause the server to reset handshakes; check your web server error logs for connection reset entries or repeated SYN packets that are not completing; check your CDN or WAF firewall logs for blocked requests; check server resource utilization for overload conditions where the TCP accept queue may be filling up; and run openssl s_client against your domain to test the TLS handshake directly from the command line.
