What does ERR_TUNNEL_CONNECTION_FAILED mean in Chrome and Edge?

ERR_TUNNEL_CONNECTION_FAILED means Chrome reached the proxy and asked it to open a tunnel with CONNECT host:443, and the proxy answered with something other than 200. The proxy refused, failed to reach the site, or answered in a way Chrome will not accept, and Chrome threw that answer away rather than show it. So the error is not about your cache, your cookies or the site. It is a status code the proxy sent, and finding it is the whole diagnosis. Chromium's error list defines it as "A tunnel connection through the proxy could not be established", code -111, and it only appears for requests Chrome tunnels with CONNECT, which for ordinary pages means https:// URLs.

The other proxy errors fail at different points in the same sequence. ERR_PROXY_CONNECTION_FAILED means Chrome never got a working connection to the proxy at all. ERR_PROXY_CERTIFICATE_INVALID means it got one, but the proxy's own TLS certificate failed verification. ERR_PROXY_AUTH_UNSUPPORTED means the proxy asked for credentials in a scheme Chrome cannot use. ERR_MANDATORY_PROXY_CONFIGURATION_FAILED means Chrome never got as far as picking a proxy, because a PAC file it was told it must use could not be loaded. Microsoft Edge is built on Chromium and reports the same error names; the tests below ran Chromium, not Edge.

What the proxy answered, and what Chrome shows#

Every row was observed on 26 October 2026 against a real Squid, a real tinyproxy or a scripted proxy that sent exactly the bytes in the first column. The third column is where the real answer can be read, because Chrome's error page never contains it.

Read it from the bottom up. The lower rows never reached the CONNECT step: the problem is the proxy setting, the path to the proxy or the PAC file. The ERR_TUNNEL_CONNECTION_FAILED rows did reach it, so the browser is configured correctly and the answer belongs to whoever runs the proxy. A reset, a silent close or a stall is the proxy, or something in front of it, dropping the connection without saying why.

How it was tested#

The browser was Chromium 142.0.7444.59 from Alpine 3.22, run headless in a container with --proxy-server or --proxy-pac-url and a NetLog written with --log-net-log. The error code was read from the error page Chromium rendered, and the proxy's real answer from the NetLog's HTTP_TRANSACTION_READ_TUNNEL_RESPONSE_HEADERS event. The proxies were Squid 6.12 (default SSL_ports rule, a dstdomain deny, and a second port with Basic authentication), tinyproxy 1.11.2 with ConnectPort 443, and a small Python server that answered each CONNECT with one fixed reply, which is how the malformed and unusual replies were produced. The HTTPS proxy was a TLS front end with a self-signed certificate relaying to Squid; policies went in Chromium's managed policy file. Windows and macOS builds, and Edge itself, were not run.

Why Chrome will not show you the proxy's 403 page#

Squid sends a readable error page with its 403. For an http:// URL Chrome displays it: http://example.net/ through the test Squid showed Squid's "The requested URL could not be retrieved" page. For https://example.net/, the same 403 produced only ERR_TUNNEL_CONNECTION_FAILED.

That is deliberate, and Chromium's source says why. In HttpProxyClientSocket::DoProcessResponseCode, 200 opens the tunnel, 407 goes to the authentication code, and everything else falls to a default: branch that returns ERR_TUNNEL_CONNECTION_FAILED, with the comment that the response is ignored "to avoid letting the proxy impersonate the target server". If Chrome rendered the body, any proxy, or anyone posing as one, could put arbitrary content under an HTTPS site's address. The same comment admits the cost: "We have seen proxy 403, 404, and 501 response bodies that contain a useful error message." The explanation exists, and the browser drops it.

RFC 9110 gives Chrome the basis to be this strict. Its CONNECT section says "Any 2xx (Successful) response indicates that the sender (and all inbound proxies) will switch to tunnel mode immediately after the response header section", and "Any response other than a successful response indicates that the tunnel has not yet been formed." A redirect to a captive portal falls under the same rule. Chromium's error list notes that a former code, HTTPS_PROXY_TUNNEL_RESPONSE_REDIRECT, is obsolete "since we now use the catch-all ERR_TUNNEL_CONNECTION_FAILED when a proxy tried to redirect a request", and the 302 row above confirms it. The full exchange, and the status codes proxies send to CONNECT, are covered in HTTP CONNECT tunnelling.

Getting the status code the browser hid#

Three places show what the proxy actually sent.

curl through the same proxy. curl prints the status Chrome swallows. Against the test Squid, curl 8.14.1 reported:

$ curl -sS -o /dev/null -x http://proxy:3128 https://example.com:444/
curl: (56) CONNECT tunnel failed, response 403
$ curl -sS -o /dev/null -x http://proxy:3128 https://nosuchhost.invalid/
curl: (56) CONNECT tunnel failed, response 503

A reset gives Recv failure: Connection reset by peer and a silent close Proxy CONNECT aborted. Add -v to see the CONNECT response headers, including Squid's X-Squid-Error; the other flags are in curl through a proxy. curl must use the proxy Chrome resolved, which is not obvious when a PAC file is involved.

A NetLog from the browser. Open chrome://net-export, start logging, reproduce the error, stop, and load the file into the NetLog viewer at netlog-viewer.appspot.com. Search the events for the host name. The entries that matter:

HTTP_TRANSACTION_SEND_TUNNEL_HEADERS
  CONNECT example.com:443 HTTP/1.1
HTTP_TRANSACTION_READ_TUNNEL_RESPONSE_HEADERS
  HTTP/1.1 403 Forbidden
HTTP_PROXY_CONNECT_JOB_CONNECT
  net_error = -111 (ERR_TUNNEL_CONNECTION_FAILED)

If READ_TUNNEL_RESPONSE_HEADERS is present, the proxy answered and the status line is right there. If it is absent and the job ended with -101, -324 or -7, the proxy reset, closed or never replied. PROXY_RESOLUTION_SERVICE_RESOLVED_PROXY_LIST shows which proxy (or DIRECT) the request used, which settles the PAC question.

The proxy's access log. Squid writes one line per CONNECT with the status: TCP_DENIED/403 CONNECT example.com:444 for an ACL, TCP_DENIED/407 for missing credentials, and, confusingly, TCP_TUNNEL/503 CONNECT nosuchhost.invalid:443 for a tunnel that never opened. If the access log has no line at all for the client at the time of the error, the request never reached that proxy, and the cause is in the bottom rows of the table.

403 vs 502 vs 503: what each means at the proxy#

Once you have the status, remember that the origin server has not been contacted: the status is entirely the proxy's opinion.

The 403 for a non-443 port is the one developers hit most: https://app.internal:8443/ through a stock Squid fails while https://app.internal/ works. RFC 9110 says proxies "SHOULD restrict its use to a limited set of known ports", and Squid's default does exactly that.

The 407 cases: a prompt, or ERR_PROXY_AUTH_UNSUPPORTED#

A 407 is the only non-200 answer Chrome acts on. What it does next depends on whether it can use any scheme the proxy offered in Proxy-Authenticate.

If it can, as with Basic or NTLM, Chrome asks for credentials. Headless Chromium has no prompt, and the main page then failed with ERR_TUNNEL_CONNECTION_FAILED, which is the path Chromium's source describes for a dismissed prompt: HttpNetworkTransaction returns ERR_TUNNEL_CONNECTION_FAILED when a 407 tunnel response is read after "the user cancels a 407 proxy auth prompt". So ERR_TUNNEL_CONNECTION_FAILED on a proxy that needs authentication can simply mean someone pressed Cancel.

If it cannot, HttpAuthController returns ERR_PROXY_AUTH_UNSUPPORTED (-115) while the tunnel is being established, and no prompt appears. The test produced it four ways:

On managed machines, check the policy case first: a proxy offering only NTLM or only Negotiate fails every HTTPS site wherever AuthSchemes leaves that scheme out. chrome://policy shows the effective value. How the schemes differ, and why connection-bound NTLM is fragile through intermediaries, is in proxy authentication. For command-line tools behind the same proxy, the usual fix is a local helper, compared in Cntlm or Px.

ERR_PROXY_CONNECTION_FAILED: the proxy never answered CONNECT#

Chromium defines ERR_PROXY_CONNECTION_FAILED (-130) as "An error occurred either in resolving its name, or in connecting a socket to it", and adds: "this does NOT include failures during the actual 'CONNECT' method of an HTTP proxy." In HttpProxyConnectJob, any failure of the transport connection to the first proxy becomes this code unless it is a certificate error or a request for a client certificate. Three causes produced it in the test:

• The proxy port was closed (--proxy-server=http://127.0.0.1:9099 with nothing listening).
• The proxy's host name did not resolve (proxy.invalid).
• The proxy was configured as https:// but listened in plain HTTP. Chromium opened TLS, Squid answered the ClientHello with an HTTP 400 and logged NONE_NONE/400 error:invalid-request, and the TLS failure was reported as ERR_PROXY_CONNECTION_FAILED. The same mistake in environment variables is covered in should HTTPS_PROXY start with http:// or https://?.

The reverse mistake, http:// pointed at a port that expects TLS, gave ERR_CONNECTION_RESET with the test's TLS front end, which dropped the connection when the plain CONNECT failed its handshake. Another TLS proxy may fail differently.

Because Chrome never exchanged a byte of HTTP with the proxy, there is nothing in the proxy's log. Check the configured proxy first: on Windows, Chrome and Edge use the per-user system settings, not netsh winhttp, which is laid out in netsh winhttp vs Windows proxy settings.

ERR_PROXY_CERTIFICATE_INVALID: an HTTPS proxy with a bad certificate#

With an https:// proxy (or a PAC entry of the form HTTPS host:port), Chrome opens TLS to the proxy first. If that handshake fails with any certificate error, HttpProxyConnectJob maps it to ERR_PROXY_CERTIFICATE_INVALID (-136): "The certificate presented by the HTTPS Proxy was invalid". The test's self-signed proxy certificate produced it. There is no "proceed anyway" link as there is for a site's certificate, and the source carries a TODO to "allow the user to deal with proxy cert errors in the same way as server cert errors". The fix is to install the proxy's CA where Chrome trusts certificates, or to fix the name: the certificate must match the proxy host name Chrome was given.

This is not the certificate a TLS-intercepting proxy forges for each site; that case is covered in TLS interception and corporate root CAs.

ERR_MANDATORY_PROXY_CONFIGURATION_FAILED: the PAC file was required#

Chromium defines ERR_MANDATORY_PROXY_CONFIGURATION_FAILED (-131) as "A mandatory proxy configuration could not be used. Currently this means that a mandatory PAC script could not be fetched, parsed or executed." The important word is mandatory. An ordinary PAC failure does not produce an error at all. In the test, a PAC URL that returned 404, a script with a syntax error and a script that threw an exception inside FindProxyForURL all made Chromium go DIRECT silently, with the problem visible only in the NetLog (PAC_FILE_DECIDER_FETCH_PAC_SCRIPT with ERR_HTTP_RESPONSE_CODE_FAILURE, or PAC_JAVASCRIPT_ERROR with the line number). Chromium's proxy documentation describes the same rule: unless the PAC is mandatory, "proxy resolution will silently fall back to DIRECT", and if it is, "fallback to DIRECT is not permitted".

A PAC becomes mandatory through the ProxySettings policy with ProxyPacMandatory: true (the policy's description: it "prevents the network stack from falling back to direct connections with invalid or unavailable PAC script"), or through an extension using Chrome's proxy API. With that policy set, both the 404 and the syntax error gave ERR_MANDATORY_PROXY_CONFIGURATION_FAILED for every page. On Windows with system settings, the documentation adds that a failed PAC fetch falls back to the manual proxy servers where the platform supports it.

So this error means the policy is doing its job and the PAC host is down or serving a broken file. Fetch the PAC URL from that machine; if it loads, run it through a PAC file tester. Chromium retries a failed fetch after 8 seconds, 32 seconds after that, 2 minutes after that and then every 4 hours, so a fixed file can take a while to be picked up unless the network or settings change. The rest of PAC behaviour is in PAC files and WPAD.

Why a second proxy in the PAC file does not help#

A PAC result such as PROXY proxy1:3128; PROXY proxy2:3128 looks like redundancy. It is redundancy only against some failures. CanFalloverToNextProxy in Chromium's proxy_fallback.cc lists the errors that try the next entry: ERR_PROXY_CONNECTION_FAILED, connection reset, refused, closed and timed out, ERR_PROXY_CERTIFICATE_INVALID, ERR_SSL_PROTOCOL_ERROR and a few others. ERR_TUNNEL_CONNECTION_FAILED is not among them, except for Chrome's own IP Protection proxies. The test confirmed both sides:

Chromium's documentation gives the history: before M67 a failed CONNECT did trigger fallback, which broke "deployments whose HTTP proxies intentionally failed certain https:// requests", because with DIRECT next in the list the refusing proxy was marked bad and the block was bypassed. The consequence for an administrator: a primary proxy that is up but answers 503 to everything breaks HTTPS for every browser using that PAC, however many backups it lists. Health-check proxies at the HTTP level, not just the TCP port. A proxy that does fail over is marked bad for 5 minutes and moved to the end of the list, so a recovered proxy is not used again straight away.

Errors that are not about your proxy#

Two more codes are worth knowing because they mislead.

Testing with localhost goes direct. Chromium's implicit bypass rules send localhost, *.localhost, 127.0.0.1/8, [::1] and link-local addresses direct even when a proxy is configured, since M72 for manual proxy settings. In the test, https://127.0.0.1/ gave ERR_CONNECTION_REFUSED and the proxy saw nothing. To push loopback through the proxy, add <-loopback> to the bypass list (--proxy-bypass-list="<-loopback>"). The same request to the container's own non-loopback address went through Squid and gave the expected ERR_TUNNEL_CONNECTION_FAILED from a 503.

ERR_PROXY_UNABLE_TO_CONNECT_TO_DESTINATION (-186) exists, and its comment in the error list contrasts it with ERR_TUNNEL_CONNECTION_FAILED: it marks a failure "outside the control of the proxy server", such as a destination that does not resolve, so that the proxy is not marked bad. It comes from a ProxyDelegate, a hook that sees the tunnel response before Chromium's own status handling, which only ever returns ERR_TUNNEL_CONNECTION_FAILED for a refused CONNECT. With ordinary proxy settings, Squid failing to resolve the destination came back as ERR_TUNNEL_CONNECTION_FAILED. A -186 means a delegate, such as Chrome's IP Protection, was handling that proxy.

Where this answer stops applying#

The behaviour above is Chromium 142.0.7444.59 on Linux, run headless, with HTTP/1.1 proxies. Chrome and Edge on Windows and macOS were not tested; authentication libraries differ by platform, so the Linux Negotiate row in particular may not reproduce there. HTTP/2 and QUIC proxies, which Chrome can also use, establish tunnels on different code paths and were not tested. The tunnel timeout of about 30 seconds is the desktop constant in http_proxy_connect_job.cc; on Android and iOS the source sets 10 seconds, and it is in addition to the TCP connect timeout. Other proxies pick their own status codes, so the status rows will vary while Chrome's mapping stays the same: anything but 200 or a usable 407 is ERR_TUNNEL_CONNECTION_FAILED. When you have the status but not the cause, work along the chain one hop at a time using a proxy debugging playbook.

Frequently asked questions#

What does ERR_TUNNEL_CONNECTION_FAILED mean?#

Chrome connected to the configured proxy and sent CONNECT host:443 to open a tunnel for an HTTPS page, and the proxy answered with something other than 200: usually 403 (blocked by policy or port), 502 or 503 (the proxy could not reach the site), or a 407 that was not satisfied. Chrome hides the proxy's answer for security, so read it in the proxy's log, with curl, or in a chrome://net-export NetLog.

What is the difference between ERR_TUNNEL_CONNECTION_FAILED and ERR_PROXY_CONNECTION_FAILED?#

ERR_PROXY_CONNECTION_FAILED means Chrome could not connect to the proxy at all: its name did not resolve, its port was closed, or TLS to it failed. ERR_TUNNEL_CONNECTION_FAILED means the connection to the proxy worked and the proxy refused or failed the CONNECT request. The first is a client or network configuration problem; the second is a decision made at the proxy.

Does clearing the cache or cookies fix ERR_TUNNEL_CONNECTION_FAILED?#

No. The error happens during tunnel setup, before any request reaches the website, and the cache takes no part in it. Turning the proxy off may make the page load, but that only proves the proxy was refusing it.

Why do I get ERR_PROXY_AUTH_UNSUPPORTED?#

The proxy answered 407 but offered no authentication scheme Chrome can use. In testing that was an unknown scheme, a 407 without any Proxy-Authenticate header, Negotiate on Linux without a Kerberos library, and NTLM removed by the AuthSchemes policy. Check the Proxy-Authenticate header with curl -v and the effective AuthSchemes value in chrome://policy.

What causes ERR_MANDATORY_PROXY_CONFIGURATION_FAILED?#

A PAC file that policy marks as mandatory (ProxySettings with ProxyPacMandatory, or an extension) could not be fetched, parsed or run, so Chrome refuses to go direct. Without the mandatory flag, the same broken PAC file makes Chrome go direct silently instead. Check that the PAC URL loads from the affected machine and that the script has no syntax errors.