ERR_TUNNEL_CONNECTION_FAILED: Causes and How to Fix It

Chrome, Edge, Opera, Brave, and Chrome on Android all show ERR_TUNNEL_CONNECTION_FAILED for one event: your browser asked a proxy to open a tunnel, and the proxy did not open one. Every useful fix follows from knowing what that tunnel is.

Plain HTTP can be relayed by reading it: the proxy receives your request and forwards it. HTTPS cannot work that way, because the point of TLS is that nothing in the middle can read the exchange. So the client asks for something else first. It sends the CONNECT method, defined in RFC 9110 section 9.3.6 and documented in MDN's CONNECT reference, naming a host and a port:

CONNECT example.com:443 HTTP/1.1
Host: example.com:443

HTTP/1.1 200 Connection Established

That is not a request for a page. It is a request for a pipe. A willing and able proxy opens its own TCP connection to that host and port, answers 200 Connection Established, and stops speaking HTTP. RFC 9110 describes what it becomes: a tunnel "acts as a blind relay between two connections without changing the messages."

Only then does your browser run its TLS handshake, with the destination, through the pipe. The certificate it validates belongs to the destination and the keys are known to those two ends alone, which is why a correctly behaving proxy carries ciphertext it cannot read. Hold on to that property: the most common cause of this error is software that breaks it on purpose.

The error name is scoped to that setup step and nothing else. Chromium's network error list records it as -111, "a tunnel connection through the proxy could not be established." Nothing had reached the website yet, so the site being down, DNS, and the destination's certificate are ruled out before you start. Two questions remain: is a configured proxy server supposed to be in the path at all, and what did it answer?

A CONNECT request has four possible outcomes, and which one you got decides what to fix. The lab behind this guide builds three proxies and one dead port on loopback and records all four on Node v24.14.0, verified 2026-07-29:

node scripts/verify-tunnel-failure-lab.mjs

PASS  CONNECT to an HTTP-only proxy → 501 (wrong proxy type for HTTPS)  (status=501)
PASS  CONNECT to a policy-restricted proxy → 403 (tunnel denied by rule)  (status=403)
PASS  CONNECT to a tunnel-capable proxy → 200 Established, bytes relay end to end  (status=200)
PASS  CONNECT to a dead proxy port → ECONNREFUSED (the PROXY_CONNECTION_FAILED sibling)  (error=ECONNREFUSED)

checks passed: 4/4

The proxy that relays plain HTTP but implements no tunneling answered 501: the endpoint is alive, it simply does not tunnel, the signature of a wrong proxy type or port. The one that forbids tunneling by rule answered 403: nothing there is broken, a policy matched the request and refused it. The tunnel-capable proxy answered 200, and a request written into that socket came back carrying the origin's body, origin through tunnel, untouched.

The fourth line costs people hours. With nothing listening at the proxy address there is no HTTP conversation at all: TCP is refused before a CONNECT can be sent, and Chromium reports that as ERR_PROXY_CONNECTION_FAILED, error -130, whose source comment explicitly excludes failures during the actual CONNECT method. One sentence keeps the pair apart. ERR_PROXY_CONNECTION_FAILED means you never reached the proxy; ERR_TUNNEL_CONNECTION_FAILED means you reached it and it would not open the pipe.

On one computer, on ordinary sites, on a network you control, the cause is almost always software you installed.

First and most often, security software that inspects encrypted connections. A module sold as HTTPS scanning, encrypted connections scanning, or web shield cannot work through a tunnel, because the tunnel exists to make that traffic unreadable. So these products break the property on purpose: they intercept the connection locally, terminate TLS with a root certificate they installed on your machine, read the plaintext, and re-originate the request onward. That machinery fails predictably: the product is older than your browser, its local root is expired, a filtering driver is wedged after an update, or two products are inspecting the same connection at once. When any of that breaks, tunnel setup dies with it.

Fix it in this order. Identify the product: a security suite, an endpoint agent, or a parental filter. Turn off its encrypted-connections scanning only, not the whole product, and reload once; that is a diagnostic, not a fix. If the page loads, update the product first, because a stale scanner against a current browser is the most common pairing of all. If that does not settle it, add the browser executable to the product's own exclusion list, then switch scanning back on. Leaving inspection off permanently trades one working page for a real loss of protection.

Second, two intermediaries competing for the same connection. A VPN client, a browser VPN extension, and a system proxy each want to own your traffic, and privacy clients often install a local proxy that survives the client disconnecting. Disconnect everything, reload, then reintroduce one component at a time; the proxy versus VPN comparison covers why the two do not layer cleanly. Opera has its own variant: the built-in browser VPN and a third-party scanner both want that connection, and Opera's setting for scanning encrypted connections decides which one gets it.

Third, a proxy nobody configured on purpose.

Plenty of software writes an operating-system proxy entry and never cleans it up: VPN clients, ad filters, tuning utilities, local intercepting proxies, old work configurations. Uninstall it, or let it crash, and the setting outlives it. Your browser then dutifully asks a dead intermediary for a tunnel on every HTTPS page. The signature is unmistakable: every site fails, it fails instantly rather than after a wait, and it follows the browser rather than the network.

Inspect the setting instead of guessing. On Windows, open Settings, then Network and internet, then Proxy, and read both halves of that screen as Microsoft's proxy documentation describes them: Automatic proxy setup, covering Automatically detect settings and Use setup script, and Manual proxy setup, naming an address and a port. Turn off anything you did not deliberately configure, and note what was there first, because on a work device it may belong to your employer. A setup script that is unreachable, stale, or names a host that no longer exists aims every HTTPS request at a phantom.

On macOS the same choices live under System Settings, Network, your active service, Details, then Proxies, where CONNECT uses Secure web proxy (HTTPS). On Android the proxy is stored per saved Wi-Fi network rather than per device: open the saved network, modify it, expand the advanced options, and set Proxy to None. That explains most Android reports, where the error follows one Wi-Fi network while mobile data is fine.

Chromium browsers, meaning Chrome, Edge, Opera, and Brave, read the system configuration and keep no list of their own, which is why they fail together. Firefox keeps the choice in its own connection settings, so it makes a clean control: set Firefox to No proxy, reload, and you have separated a system proxy problem from everything else. On a managed device, open chrome://policy, where a proxy pushed by administrative policy appears, overrides the settings screen, and is not yours to change.

The browser tells you a tunnel failed. It does not tell you what the proxy said. curl does. Name the proxy with -x and add -p, which the curl manual defines as "establish a tunnel to the destination through a PROXY that uses the HTTP CONNECT method." These are the lab's proxies with curl 8.17.0, verbose output trimmed to the CONNECT exchange:

$ curl -v -p -x http://127.0.0.1:8112 http://127.0.0.1:8109/
> CONNECT 127.0.0.1:8109 HTTP/1.1
< HTTP/1.1 200 Connection Established
* CONNECT tunnel established, response 200
origin through tunnel

$ curl -v -p -x http://127.0.0.1:8111 http://127.0.0.1:8109/
< HTTP/1.1 403 Forbidden
curl: (56) CONNECT tunnel failed, response 403

$ curl -v -p -x http://127.0.0.1:8110 http://127.0.0.1:8109/
< HTTP/1.1 501 Not Implemented
curl: (56) CONNECT tunnel failed, response 501

$ curl -v -p -x http://127.0.0.1:8116 http://127.0.0.1:8109/
curl: (7) Failed to connect to 127.0.0.1 port 8109 via 127.0.0.1

Against a real proxy, substitute your host and port, use an https:// URL, and drop -p: curl tunnels automatically for HTTPS. Exit code 56 means you reached a proxy and it declined, and the status beside it maps onto the table above. Exit code 7 means you never reached a proxy at all: the sibling error. The most informative result is the one that contradicts the browser: if curl tunnels cleanly while Chrome still fails through the same proxy, the proxy is innocent and something local is intercepting the browser.

When you configured the proxy yourself, three mistakes cover nearly all of it. Scheme: a SOCKS5 endpoint in an HTTP proxy field can never establish a CONNECT tunnel, because SOCKS negotiates in its own protocol and never sees an HTTP CONNECT line, and the HTTP versus SOCKS5 comparison covers which clients speak which. Credentials: a proxy wanting authentication answers 407, and clients that mishandle it surface a generic tunnel error. Host and port: a stale endpoint gives you the refused connection instead.

Get the endpoint right before rebuilding the client. A proxy grants access to nothing: it changes the route a request takes, and a destination that refuses you is not fixed by changing exits. Once the tunnel is up, a 403 or a block page is the site answering you, and the right response is to slow down or stop. For authorized work inside an approved budget, confirm an exit answers with the proxy checker and emit client settings with the proxy configuration generator, so what you write matches what the endpoint speaks.

On a corporate, campus, or guest network, the lab's 403 row is what you are looking at: a gateway perfectly capable of tunneling is choosing not to tunnel this one. That is configuration, not breakage, and the decision belongs to the operator.

The version nobody explains to a general audience is the destination port allowlist. Forward proxies and cloud secure web gateways commonly permit CONNECT only to a short list of destination ports, in practice 443 and sometimes 8443, because an unrestricted CONNECT is an unrestricted outbound tunnel. The symptom looks site-specific and is not: every ordinary site works, then one service on 8443, 9443, or a vendor-specific port fails for everyone at once. Compare a plain https://host/ request with the same host on the explicit odd port. If 443 works and the other does not, the cause is a rule about ports, not anything about that site, and proxy ports explained covers why intermediaries treat ports as a policy surface. Check this first whenever the failing address carries a port number.

Other gateway shapes produce the same browser string: a blocked destination or category, TLS inspection at organization scale, which is why personal devices and certificate-pinning apps fail where managed laptops work, and an expired proxy authentication session answered with 407.

Your move is diagnosis, then a request. Collect the facts that make a ticket answerable: the destination host and port, the CONNECT response code from the curl test above, whether other sites work, and whether that host answers on 443. That turns a vague report into a log lookup, because the gateway recorded your CONNECT and the rule that matched it. Then ask for a scoped exception with the business reason attached.

Do not try to route around the control. A refusal is a decision by the people who run the network, not a defect, and adding an intermediary of your own does not create authorization. If the destination is a service you run, publish it on 443 behind a hostname, the shape every allowlist is built around.