ERR_TUNNEL_CONNECTION_FAILED is the more specific sibling of the error most people know. When Chrome cannot reach a configured proxy at all, it shows ERR_PROXY_CONNECTION_FAILED. This error means Chrome did reach the proxy, the proxy answered, and then the proxy could not do the one thing HTTPS requires of it: open a tunnel to the site. Chromium's network error list files it as error -111, "A tunnel connection through the proxy could not be established", and that sentence contains the whole diagnosis. The proxy is alive. The tunnel is what failed.
That difference points the investigation somewhere else. A proxy that does not answer is a dead proxy or a wrong address, and the fixes are about the address. A proxy that answers and refuses the tunnel is telling you something about its own rules, its own reach, or your credentials, and the fastest way to learn which is to ask it directly, which takes one command.
What a tunnel is, and why only HTTPS needs one
For a plain http:// page, the browser sends the whole request to the proxy, the proxy fetches the page, and hands it back. The proxy sees everything, and it can do everything. For an https:// page that model does not work, because the browser and the site have to negotiate an encrypted connection that no middle party can read. The browser instead sends the proxy a request that reads CONNECT example.com:443 HTTP/1.1, asking it to open a raw connection to that host and port and then relay bytes in both directions without looking at them. If the proxy answers 200 Connection established, the browser starts its TLS handshake through the tunnel and the page loads. Any other outcome, a 403, a 405, a 407, a 502, a 503, or a closed connection, and Chrome reports ERR_TUNNEL_CONNECTION_FAILED.
So the error is the proxy's answer to CONNECT, compressed into one code. The proxy had a reason, and it usually said so in a status line Chrome does not show you.
Chrome
connects to the proxy
Proxy
answers; tunnel refused = -111
Site, port 443
never reached
Ask the proxy why
Chrome hides the CONNECT response. curl shows it. On any system, with the proxy's address and port and any https:// site:
curl -v -x http://203.0.113.7:8080 https://example.com/ -o /dev/null
Read the lines after CONNECT example.com:443. The proxy's status line is the answer to your whole problem.
| What curl shows after CONNECT | What the proxy is saying | Fix |
|---|---|---|
HTTP/1.1 200 Connection established | The tunnel works in curl | The problem is Chrome-side: extension, credentials, or a second proxy layer |
HTTP/1.1 407 Proxy Authentication Required | It wants a username and password | Add credentials, or whitelist your IP with the provider |
HTTP/1.1 403 Forbidden or 405 Method Not Allowed | It refuses tunnels, or tunnels to that port | Use a proxy that supports HTTPS, or the port it allows |
HTTP/1.1 502 Bad Gateway or 503 Service Unavailable | It could not reach the site | Try another site; if all fail, the proxy's upstream is broken |
| Connection reset, or curl error 56 | It closed the connection without answering | Protocol mismatch, or a half-dead proxy |
| Nothing, then a timeout | Reached but never answered | Overloaded or dying proxy |
curl reports a non-200 CONNECT answer as its own error 56, phrased as "Received HTTP code 407 from proxy after CONNECT" (with whatever code applies), which is why the same failure looks different in a script and in a browser. Our guide to curl proxy errors covers the curl side in full.
The causes, and the fix for each
1. The proxy is HTTP-only and does not support CONNECT
With free proxies, this cause leads the list. A great many of the addresses on public lists are HTTP-only: they will fetch a plain http:// page and refuse the CONNECT request that every https:// site needs. Since almost the whole web is HTTPS now, such a proxy fails on nearly everything while a checker that only tests a plain HTTP page reports it alive. If HTTP sites load through the proxy and HTTPS sites fail, this is almost certainly your case.
What you need is a proxy that supports HTTPS tunnelling. Our proxy checker tests each address for HTTP, HTTPS, and SOCKS support separately, so you can see before you configure anything whether the proxy will carry HTTPS at all. The free proxy list shows the same per-protocol verification for every entry.
2. The proxy allows tunnels only to certain ports
Proxies commonly restrict CONNECT to port 443 to stop themselves being used as a general-purpose relay. Squid, the most widely deployed proxy software, ships with a rule that denies CONNECT to anything but its list of SSL ports. If you are tunnelling to a site on an unusual port, https://example.com:8443 for instance, and the proxy answers 403 to the CONNECT, this is why. Use port 443 where the site offers it, or a proxy without the restriction. SOCKS5 proxies have no such rule, because SOCKS tunnels any port by design.
3. The proxy wants credentials, and Chrome did not provide them
A 407 to the CONNECT means the proxy requires authentication. Chrome normally shows a login prompt for this, but when the proxy is set by an extension with stale credentials, or when the proxy is IP-authenticated and your address changed, the exchange fails and the tunnel error is what you see. Update the username and password in whatever configured the proxy, or add your current IP to the provider's whitelist. Everything about this case, including the special-character trap in passwords, is in our guide to 407 Proxy Authentication Required.
4. The proxy cannot reach the site
A 502 or 503 to the CONNECT means the proxy accepted the request and then failed to connect to the site from its side. Its DNS may be failing, its upstream network may be blocking the destination, or the site may be refusing connections from the proxy's IP at the TCP level. Test with two or three different sites. If only one fails, the site is unreachable from that proxy and a different exit is the answer. If everything fails, the proxy's outbound path is broken and the proxy is effectively dead even though it answers; replace it.
5. A filter is refusing tunnels to specific sites
The consumer version of the error, and the one that catches people who never configured a proxy. Antivirus web shields, parental controls, school and office filters, and some ad blockers work as a local or network proxy, and the way they block a site is to refuse the CONNECT to it. The signature is unmistakable: most sites load, a particular category of site fails with the tunnel error, and the proxy address in your settings is 127.0.0.1 or a private network address. The fix belongs in the filtering product's settings, or in a conversation with whoever runs the network. On your own machine, the filter's own uninstaller is the clean way out; just switching the proxy off leaves the product half-working.
6. A leftover proxy that still answers
A VPN client or filter that has been uninstalled badly sometimes leaves a process listening on its old port. The proxy answers, so Chrome gets past the connection step, but nothing behind it works, so every tunnel fails. On Windows, netstat -ano | findstr :PORT (with the port from your proxy setting) shows the process ID holding the port, and Task Manager's Details tab names it. Remove the program properly, then clear the proxy in Settings and in Internet Options as described in how to turn off a proxy.
7. A protocol mismatch
Point Chrome's HTTP proxy setting at a SOCKS server and the server receives a CONNECT line it does not understand. Some SOCKS implementations close the connection, which Chrome reports as this error; others never answer, which Chrome reports as the connection-failed error instead. If port 1080 appears in your proxy setting, the address is almost certainly SOCKS and belongs in a SOCKS field, which in Chrome means an extension or the system's dedicated SOCKS setting rather than the HTTP proxy box.
Chrome-side checks when curl says the tunnel works
If curl gets 200 Connection established through the same proxy and Chrome still fails, the difference is inside Chrome. Go to chrome://extensions, disable every proxy, VPN, and privacy extension, then reload; an extension can be routing Chrome through a second proxy that curl never sees. Check chrome://policy for a ProxyServer or ProxyPacUrl entry, which overrides both the system setting and any extension. And test in a fresh profile or a guest window, which starts with no extensions at all. If the guest window loads the page, the cause is an extension in your main profile.
If you never set a proxy
Most people who meet this error at home did not configure anything. Read the address on the proxy page (Settings, Network & internet, Proxy on Windows; System Settings, Network, Details, Proxies on a Mac) before switching it off. A 127.0.0.1 address is a program on your computer, usually a VPN, an ad blocker, or a security product, and its own settings or uninstaller are where the fix lives. An unfamiliar address on a machine that has never had a paid proxy deserves a look in our IP lookup and, if the setting returns after you clear it, the full treatment in proxy settings that keep turning back on.
The one-minute isolation
- Run the curl command above against an
https://site. Read the status line after CONNECT. That single line assigns the cause to one of the seven sections. - If curl says 200 and Chrome fails, the problem is a Chrome extension, policy, or profile.
- If curl says 407, add credentials or whitelist your IP.
- If curl says 403 or 405, use a proxy verified for HTTPS, or change the port.
- If curl says 502 or 503, try another site; if all fail, replace the proxy.
- When only certain sites fail and the proxy is local, a filter is doing its job and needs to be reconfigured or removed.
Reliable HTTPS tunnelling is the baseline for any real use of a proxy, not a luxury. Every address in our free proxy list carries a per-protocol result from the last check, and when the job needs a tunnel that holds for hours rather than minutes, an authenticated ISP proxy on a fixed address, or a residential session that holds its exit, is what removes this error from your life entirely.