How to Fix the ERR_CONNECTION_RESET Error (10 Methods)

ERR_CONNECTION_RESET means the connection between Chrome and the website ended abruptly

Chromium defines its underlying CONNECTION_RESET error as a connection reset corresponding to a TCP reset, or RST. Chrome received no complete web response because the browser, device, network, security layer, CDN, or server terminated the connection first.

That makes this error different from ERR_NAME_NOT_RESOLVED, which points to DNS, and ERR_CONNECTION_REFUSED, which means the destination rejected the connection attempt.

A reset can happen after Chrome has already found the IP address and started communicating with it.

The right fix depends on scope. If one browser fails, inspect that browser. If every device on one Wi-Fi connection fails, inspect the router or network.

If visitors across several networks fail on one website, the site owner needs to inspect the server, firewall, CDN, and application.

Before you retry a payment or form: confirm whether the first submission completed. A reset can occur after the server accepted a request but before the browser received the response. Repeating a non-idempotent action may create a duplicate order, charge, or message.

What causes ERR_CONNECTION_RESET?

Common causes include:

• an unstable Wi-Fi, mobile, or broadband connection;

• a router or network device that drops the session;

• a VPN, proxy, captive portal, or filtering service;

• antivirus HTTPS inspection or a firewall rule;

• a damaged Windows Winsock or TCP/IP configuration;

• a browser extension, corrupt site data, or outdated browser;

• a CDN, web application firewall, load balancer, or origin rule that resets traffic;

• an overloaded, crashing, or incorrectly configured web server; or

• a WordPress plugin or application process that fails on a specific request.

The Chromium source maps the error to code -101 and explicitly distinguishes it from closed, refused, failed, unresolved, and disconnected conditions.

That definition is useful because it stops you from treating every Chrome connection message as the same fault.

Diagnose the failing layer first

Run three quick comparisons before changing settings:

Test	What the result suggests
Open the same URL in another browser	If it works, focus on Chrome settings, extensions, or site data
Open several unrelated websites	If they also fail, focus on the device, router, proxy, VPN, or ISP path
Switch between broadband/Wi-Fi and mobile data	If only one network fails, focus on that network path or its public IP
Open the affected website from another device and network	If it fails everywhere, the website owner should inspect the server side
Open another page on the same website	If one URL fails, inspect that route, plugin, request size, or application process

Developers can also test outside Chrome:

curl.exe -I -v https://example.com/
Test-NetConnection example.com -Port 443

Test-NetConnection checks whether Windows can establish a TCP connection to port 443. It does not prove that HTTP, TLS, the application, or every page works. curl -v shows more of the connection sequence, but its output can contain hostnames, IP addresses, and headers. Remove secrets before sharing it.

Now apply the method that matches your evidence.

1) Reload safely and confirm the website address

Check the URL for a spelling mistake, remove any accidental punctuation, and reload once. If you reached the error after clicking Submit, Pay, Upload, or another state-changing action, check the account, inbox, or order history before sending it again.

Open the website’s home page as well as the failed URL. A working home page with one broken path points away from your whole internet connection. It may indicate a route-specific application problem, security rule, large upload, or request that takes too long.

Google’s Chrome connection-error guide likewise starts with checking the URL, reloading, and deciding whether one or several websites are affected.

If the site fails on several independent networks, stop repeating client-side resets. Report it to the site owner or continue with methods 9 and 10 if you manage the website.

2) Restart Chrome, the device, and network equipment

Close Chrome completely, reopen it, and retry. If that does not help, restart the device. This clears temporary browser and operating-system state without changing permanent network settings.

When multiple devices fail on the same home or small-office network, restart the router or optical network terminal using the vendor or ISP procedure. A practical sequence is:

• Save active work and stop important transfers.

• Turn off the router and upstream modem or terminal if you control both.

• Wait about 30 seconds.

• Power the upstream device first and wait for it to reconnect.

• Power the router and wait for Wi-Fi and internet service to return.

• Repeat the same URL test.

Do not restart shared business equipment without authorization. If your ISP manages the device, use its approved support process rather than pressing a reset pin; a factory reset can erase the connection configuration.

3) Update Chrome and the operating system

An outdated browser or operating-system networking component can preserve a bug that current releases have fixed.

In Chrome, open Menu > Help > About Google Chrome, allow any available update to install, and relaunch the browser.

Install supported Windows or macOS updates through the operating system’s normal update screen. Restart when the update requires it. On managed computers, let the administrator control the update schedule.

Do not download “Chrome repair” tools or network-driver packages from random websites. Use Chrome’s built-in updater, the operating-system update service, or the device manufacturer’s official support page.

If the error began immediately after an update, record the exact browser and OS versions. That timing helps support distinguish a regression from a long-standing network problem.

4) Test Incognito mode, extensions, and site data

Open the same URL in a Chrome Incognito window.

Chrome normally prevents extensions from running in Incognito unless you have explicitly allowed them, so a successful Incognito test is evidence that an extension or stored browser data may be involved.

If the page works in Incognito:

• Open chrome://extensions/.

• Turn off extensions that filter traffic, rewrite pages, manage proxies, block scripts, or scan links.

• Test the normal window again.

• Re-enable extensions one at a time until the error returns.

• Remove or repair only the extension you identify.

Then clear data for the affected site rather than erasing the whole browser immediately.

Open the site controls from the address bar, find its stored data, remove it, and sign in again. Clearing cookies can sign you out and remove local preferences or an unsaved cart.

Google’s official procedure recommends Incognito testing, disabling extensions, and deleting browsing data for connection and loading problems.

If the error also appears in another browser, move on instead of repeatedly reinstalling Chrome.

5) Disconnect a VPN or correct the proxy

A VPN or proxy sits between the browser and website. If that intermediary closes the TCP session, blocks the host, mishandles TLS, or uses an unhealthy route, Chrome can report a reset.

Disconnect one layer at a time:

• pause the VPN and test through the normal internet connection;

• if you use a manual proxy, verify its address, port, credentials, and automatic-configuration script;

• sign in to any hotel, airport, campus, or café captive portal; and

• on a managed network, ask IT whether the destination or category is blocked.

On Windows 11, review Settings > Network & internet > Proxy. Do not delete a workplace proxy or PAC configuration merely because it exists.

Record the current settings first and change them only when you own the device or have approval.

If the website works without the VPN, try another approved VPN location or contact the VPN provider with the failing hostname and time. If it works on mobile data but not the office network, the office proxy or firewall becomes a stronger suspect.

6) Check firewall and antivirus web protection

Security software can reset a connection when a rule blocks the destination, its HTTPS-inspection component fails, or the browser lacks permission to connect.

Review the product’s event log, quarantine, web protection, and firewall rules for the exact time of the failure.

Prefer a controlled allow rule or vendor-documented diagnostic mode over turning protection off.

If an authorized temporary test requires disabling a component, disconnect from unnecessary services, keep the test brief, and restore protection immediately.

Never advise users to browse normally with the firewall or antivirus disabled.

Check Windows Security for Chrome’s network permission and review third-party endpoint tools separately.

Company-managed HTTPS inspection may require a trusted enterprise certificate or a policy correction that only IT can provide.

If security software blocks only one website, verify the domain carefully before allowing it. A warning can represent a real threat rather than a false positive.

7) Clear DNS only when the address may be stale

DNS normally finishes before the TCP reset occurs, so flushing DNS is not the universal fix for ERR_CONNECTION_RESET.

It becomes relevant when the website recently moved, different networks resolve it to different addresses, or your device holds a stale destination.

On Windows, open PowerShell and run:

Clear-DnsClientCache

Or use Command Prompt:

ipconfig /flushdns

Microsoft documents these as equivalent ways to clear the Windows DNS client cache. Retry the website once.

If nothing changes, do not keep flushing; investigate the layer that actually resets the connection.

You can compare answers without permanently changing your resolver:

Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Type A -Server 1.1.1.1
Resolve-DnsName example.com -Type A -Server 8.8.8.

Different answers can be legitimate when a CDN routes users by location. Look for stale, private, or clearly incorrect destinations rather than assuming every difference is a fault.

Our Pakistan nameserver guide explains how recursive lookups reach the servers that hold a domain’s records.

8) Reset Winsock and TCP/IP on Windows

Use this advanced method only when several applications or websites fail on one Windows device and simpler tests did not help.

It changes system networking state, requires administrator rights, and needs a restart.

Before proceeding, record any static IP address, DNS server, proxy, VPN, or specialist network configuration. Do not run the reset over a remote connection that you could lose.

Open Windows Terminal (Admin) or Command Prompt (Admin), then run:

netsh winsock reset
netsh int ip reset resetlog.txt

Restart Windows and test again. Microsoft’s Winsock documentation says the first command returns the Winsock catalog to a clean state.

Its TCP/IP reset procedure explains that the second command rewrites TCP/IP and DHCP configuration parameters and requires administrator access.

Restore any approved static or enterprise settings after the restart. If only one website failed before the reset, this method was probably too broad; use the website-owner checks instead.

9) Inspect the CDN, firewall, and server logs

If the error affects one website across different browsers, devices, and networks, work from the server side.

Record the exact UTC or Pakistan time, requested URL, client public IP where appropriate, request method, and whether the failure happens before headers, during an upload, or partway through a download.

Check each hop:

• CDN or reverse proxy: review edge events, origin health, TLS mode, upstream timeouts, and whether bypassing the edge on a controlled test hostname changes the result.
  

• Web application firewall: find blocked or challenged requests matching the client IP, path, rule ID, and time. Tune the confirmed false positive narrowly instead of disabling the WAF.
  

• Origin firewall: confirm that it allows the CDN or load balancer addresses you actually use and does not rate-limit legitimate traffic.
  

• Web server: correlate access and error logs for worker crashes, upstream failures, process limits, TLS errors, and abrupt closes.
  

• Application: inspect the route, PHP or runtime logs, database failures, memory exhaustion, and long-running requests.

Apache calls its error log the first place to look when server operation fails, and its documentation recommends correlating error and access-log entries.

In cPanel, Metrics > Raw Access can provide downloadable Apache or NGINX access logs when the host has enabled that interface.

Logs can contain visitor IPs, URLs, and other sensitive details, so share the smallest relevant extract.

Do not simply increase every timeout. A timeout increase can hide a slow query, dead upstream, or exhausted worker pool.

Fix the event shown in the logs, then repeat the same request from the networks that originally failed.

10) Isolate WordPress faults and send a useful support report

When one WordPress site or route triggers resets, create a backup and reproduce the issue in staging when possible.

Check WordPress Tools > Site Health, PHP and web-server logs, resource usage, recent deployments, and the exact request that fails.

Test plugins methodically:

• Deactivate the most likely caching, security, redirect, optimization, or proxy-integration plugin.

• Retry the same request.

• If needed, deactivate all plugins in staging and test again.

• Reactivate them one at a time until the reset returns.

• Test a standard theme only when the evidence points to theme or rendering code.

The WordPress troubleshooting documentation explains how to deactivate plugins through the dashboard, database, FTP, or File Manager when the administration screen is unavailable.

Do not rename or delete plugin folders on a live store without a backup, maintenance plan, and rollback route.

If you need help with a website hosted by us, use our Truehost support page. Include:

• the full URL and approximate time of failure;

• your browser, operating system, and network or ISP;

• whether another device, browser, and mobile data work;

• the curl -v result with secrets removed;

• a sanitized Chrome HAR when requested;

• the latest relevant server, CDN, WAF, or WordPress log lines; and

• the change that happened before the error began.

Chrome DevTools can export a sanitized HAR that omits sensitive Cookie, Set-Cookie, and Authorization headers by default.

Still inspect the file before sending it because URLs, query parameters, and response data can contain private information.

If the current plan or server cannot sustain legitimate request volume after the underlying fault is confirmed, review our cPanel hosting options.

Upgrading resources should follow evidence of exhaustion; it should not replace diagnosis.

Verify that the reset is fixed

Repeat the same URL, browser, device, and network combination that originally failed.

Then test a second network and the important site paths: home page, login, checkout, upload, API endpoint, and any route involved in the incident.

For a website-wide problem, monitor the server and edge logs while you test. A page that loads once does not prove the fault has gone if a firewall rule, worker crash, or bad upstream fails intermittently.

The fastest lasting fix is the narrowest one supported by evidence:

• remove one broken extension,

• correct one proxy,

• repair one Windows network stack,

• tune one false-positive WAF rule, or

• fix one failing application path.

Avoid changing all five layers at once, because you will not know what solved the problem or what created the next one.