In short. The "tunnel" is the HTTP CONNECT request a browser sends to a forward proxy before it can carry HTTPS. This error means that request failed — the proxy was unreachable, refused it, or demanded credentials. Unlike most browser errors, this one really is on the client side, and checking your proxy settings really is the first thing to do.
Unusually, the standard advice for this error is correct
Most browser errors get consumer-grade advice that targets the wrong layer. This one is the exception, and it is worth saying so plainly: the widely published suggestion to disable your proxy or VPN is the right first step, because the error is generated by a proxy interaction and nothing else.
What that advice does not do is explain the mechanism, which is what you need when the obvious fix does not apply — when the proxy is deliberate and required, when there is no proxy configured at all, or when you own a site and your users are the ones seeing it. Those are the cases covered below.
What the tunnel actually is
A forward proxy can read and route plain HTTP. It cannot do that for HTTPS, because the traffic is encrypted end to end. So the client asks the proxy for a raw byte pipe instead:
CONNECT example.com:443 HTTP/1.1
Host: example.com:443
# The proxy replies 200 and then relays bytes blindly in both directions.
# TLS is negotiated through that pipe, between the browser and the site.Everything after the proxy's 200 is opaque to it. That is why the failure is so specific: it happens in the small window before the tunnel exists, and the proxy is the only party involved. Once the tunnel is established, any later problem produces a certificate or connection error instead.
Chrome distinguishes two nearby errors.
ERR_PROXY_CONNECTION_FAILEDmeans the proxy itself could not be reached.ERR_TUNNEL_CONNECTION_FAILEDmeans the proxy was reached and the CONNECT did not succeed. The second is more informative — something answered, and it said no.
Three commands that locate the cause
# 1. Is a proxy configured at all, and where does it point?
env | grep -i -E 'http_proxy|https_proxy|all_proxy' # shell environment
scutil --proxy # macOS system settings
netsh winhttp show proxy # Windows
# 2. Is that proxy reachable on its port?
nc -vz -w 5 proxy.example.com 3128
# 3. Does it accept a CONNECT for this destination?
curl -vsS -x http://proxy.example.com:3128 https://example.com/ -o /dev/null 2>&1 \
| grep -Ei 'connect|proxy|407|403|502'The third command is the decisive one. Its output distinguishes the four situations below, and each has a different owner.
| What the proxy returns | Meaning | Who fixes it |
|---|---|---|
| Nothing — connection refused or times out | Proxy is down or the address is stale | You, or whoever runs the proxy |
407 Proxy Authentication Required | Credentials missing or expired | You — re-authenticate |
403 Forbidden | Policy forbids this destination or port | Network administrator |
502 or similar | Proxy could not reach the destination | Destination or the proxy's own upstream |
Cause 1: a proxy is configured that no longer exists
By far the most common case, and it usually has nothing to do with a proxy you knowingly use. Software that routes traffic — a VPN client, a security suite, a debugging tool, an ad blocker with a local proxy — sets a system proxy while running and is supposed to clear it when it stops. When it crashes or is uninstalled untidily, the setting survives.
The browser then dutifully sends CONNECT to an address where nothing is listening, and every HTTPS site fails at once. The signature is unmistakable: all encrypted sites break simultaneously, immediately after installing or removing something.
Clear the setting at the system level rather than in the browser, because most browsers inherit from the operating system rather than holding their own.
Cause 2: an automatic configuration script that cannot be fetched
Many managed networks distribute proxy settings through a PAC file — a small script the machine downloads and evaluates to decide which proxy to use per destination. If that file is unreachable, malformed, or points at a decommissioned server, the result is the same failure with no visible proxy in the interface.
# Where is the script, and can it actually be fetched?
scutil --proxy | grep -i 'ProxyAutoConfigURLString'
curl -sS -o /dev/null -w 'pac fetch: %{http_code}\n' http://config.example.com/proxy.pacA non-200 here explains the error entirely. This is common on a laptop that has left the office network but kept a configuration profile that assumes an internal address is reachable.
Cause 3: the proxy allows CONNECT only to standard ports
This is the cause most guides omit, and the one that matters if you run a service rather than just browse. Proxies routinely restrict which destination ports CONNECT may target — commonly 443 alone, sometimes a short allowlist.
A site served on 443 works. The same site served on 8443, or an API on a custom port, is refused with 403 before any connection to it is attempted. The failure is invisible from outside the proxied network and perfectly reproducible inside it.
# Same host, two ports — refusal on one and success on the other is diagnostic
for p in 443 8443; do
printf 'port %-6s ' "$p"
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 8 \
-x http://proxy.example.com:3128 "https://example.com:$p/" || echo 'refused'
doneCause 4: authentication that expired quietly
Proxies that require credentials answer CONNECT with 407. Browsers usually prompt, but a cached credential that has since expired, or a machine account whose ticket lapsed, can produce a silent failure instead — particularly for background requests that have no user interface to prompt in.
The tell is that interactive browsing works after a prompt while applications and command-line tools continue to fail, because they never saw the prompt.
If you run a site and your users report this
Start from the fact that your server is almost certainly not involved. The CONNECT never reached it — the proxy refused before opening anything. There is, however, one configuration on your side that reliably causes this for corporate visitors, and it is worth checking before you tell them it is their problem.
- Non-standard ports. If you publish anything on a port other than 443 — an API, a dashboard, a websocket endpoint, a staging environment — expect it to be unreachable from managed networks whose proxies allow CONNECT only to 443. Publish behind 443 with a hostname or path instead.
- Direct-to-IP endpoints. Some proxies refuse CONNECT to bare addresses. Give every endpoint a hostname.
- Unusual TLS on a shared name. If a proxy is doing interception, an unusual configuration can cause it to give up at the tunnel stage rather than later.
The first point is worth taking seriously if you sell to businesses. An API that works everywhere except at your enterprise customers is frequently not a firewall problem in the sense people assume — it is a port their proxy will not tunnel to, and moving the endpoint to 443 removes the whole class.
Cause 5: something set a proxy without asking
Unwanted software sometimes routes traffic through a proxy it controls, either for injection or interception. The error appears when that proxy stops working or is partially removed.
Two signals separate this from an ordinary leftover: a proxy address you do not recognise, particularly a local one paired with software you did not install, and certificates issued by an unfamiliar authority on sites that otherwise validate normally. If both are present, treat the machine as compromised and clean it rather than only clearing the setting.
Ruling out the network in one step
Whatever the suspected cause, one comparison settles whether the proxy is involved at all:
# Bypass every proxy for a single request. If this succeeds while the browser
# fails, the proxy path is the problem and the site is fine.
curl -sS --noproxy '*' -o /dev/null -w 'direct: %{http_code}\n' https://example.com/A direct request that succeeds proves the destination is healthy and reachable. From there the investigation belongs entirely to the proxy configuration, and no amount of work on the site will change the outcome.
How to check right now
Use the port checker to confirm from outside your network that the port you publish on is actually open and reachable — the first thing to establish when enterprise users cannot connect but everyone else can. The header checker shows what your site returns to a client with no proxy in the path, which separates "the site is broken" from "the path to it is". The SSL checker confirms the certificate is valid on the port in question, since services on non-standard ports are the ones most often left with a stale one.
If your users are hitting this on a specific endpoint, scheduled monitoring from outside your network tells you whether the endpoint itself is healthy while their reports continue — which is the evidence that turns a support argument into a network conversation.
Frequently asked questions
I do not use a proxy. Why am I seeing this?
Something configured one. VPN clients, security suites and debugging tools set a system proxy while they run, and an untidy exit leaves the setting behind. Check the system proxy configuration rather than the browser's, because browsers usually inherit it.
Why do all HTTPS sites fail but plain HTTP works?
Because only HTTPS needs a tunnel. Plain HTTP is forwarded by the proxy directly, so it is unaffected by a CONNECT failure. That contrast is a strong confirmation that the proxy is where to look.
Is my site causing this for my users?
Almost never — the request did not reach it. The realistic exception is publishing on a non-standard port, which many corporate proxies refuse to tunnel to. Check what port the affected endpoint uses before concluding anything.
What is the difference from ERR_PROXY_CONNECTION_FAILED?
That one means the proxy could not be reached at all. This one means it was reached and the tunnel request did not succeed — so something answered and declined, which is more informative and points at policy or credentials rather than reachability.
It works in one browser but not another.
Browsers differ in whether they use the system proxy or their own, and in how they handle authentication prompts. A browser with its own setting can succeed while everything inheriting the system configuration fails.
Should I just disable the proxy permanently?
On a personal machine where the setting was left behind by uninstalled software, yes. On a managed network the proxy is usually mandatory and often the only permitted route out, so disabling it will simply stop traffic. There, the finding to report is which destination or port is being refused.
Checklist
- Check the system proxy configuration first — the browser usually inherits it.
- Note whether every HTTPS site fails or only one; the first means a local setting.
- Confirm the proxy address is reachable on its port.
- Read what the proxy returns to CONNECT — 407, 403 and 502 mean different owners.
- Verify any automatic configuration script can actually be fetched.
- Compare a standard port against a non-standard one for the same host.
- Run one direct request bypassing the proxy to clear the destination.
- Treat an unrecognised proxy plus an unfamiliar certificate authority as a compromised machine.
- If you publish a service, keep it on 443 for enterprise reachability.
- Prove the endpoint is healthy from outside before debating whose fault it is.
