My friend texted me a screenshot last weekend. ERR_TUNNEL_CONNECTION_FAILED, with the wall of red text below it. “The site is down,” the page announced. He had already tried two other sites in the same Chrome window and they both loaded. He opened the failing site in Firefox on the same laptop and it loaded. He texted me again: “Why does Chrome think the internet is broken when it is clearly not.”
I have had this conversation with three different people in the last six months. The answer is the same every time, because Chrome is making the same mistake every time. It is reading a tunnel handshake failure as a server problem, when the actual cause is almost always one of three things sitting between the browser and the page. A misconfigured proxy, a stale DNS cache, or a piece of software that quietly refuses the connection without telling you.
This article is the walk-through I gave my friend, written down so the next person who hits it can skip the back-and-forth.
What Chrome is actually saying
Chrome has a specific error family for problems during the HTTPS handshake. The handshake is the back-and-forth where your browser and the website agree on encryption keys before any actual page data moves. That handshake goes through a tunnel, which is just the encrypted pipe between your browser and whatever is forwarding the request. If the tunnel never finishes building, the browser gives up and prints one of a few related codes.
ERR_TUNNEL_CONNECTION_FAILED is the specific case where the tunnel build failed because something in the middle refused, dropped, or never answered. That something is almost always a proxy, a DNS server, or a security tool. The browser does not know which one, so it falls back to its default message, which is “this site may be down or moved.” That message is wrong nine times out of ten. The site is fine. The handshake never even reached the site.
A useful comparison is what happens with ERR_CONNECTION_TIMED_OUT. That error means the server did not respond at all. The request reached the network, the network tried to deliver it, and silence came back. Different cause, different fix. If your error is timeout, the article you want is the one about servers not responding, not the one you are reading.
Why the same fix works for most people
The fix that solves most of these cases is a one-minute check of the proxy settings. Most home users do not need a manual proxy. If one is set, it is almost always a leftover from a corporate VPN that was uninstalled six months ago, a privacy browser extension that poked at the system proxy and then got removed, or the rare case of actual malware rewriting the setting. The result is the same: a stale address that breaks specific domains without breaking the rest of your browsing.
On Windows, open Settings, go to Network and Internet, then Proxy, and look at the manual proxy section. Anything listed there that you did not set yourself should be turned off. There is also a switch called “Automatically detect settings” that should usually be off unless you are on a managed corporate network. Both are reversible in ten seconds.
On macOS, the equivalent path is System Settings, then Network, then Details, then Proxies for your active interface. The toggles mirror Windows: auto-detect at the top, then a stack of toggles for specific proxy types. Anything you did not deliberately enable should be turned off.
When the proxy panel is clean and the error is still there, the next stop is a DNS flush. Both Windows and macOS cache DNS answers, and a stale cache can hold onto a broken entry for hours after the underlying record has been fixed upstream. The fix is a single command on each platform, followed by a reboot to make sure everything picks up the fresh cache.
If DNS flush alone does not hold, the next step is switching to a public DNS provider. Cloudflare’s 1.1.1.1, Google’s 8.8.8.8, and OpenDNS at 208.67.222.222 are the three public options most people default to. The change is reversible, the speed difference is small, and the privacy posture of any of the three is better than a flaky ISP resolver.
For people who reach the VPN layer, the test is the simplest of the bunch. Disconnect the VPN and reload the failing page. If the page loads, the VPN client is the cause. Some clients have a kill switch that needs to be off. Some need a different protocol. A few just need a reinstall. There is no single cure because every VPN client behaves a little differently, and the official support article for your specific client is the right place to look next.
The bucket my friend was actually in
When my friend walked through the steps, he found a manual proxy address in his Windows settings that he had never seen before. He did not know where it came from. Turning it off fixed the error in under a minute.
His bucket, in the language of debugging: browser-specific, but everywhere. The page loaded in Firefox, so the page was fine. The page loaded in Chrome on his phone over the same Wi-Fi, so the network was fine. The problem was the Chrome instance on his laptop, which was using a setting that pointed at a proxy server that no longer existed.
The four buckets worth thinking about before you start:
- The failure is page-specific. The issue is the page. Try again in a few minutes, or open from a different IP via a VPN.
- The failure is network-specific. The issue is your network, your router, your captive portal, or your gateway.
- The failure is browser-specific but everywhere. The issue is Chrome or your extensions. Most common for this error.
- The failure is everything-everywhere. The issue is your network adapter or your ISP. Rare for this error, but worth checking the network adapter if everything else fails.
The minute you spend figuring out which bucket you are in will save you from changing five things at once and not knowing which one worked.
Company networks and the one case you cannot fix yourself
There is a fifth cause that is harder to address on your own, and worth flagging because people waste hours on it. Some corporate gateways reject HTTPS traffic on non-standard ports and report it as ERR_TUNNEL_CONNECTION_FAILED. Broadcom’s cloud web gateway has been documented to behave this way, and other enterprise gateways may as well.
When the error only happens on office Wi-Fi and never on your home network, that is almost certainly the cause. The only path forward is to ask IT to allow the site or to use the VPN they provide to tunnel out of the gateway. Local fiddling will not help. The same logic applies for school networks, hotel captive portals, or any other managed network where you do not control the gateway.
This is the case I should have flagged earlier in my friend’s debugging. He works from home, so the office gateway was not the cause, but if he had been at his company’s office, the fix would have been IT, not his local machine.
Errors that get conflated with this one in forum threads
When someone posts ERR_TUNNEL_CONNECTION_FAILED on Reddit, half the replies assume they actually have a different error and recommend fixes for the wrong problem. The codes that get confused most often are a small family, and each one points to a different layer of the stack.
The “no network at all” code is net::err_internet_disconnected. That one fires when your machine genuinely cannot reach anything, including the local router. If you have any other working tab or app, you do not have that error.
A timeout is ERR_CONNECTION_TIMED_OUT. The request was sent, the network tried to deliver it, and silence came back. Different cause, different fix. Servers-not-responding is its own debugging tree, and the article you want for that error is not this one.
A refused connection shows as ERR_CONNECTION_REFUSED. The server actively said no, which usually means the destination is up but the specific port or service is not.
ERR_SSL_PROTOCOL_ERROR is the one that throws people off most. It looks like a tunnel problem but is actually a certificate problem. The HTTPS handshake failed because the certificate is invalid, expired, or self-signed. The fix lives in the certificate path, not the proxy or DNS path.
DNS_PROBE_FINISHED_NXDOMAIN is what shows up when the domain itself does not exist. Your resolver is working, the request reached it, and the resolver came back with “no such name.” That is a typo or a dead-link problem, not a tunnel problem.
If your error matches one of those, the article you want is different. Read the full error string before searching, because the wrong search will lead you to a fix that does not apply to your case.
Trade-offs
Every fix has a cost. Flushing DNS clears a cache you may have wanted to keep warm, which means the next lookup for popular domains takes a beat longer. Switching to a public DNS resolver routes every domain your machine resolves through a third party, which has privacy implications you should think about, even when the provider publishes a privacy commitment. Disabling your VPN leaves your traffic unprotected for as long as you are off.
The other side of the trade-off is that the alternative is sitting with a browser that refuses half the pages you try to load. For most home users on a normal network, the proxy check and the DNS flush clear the issue without giving anything up. Once the deeper fixes come in, you are trading convenience for the ability to actually use the page, which is usually a fair exchange.
If you only do one thing from this article, check your proxy settings first. That is the cheapest, fastest, and most common fix, and it takes about ten seconds.