How is this different from ERR_TUNNEL_CONNECTION_FAILED?

They fail at different hops. ERR_PROXY_CONNECTION_FAILED means Chrome couldn't reach the proxy at all — the address is dead, the port is wrong, the PAC file didn't load, so there's no proxy to talk to. ERR_TUNNEL_CONNECTION_FAILED means Chrome *did* reach the proxy and asked it, via an HTTP CONNECT, to open a tunnel to the destination — and the proxy refused or failed to complete that tunnel. One is 'I can't find my proxy'; the other is 'my proxy answered but wouldn't connect me onward.' The distinction tells you where to look: PROXY_CONNECTION_FAILED is about your proxy *configuration and reachability*, TUNNEL_CONNECTION_FAILED is about the proxy's own upstream connectivity or policy.

I never set up a proxy. Why is Chrome using one?

Because something set it for you and didn't clean up. The usual suspects: a VPN or 'privacy' browser extension that installed a proxy and left the setting behind after you disabled or removed it; antivirus or parental-control software that routes traffic through a local proxy; a corporate policy or a PAC/WPAD auto-configuration your network hands out; or malware. Chrome on Windows and macOS reads the operating system's proxy settings by default, so a proxy configured anywhere in the OS — or left over from software you uninstalled — becomes Chrome's proxy. If you don't intend to use one, the fix is to find and clear that setting, not to touch the website.

Every website fails, not just one. Does that narrow it down?

Hugely — and in your favor. A proxy sits in front of *all* your traffic, so when it's broken, every site returns the identical ERR_PROXY_CONNECTION_FAILED, regardless of whether the site itself is up. That uniformity is the fingerprint of a client-side proxy problem: real server outages don't fail every unrelated site in exactly the same way at exactly the same moment. If one specific site is down but everything else loads, this error is the wrong lead. If *everything* fails identically, stop checking sites and go straight to your proxy configuration.

Views: 40

ERR_PROXY_CONNECTION_FAILED

ERR_PROXY_CONNECTION_FAILED means Chrome can't reach your proxy, not the website. Isolate proxy from server in 3 checks. Free instant check, no sign-up.

Check your domain for this issue now

Free, no sign-up. Runs the exact check this guide describes and shows what to fix.

Problem

Chrome refuses to load anything and shows ERR_PROXY_CONNECTION_FAILED, often under the heading “Unable to connect to the proxy server.” Read that literally, because it’s precise: Chrome is not saying the website is down. It’s saying it was configured to reach the internet through a proxy, and it couldn’t reach the proxy. The request never made it past the first hop — your own machine’s idea of how to get online.

This is a client-side error wearing the costume of a website error. The site you were trying to open is very likely fine. The break is between Chrome and a proxy server it was told to use, and that proxy is either gone, wrong, or was never supposed to be there in the first place.

Symptoms

The exact code is ERR_PROXY_CONNECTION_FAILED, frequently with “Unable to connect to the proxy server.”
Every website fails the same way, not just one — the giveaway that the problem is in front of all your traffic.
Other browsers or apps that use the same OS proxy settings break too; ones configured to go direct still work.
It often starts right after installing or removing a VPN, a proxy extension, or a security product — or after joining a new network that pushes an auto-config.
An external HTTP check of the “broken” site from outside your machine returns a clean response, proving the site is up and the fault is local.

What ERR_PROXY_CONNECTION_FAILED Actually Means

A proxy is a middleman you route traffic through on purpose — a corporate gateway, a privacy tool, a content filter. When Chrome is configured to use one, it doesn’t connect to websites directly; it connects to the proxy and asks the proxy to fetch things on its behalf. ERR_PROXY_CONNECTION_FAILED is Chrome reporting that step one failed: it tried to open a connection to the proxy itself and couldn’t. Because that failure happens before any request to the actual website, the website’s health is irrelevant — Chrome never got far enough to ask about it.

There are a few distinct ways to end up here, and they share a root: Chrome thinks it should use a proxy that it can’t actually talk to. The proxy’s address or port is wrong or stale. The proxy service is down or unreachable from your network. Or the configuration is automatic — a PAC file specified by URL, or WPAD auto-discovery — and the script itself failed to load, so Chrome has a proxy instruction it can’t resolve. On Windows and macOS, Chrome inherits the operating system’s proxy settings by default, which is why a proxy nobody remembers configuring — left behind by uninstalled software, or pushed by a network you’ve since left — keeps intercepting your traffic.

The reframe that makes this easy: the number of failing sites tells you where the problem is. One site down, everything else fine? This isn’t your error; look at that site. Everything failing with the identical proxy message? The problem is the proxy layer between you and the whole internet, and no amount of reloading a website will move it.

Top Causes

A stale or wrong manual proxy setting - A host/port is configured in the OS or Chrome proxy settings, and it’s either mistyped, pointing at a proxy that’s now offline, or a leftover from a tool you removed. The most common case, and the easiest fix: clear it if you don’t need a proxy, correct it if you do.
A leftover proxy from a VPN, extension, or security app - Software installed a proxy to route your traffic and didn’t undo it when you disabled or uninstalled it. Chrome keeps honoring the abandoned setting. Disabling proxy-touching extensions and resetting the proxy config clears it.
A broken PAC file or WPAD auto-config - Chrome is set to auto-detect or use an automatic configuration script, and that script’s URL is unreachable or errors out. Every request then fails because Chrome can’t determine how to route it. Common on corporate networks with a misconfigured or off-network PAC URL.
The proxy server itself is down or unreachable - The configured proxy is correct but offline, blocked by a firewall, or on a network you can no longer reach (off VPN, changed subnet). Here the setting is right; the target is gone.

Diagnose with DechoNet

HTTP Check the site from our side, which does not go through your proxy. If our check returns a clean response while your Chrome shows ERR_PROXY_CONNECTION_FAILED, you’ve proven the split in one move: the website is up and reachable, and the failure lives entirely in your local proxy path. That result redirects the entire investigation — stop touching the site and go to your proxy settings, because an external success plus a local proxy error can only mean the proxy, not the server. If our check also fails, the site itself may genuinely be down, and the proxy error is a coincidence worth ruling out separately.

Resolution Checklist

Confirm the scope. If every site fails identically, it’s the proxy; if only one does, this error is a red herring and the site is the lead.
Run an external HTTP check to prove the site is actually up. A clean result from outside your machine means the fault is local proxy configuration, full stop.
Open your OS proxy settings. On Windows: Settings → Network & Internet → Proxy. On macOS: System Settings → Network → your connection → Proxies. If you don’t use a proxy, turn off both manual proxy and automatic configuration.
If you do use a proxy, verify the host, port, and — for automatic setups — that the PAC/WPAD URL actually loads. A stale or off-network URL fails every request.
Disable Chrome extensions that touch the network — VPNs, proxy switchers, privacy filters — and retest. Reinstate them one at a time to find the culprit.
As a last resort, reset Chrome’s settings (Settings → Reset settings), which clears any proxy overrides Chrome itself holds, then confirm the OS setting is clean too.

When to Escalate

On a managed or corporate machine, the proxy is usually set by policy, and you can’t — and shouldn’t — clear it yourself. If the PAC/WPAD config is failing, that’s an IT escalation: the auto-config URL or the proxy service needs fixing centrally, and the useful report is “every site returns ERR_PROXY_CONNECTION_FAILED and the PAC URL doesn’t load,” not “the internet is down.”
If the proxy is one you run, escalate to whoever owns it when the address is correct but the service is unreachable — that’s a proxy-availability or firewall problem on the proxy side, one hop past your browser.
If no proxy should exist and one keeps reappearing after you clear it, treat it as a possible unwanted-software or malware issue and escalate to endpoint security — something is re-writing your proxy settings, and clearing them by hand won’t hold.