Checking the Proxy and the Firewall: Fix the Chrome Error

The line "checking the proxy and the firewall" is one of the suggestions Chrome prints under a "This site can't be reached" page, most often together with error codes like ERR_PROXY_CONNECTION_FAILED, ERR_TUNNEL_CONNECTION_FAILED, or ERR_TIMED_OUT, all listed in Chrome's connection-error help. Despite the phrasing, Chrome is not asking you to do anything yet; it is naming the two network layers most likely to have eaten your request.

The meaning is specific when a proxy is involved: your browser was told to send web traffic through an intermediary server, and that hop failed. Either the proxy could not be reached, refused the connection, spoke the wrong protocol for what the browser asked of it, or timed out. Nothing about the destination site has been tested at that point, which is why a perfectly healthy site becomes unreachable behind a broken proxy hop. The loopback lab later in this guide reproduces each of those failures and shows the raw socket errors Chrome dresses up in friendlier words.

The message splits into two very different situations, with different fixes. Either you never knowingly configured a proxy and something set one for you, in which case the fix is removal, or you rely on a proxy deliberately, in which case the fix is finding which link in the chain broke. The next section tells you which situation you are in, in about a minute.

Chrome, Edge, and Opera do not keep their own proxy settings; per Chromium's network-settings notes, they use the operating system's, which is why the same error and the same fix apply to all Chromium browsers on a machine.

On Windows, open Settings, then Network & internet, then Proxy. Three things can be active there: automatic detection, a setup script (a PAC file URL), and a manual proxy with an address and port. Note what is on before changing anything. The command-line view of the system-wide WinHTTP proxy is also worth a look:

netsh winhttp show proxy

Current WinHTTP proxy settings:
    Direct access (no proxy server).

On macOS, check System Settings under Wi-Fi or Ethernet, Details, Proxies, or list the same from a terminal with networksetup -getwebproxy "Wi-Fi" and networksetup -getsecurewebproxy "Wi-Fi".

Interpret what you find against what you expect. Everything off and the error still appearing means the proxy half of the message is a red herring for you; skip to the firewall section. A manual proxy or setup script you do not recognize is the trail to follow in the next section. A proxy you configured on purpose, for work or for a data workflow, sends you to the section after it.

Unexpected proxy settings come from a short list of sources, ordered here by how often they turn out to be the answer. First, leftovers: VPN clients, privacy suites, and some antivirus products set a system proxy while active and occasionally fail to clean it up after uninstall or a crashed session, leaving the browser pointed at a proxy that no longer exists. Second, a stale setup script: a PAC URL from an old network or tool that no longer resolves, which stalls every connection while the browser tries to fetch instructions. Third, adware or malware that quietly set a proxy to inspect or redirect your traffic. Fourth, a work-managed machine that expects a corporate network it currently cannot reach; on those, the setting is policy-managed, and the fix belongs to your IT team rather than this page.

For the first three, the repair is the same: in the proxy settings you just inspected, turn off the manual proxy and the setup script, then clear the WinHTTP layer for good measure:

netsh winhttp reset proxy

Restart the browser and retry the page.

Then do one more thing: check the settings again after the next reboot. A proxy that keeps coming back after you disable it is the classic sign that software on the machine is reasserting it, and if no legitimate tool of yours explains it, that is the point to run a full malware scan and review recently installed programs and browser extensions.

When the proxy is intentional, work outward from the server. Start by testing the proxy itself rather than restarting the browser again: the proxy checker verifies an endpoint is alive, reachable, and answering, which separates "my proxy is down" from "my machine is misconfigured" in one step.

If the endpoint is alive, the usual culprits are, in order: a wrong port, a scheme mismatch, authentication, and a firewall in the path. Port and scheme travel together, because sending HTTP proxy requests to a SOCKS port or vice versa fails in ways that look like the server is broken; the proxy-port guide covers which ports carry which protocols, and the HTTP versus SOCKS5 guide explains the two protocol families the settings dialog is asking you to choose between. Authentication failures announce themselves with status 407 responses when you test outside the browser. Egress firewalls matter on locked-down networks: common proxy ports such as 8080, 3128, or 1080 are sometimes blocked outbound on purpose, and the section below covers how to see that.

Two habits prevent most of these dead ends. Generate client configuration instead of typing it: the proxy config generator emits the exact strings for browsers, curl, and language clients, which eliminates scheme and port typos. And when a managed proxy service is the intended path, confirm the credentials and endpoint against the provider's dashboard rather than memory; rotated passwords and retired gateways produce exactly this error page.

Every cause named above reduces to a handful of socket-level outcomes, and all of them reproduce on loopback with no risk to anything. The recorded lab behind this article starts a tiny origin server and a minimal forward proxy, then performs four checks. A request configured to use a proxy port where nothing listens fails instantly with connection refused, which is the raw event behind ERR_PROXY_CONNECTION_FAILED. The same request through the live proxy relays cleanly and returns the origin's page. A CONNECT tunnel request, the method browsers use for HTTPS through a proxy as defined in the HTTP CONNECT specification, is answered with 501 by this deliberately HTTP-only proxy, reproducing the wrong-proxy-type failure. And a direct request to the origin succeeds throughout, proving the destination was healthy while the proxy path failed.

You can run the same experiment against any proxy with curl's -x option, which reports the underlying error Chrome summarizes:

curl -x http://127.0.0.1:8099 http://example.test/
curl: (7) Failed to connect to 127.0.0.1 port 8099: Connection refused

curl -x http://127.0.0.1:8098 http://127.0.0.1:8097/page
origin ok: /page

Connection refused points at a dead or wrong proxy address. A hang until timeout suggests a firewall silently dropping packets. An immediate protocol-level error suggests the scheme mismatch from the previous section. That one-line diagnosis is usually the whole investigation.

The firewall named by the error is any layer that can silently drop or intercept your connection: the operating system's own firewall, a third-party security suite, or filtering on the network between you and the destination.

Windows Defender Firewall is rarely the cause for browsers; its default outbound policy allows web traffic, so suspect it mainly if someone hardened the machine with custom outbound rules. Third-party antivirus deserves a closer look for a different reason: many implement web protection by running a local filtering proxy on the machine and routing browsers through it. A proxy entry pointing at 127.0.0.1 on a high port usually is that feature rather than malware. If the security suite crashed or half-uninstalled, its local proxy stops listening and every page load fails with exactly this error; briefly disabling the web-protection module, or reinstalling the suite cleanly, isolates the fault fast. Re-enable protection when the test is done.

Managed networks are the remaining case. Offices, schools, and some public Wi-Fi block outbound ports or force traffic through their own gateway by policy. The symptom is that direct browsing works while your configured proxy times out, or the reverse. On a network you do not administer, that filtering is policy, and the correct paths are the network administrator or a network you control, such as a phone hotspot, for confirming where the fault lives. Filtering decisions on managed networks are theirs to make; this guide diagnoses, it does not route around policy.

When the sections above have not produced the answer, five comparisons corner it. Test in Firefox: it keeps its own proxy settings independent of the system, so if Firefox loads the page while Chrome fails, the system proxy configuration is guilty. Test another site: one unreachable site with others fine points at the destination or its infrastructure, not your proxy. Test another network, such as a phone hotspot: if everything works there, the original network's filtering or its assigned proxy is the variable. Test by error code: ERR_NAME_NOT_RESOLVED is a DNS problem wearing similar clothes, and the proxy suggestion under it is usually noise. And test with curl using the exact proxy string from your settings, because its one-line errors beat the browser's summary page every time.

One outcome deserves a plain statement: sometimes the answer is that the destination refuses your network's address. That presents as one site failing from your network while working elsewhere, with your proxy blameless. What to do about it depends on your relationship with the site, and the honest options are the site's support, your network operator, or accepting the refusal; a block is the operator's decision about their own service. For the fundamentals behind everything this page touched, the proxy fundamentals guide walks the whole request path from client to destination, hop by hop.