ERR_CONNECTION_RESET on only one site
One site fails with ERR_CONNECTION_RESET and the rest work? A step-by-step check: network, extensions, proxy, DNS, clock, and SNI filtering with curl.
Every other site loads, but one keeps failing with "This site can't be reached" and ERR_CONNECTION_RESET. Reloading does nothing. This guide is a decision tree. Each step either finds the cause or rules one out, and the order goes from the quickest checks to the most telling one.
What "connection reset" actually means
A TCP connection can end politely, or it can be torn down at once with a reset packet (RST). Chrome and other Chromium browsers show ERR_CONNECTION_RESET when a reset arrives before the page is delivered. Firefox shows a similar "The connection was reset" page. The reset can come from the site's server, from software on your own computer, or from a device in the middle of the network that pretends to be one of the two ends.
That is why the same error has such different causes. The trick is to find out who sent the reset and when.
Step 1: is it really only one site?
Open two or three unrelated sites, including one you rarely visit. If several fail, the problem is your connection, router or device, not that one site. Restart the router and check whether other devices on the same network work. If only one site fails, keep going.
Step 2: is it only one network?
This is the most informative test, and it is free. Open the site on mobile data instead of Wi-Fi, or tether your laptop to your phone. If the site opens on one network and resets on the other, the failing network is involved. The usual causes are covered in Why does a site open on mobile data but not on Wi-Fi? If it fails everywhere, the site itself or your device is the more likely cause.
Step 3: another browser, a private window, no extensions
Try a private or incognito window, where most extensions are off by default. Then try a different browser. Ad blockers, privacy extensions, "safe browsing" add-ons and corporate browser policies can all close connections. If the site works in a private window, turn your extensions back on one at a time until the error returns.
Step 4: turn off other VPNs, proxies and HTTPS scanning
Anything that sits in the path of your traffic can reset a connection it dislikes:
- Another VPN or proxy app. Turn it off completely and test again.
- Antivirus "HTTPS scanning" or "web protection". Some security suites inspect encrypted traffic and cut connections they consider risky. Pause that feature briefly to test, then turn it back on.
- The system proxy. On Windows, look in Settings → Network & internet → Proxy. On macOS, look in System Settings → Network → your connection → Details → Proxies. A proxy you do not recognise, or a leftover one from an old app, can break single sites. Remove only what you know you set yourself, and ask your IT team on a managed computer.
Step 5: clear the DNS cache and try encrypted DNS
If the site moved servers, your device may still use the old address, which can reset or time out. Flush the caches:
# Windows (Command Prompt)
ipconfig /flushdns
# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
# Chrome's own cache: open chrome://net-internals/#dns and click "Clear host cache"
Next, compare your network's answer with an independent resolver: nslookup example.com and then nslookup example.com 1.1.1.1. If they differ and only the independent answer works, your network's DNS is the problem. Encrypted DNS fixes that kind of block, as explained in DoH and DoT. Different addresses alone are not proof, since large sites hand out different servers to different networks.
Step 6: check the date and time
A wrong clock usually produces a certificate error rather than a reset, but it is a ten-second check. Turn on automatic date and time, then reload. Never click through a certificate warning to "get past" a failing page.
Step 7: is the site down?
Check the site's status page or official social account, or use a public "down for everyone or just me" checker. If the site is down, wait. Keep in mind that a checker tests from its own servers, so "up" there does not prove it is reachable from your network.
Step 8: read the reset with curl
If the site still resets only on one network, look at the handshake itself. curl is built into Windows 10 and 11, macOS and most Linux systems. Run it in a terminal with your site in place of example.com:
curl -v https://example.com
A healthy connection prints a few lines like these, then the page headers. The exact wording depends on your curl version and TLS library:
* Trying 203.0.113.10:443...
* Connected to example.com (203.0.113.10) port 443
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
...
< HTTP/2 200
The pattern that points to name-based filtering looks like this:
* Trying 203.0.113.10:443...
* Connected to example.com (203.0.113.10) port 443
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* Recv failure: Connection reset by peer
curl: (35) Recv failure: Connection reset by peer
Read it line by line. "Connected" means the TCP connection to the server's IP address worked, so the address is not blocked outright. "Client hello" is the first TLS message, and it carries the site name in plain text in a field called SNI. "Connection reset by peer" right after it means something cut the connection as soon as that name was visible, before the server could answer. Some networks close the connection quietly instead, which curl reports as an unexpected end of file or an SSL "syscall" error, and Chrome may show ERR_CONNECTION_CLOSED.
Compare with other outcomes:
| What curl shows | Likely meaning |
|---|---|
| Could not resolve host | DNS failure or DNS blocking. Go back to Step 5 |
| Stuck at "Trying", then a timeout | The IP address is unreachable: an IP block, a firewall or a down server |
| Reset or closed right after "Client hello", only on one network | Probably SNI filtering on that network |
| Handshake completes, then an HTTP error code | The site answered. The problem is on its side or your account |
To strengthen the case, run the same command on another network. If it works there, the filter belongs to the first network. This is not a guess about a rare situation. A 2020 OONI and Centre for Internet and Society study found TLS connections cut right after the ClientHello for certain sites on Bharti Airtel, and SNI combined with the destination address on Reliance Jio. CIS separately reported Jio using SNI inspection, and the report was discussed on the ntc.party forum. More background: How to check if a website is blocked.
Where GreenTunnel helps, and where it does not
GreenTunnel is an on-device local VPN that we make, so read this part knowing we are biased. It targets two of the causes above:
- SNI filtering. It reshapes the first TLS packets of a connection, for example by splitting the Client hello or its TLS record, so a filter that looks for a site name does not find it in one piece. How it works: SNI, DPI and TLS record splitting.
- DNS blocking. Lookups go over encrypted DNS (DoH or DoT) to Cloudflare, Google or Quad9, so the network cannot quietly return a fake answer.
Its Inspect URL tool runs the comparisons from Steps 5 and 8 for one site on the network you are on, and says whether the site is name filtered, given a fake DNS answer, blocked by IP address, or fine. If a technique works, you can tap Use this technique.
It will not help when:
- the site is down, or the reset comes from the site's own server or protection service,
- the block is by IP address, which shows up as a timeout at "Trying",
- a workplace, school or other managed network blocks the site on purpose. That network's rules are its owner's to set. Respect the policy and ask the administrator if you need access for your work,
- the cause is an extension, antivirus or stale DNS on your own device. Fix those directly.
Honest limits and responsible use
GreenTunnel does not hide your IP address and is not an anonymity tool. It cannot get around IP blocks, network shutdowns or allowlists, and it does not promise to open any specific site. Filters change over time and differ between ISPs, so a result today may differ next month.
FAQ
Is ERR_CONNECTION_RESET always a sign that a site is blocked?
No. Extensions, antivirus HTTPS scanning, a leftover proxy, stale DNS or the site itself can all cause it. Blocking becomes likely only when the reset happens on one network, right after the Client hello, and the site works elsewhere.
Why does the site work on mobile data but reset on Wi-Fi?
The two networks use different providers, resolvers and filters. One of them may read the site name or answer DNS differently. Run curl -v on both and compare where each stops.
Will clearing cookies fix a connection reset?
Rarely. Cookies are sent after the connection is set up, while most resets happen before. Clearing site data can help when the site itself rejects a bad session, which usually shows an HTTP error instead.
Can GreenTunnel fix a reset caused by my company firewall?
It is not meant to. A managed network blocks sites by its owner's policy. Ask the administrator instead of trying to get around it.
Sources
- OONI and Centre for Internet and Society, Investigating TLS blocking in India, July 2020.
- Centre for Internet and Society, Reliance Jio is using SNI inspection to block websites.
- ntc.party forum, SNI filtering by Indian ISP Reliance Jio.
- curl project, curl manual (the
-voption).