ERR_
Diagnose ERR_TUNNEL_CONNECTION_FAILED by reading the proxy CONNECT response. Separate authentication, tunnel rejection and destination TLS failures.
ERR_TUNNEL_CONNECTION_FAILED means Chromium could not establish a tunnel through the proxy. For an HTTPS URL through an HTTP proxy, inspect the CONNECT response before changing browser settings. A 407 response points to proxy authentication; other rejections need the proxy's response and the destination details to diagnose.
Find where the request stops
An HTTPS request through an HTTP proxy usually starts with CONNECT. The client asks the proxy to open a tunnel to a destination such as shop.example:443. After the proxy accepts it, the client starts TLS with the destination through that tunnel. The website's HTTP response arrives later.
Chromium defines ERR_TUNNEL_CONNECTION_FAILED separately from ERR_PROXY_CONNECTION_FAILED, which covers resolving or connecting to the proxy itself. The browser error does not identify which account setting, destination restriction or upstream connection caused the tunnel failure. The next useful evidence is the CONNECT response.
References: Chromium: network error definitions; HTTP Semantics: CONNECT
Read the tunnel status without exposing credentials
Use the same issued proxy host, port and authentication details as the browser. Follow the private curl configuration instructions in the 407 guide, then use that file below. The example path is ~/.config/proxy-check.curl. Replace the target URL with a small HTTPS page you control or are authorized to check.
The proxy entry must use the protocol supported by that endpoint. A destination URL beginning with https:// does not, by itself, require an https:// proxy entry. If the HTTP proxy uses Basic authentication, destination HTTPS does not encrypt the credentials sent on the client-to-proxy hop. Use a supported TLS-protected proxy endpoint when that hop needs encryption.
curl -q --config "$HOME/.config/proxy-check.curl" \
--noproxy "" --connect-timeout 10 --max-time 20 \
--silent --show-error --output /dev/null \
--write-out 'connect=%{http_connect} response=%{response_code}\n' \
'https://your-test-host.example/'
printf 'curl_exit=%s\n' "$?"The empty --noproxy value prevents an inherited bypass rule from skipping the proxy during this check. The command does not print the configuration file or request headers. Keep any subsequent verbose trace private because it can contain authentication data.
References: curl: configuration, --noproxy and --write-out; HTTPX: proxy schemes and tunnelling; Chromium: HTTP proxy transport and authentication
Use the response to choose the next check
A successful HTTP page does not test the same path as an HTTPS page. The proxy may forward ordinary HTTP successfully and reject CONNECT. Keep the destination, client and authentication constant while changing one variable so the comparison remains useful.
| Observation | What to check next |
|---|---|
| connect=407 | Follow the authentication guide. Confirm that the credentials belong to this endpoint and that the account's authentication method matches the client. |
| connect=403 | Ask the provider about restrictions on the destination or port. Keep the timestamp and destination hostname; the status alone does not identify the rule. |
| connect=502 or connect=503 | Compare a second permitted HTTPS destination with the same endpoint. Give the provider both results so it can distinguish a destination-specific failure from a wider service problem. |
| connect=200, followed by a certificate or TLS error | The proxy accepted CONNECT. Investigate the later TLS failure, including the target hostname and certificate trust, before rotating credentials. |
| connect=000 | curl did not record a CONNECT response. Read its error and exit status; check proxy resolution, reachability and whether the test used the intended protocol. |
References: HTTP Semantics: CONNECT responses and proxy authentication
Reproduce the failure without a paid proxy
Our downloadable fixture uses only 127.0.0.1 and never forwards traffic. With curl 8.7.1 on macOS, a controlled CONNECT 407 produced connect=407, response=000 and exit code 56. A controlled CONNECT 502 produced connect=502, response=000 and the same exit code. The exit code alone therefore did not distinguish these two failures.
A closed local proxy port produced connect=000, response=000 and exit code 7. The authentication control accepted disposable fixture credentials and then deliberately returned 502. These observations test client diagnostics; they do not measure a provider's availability or demonstrate a successful TLS tunnel.
python3 proxy-diagnostics-lab.py --output proxy-lab-results.jsonRequires Python 3.9+ and curl. The script also contains optional Requests timeout checks, which skip when Requests is unavailable. It does not change system proxy settings or use production credentials.
Send a report the provider can act on
Include the UTC timestamp, proxy protocol and endpoint, destination hostname and port, CONNECT status, curl error and the comparison with your second destination. Redact passwords, tokens and customer data. State whether the same endpoint previously worked and when that changed. A screenshot of the browser error alone leaves the provider without the response needed to trace the failure.
Download the support report template