Checking the Proxy and the Firewall: What Chrome Is Really Telling You

Checking the proxy and the firewall is not something Chrome did. It is a suggestion Chrome printed, and the sentence on your screen is a link whose only job is to open a box further down the same page.

That matters because most people reading it have no proxy at all, and Chrome never claimed they did. It prints that line for six specific error codes, regardless of what is configured on your machine, and then every guide on the internet treats it as a diagnosis.

So: where the sentence comes from, which errors produce it, what clicking it actually does, how to check a proxy and a firewall properly if you still want to, and the thing that tells you what really happened.

Author: Christopher Vance Web Infrastructure Specialist

I spend my time on both ends of a connection, and the thing that strikes me about this message is how little it knows. It is attached to the error code that came back, not to anything about your computer. Chrome has not looked at your proxy settings. It has not asked your firewall a question. It is offering a suggestion from a list.

Which is worth saying because on the code people arrive with most often, a plain refusal, the likeliest explanation is that the far end declined you and there is nothing on your side to fix.

What "Checking the Proxy and the Firewall" Actually Is

When you see checking the proxy and the firewall chrome has not run a test and reported a result. You are looking at one line of a bulleted list that begins with the word "Try:", sitting under a heading that says the site cannot be reached.

The sentence is defined in Chromium's own string file, components/error_page_strings.grdp, and reading the definition tells you everything. The message is wrapped in an anchor tag:

Its href is #buttons, a position on the page you are already on. Its onclick calls toggleHelpBox(). So the link scrolls you down and unfolds a panel. It contacts nothing, reads no setting, and returns no verdict. The word "checking" is an instruction to you, not a description of something Chrome did.

This is a browser error rather than a server response, which puts it in a different category from most things people call a proxy problem. If you are not sure which category you are in, our guide to the three layers a browser error can be coming from separates them, and this message belongs squarely in the first.

The Six Errors That Print It, and the One That Never Does

Chrome decides which suggestions to show from the error code, and nothing else. Each network error in components/error_page/common/localized_error.cc carries a set of suggestion flags, and this particular sentence appears when an error carries both the proxy flag and the firewall flag:

Note the else. Three branches run before this one: two DNS variants, which take over if the error carries a DNS or Secure DNS flag and give you the longer wording, and one for firewall-plus-antivirus. So the short version you are reading is what is left after those three have taken their cases.

Those six are the whole list. A code you will often see blamed for this message is ERR_NAME_NOT_RESOLVED, and it does not produce it: its flags include the DNS one, so it takes the earlier branch and gets the longer sentence. If a guide tells you this message means a name lookup failed, it has not read the table.

One caveat on that last column, and it is a large one. Chromium only builds the diagnostics dialog for Windows and ChromeOS. Every other platform compiles a stub whose answer is hard-coded to false, and the suggestion is then stripped before the page renders. So on macOS and Linux the last column is No for every row, whatever the flags say.

And on ERR_CONNECTION_REFUSED, the code people most often arrive with, Chrome offers the proxy and firewall line but not the diagnostics one even on Windows, because that flag is simply absent from its entry. For background on what sits between you and a site in the first place, our explainer on what an intermediary is allowed to do to your traffic covers the shape of it.

One Item in That List Does Run Something. This Is Not It.

On Windows, two suggestions sit next to each other in that list and only one of them can do anything. Both are defined in the same Chromium file.

The proxy and firewall line calls toggleHelpBox(), which flips a flag and redraws the panel. The diagnostics line is defined as <a href="javascript:diagnoseErrors()" id="diagnose-link">Running Windows Network Diagnostics</a>, and that one reaches something real: the page function hands off to the browser process, which on Windows calls into the Network Diagnostics Framework and runs it against the URL that failed.

One honest limit on that, and it says something useful: Chrome skips it in Incognito and guest profiles, because the Windows tool logs the URL it was run with. Add the platform gap the table above already noted, and the position is this. One suggestion in that list can do work, on some platforms, in some profiles. The other unfolds a panel everywhere.

So if you want something that genuinely inspects your connection, the answer is neither of those. It is Chrome's own network log. Chromium documents it for exactly this purpose: go to chrome://net-export/, press Start Logging To Disk, reproduce the failure in another tab, then press Stop Logging. What you get is, in Chromium's words, "a log file of the browser's network-level events and state."

That file contains the proxy Chrome resolved for the request, the connection attempts it made, and the point at which each one died.

One caveat worth reading before you share one. The default capture strips private information, and Chromium's own instructions are to attach it to a bug report. It is the optional Include raw bytes setting that changes the calculus: captures at that level, in Chromium's words, "may include personal information and should generally be emailed rather than posted on public forums or public bugs." So leave raw bytes off unless somebody has asked for them.

Read the Code, Not the Suggestion: Refused, Reset, or Timed Out

Refused means a machine was reachable and actively declined. Something answered. On the public internet that is usually the destination itself, or whatever sits in front of it, deciding it does not want this connection. A desktop firewall blocking an outbound request does not normally produce a refusal from the far end.

Reset means something sent an abrupt TCP reset. Of the three this is the one where equipment on the path actively intervened rather than merely staying silent, and "on the path" usually means the network's gear rather than software on your laptop.

Timed out means nothing came back. Silence is the least informative outcome of the three, and the widest range of causes fits it. It is also the outcome that a block which silently drops packets produces, since dropping leaves nothing to report. So both reset and timed out can be filtering; the difference is whether the filter answered or said nothing.

The two remaining codes sit either side of those three. Closed means the other end hung up without answering properly, which behaves like a reset for diagnostic purposes. And ERR_TLS13_DOWNGRADE_DETECTED is the one code here where suspecting a proxy is the correct first move rather than the lazy one, because Chromium says so itself. Its source comment notes the downgrade is part of a TLS 1.3 security check, but that it "may also indicate the user is behind a buggy TLS-terminating proxy which implemented TLS 1.2 incorrectly." On that code, and only that code, the suggestion on your screen is finally good advice.

If you are getting a refusal and only for certain sites, there is a possibility worth considering before you touch any settings: the site may be refusing your address in particular. We cover that pattern in the site deciding it does not want your address, and the tell is that the same page loads on a phone using mobile data.

The next two sections are for the case where those answers point inward, at your machine or your network. Section 7 is for the case where they point outward, which in practice is the commoner result.

How to Check Proxy and Firewall on Chrome: The Proxy Half

People search how to check proxy and firewall on chrome, or how to check proxy and firewall settings google chrome, as though Chrome held both. It holds neither. On Windows and macOS, Chrome reads the operating system's proxy configuration, so the thing you are checking is the system, not the browser.

And the phrase proxy and firewall settings chrome describes a screen that does not exist: Chrome has no page with a proxy on one side and a firewall on the other.

Which is why advice of the form "open Chrome's advanced settings" ages so badly. And the system setting is not the only thing Chrome obeys: a managed policy, an extension or a command-line flag can each override it, so checking one screen can mislead you. We took the whole ranking apart in the screen Chrome actually reads a proxy from.

A caution about that first command, because it is the one most guides reach for and most of them misread it. netsh winhttp reports the machine-level store. That is not the store Chrome reads, and an empty result there does not mean no proxy is configured for your browser. Windows keeps more than one, and we mapped which of the three Windows stores your app is really reading in its own guide. Run it anyway, because a stale entry there is exactly what breaks background updaters while browsing looks fine.

If you want an answer that does not depend on reading the right store, ask from outside instead. Our check that reports whether your traffic arrives through an intermediary sees what your connection actually presents, which settles in seconds what a screenshot of a settings page cannot.

Proxy and Firewall Settings: The Firewall Half, and Why It Is Rarely Guilty

Advice to check proxy and firewall chrome settings almost always treats the two as one blob, and one ranked page gives literally the same four clicks for both. They are separate systems with separate defaults, and the defaults are the reason to be skeptical.

Here is the fact that should change how you read this whole message. On Windows, macOS and Ubuntu, the firewall that came with the system does not block outgoing traffic. Microsoft documents the Windows default in the reference for the setting itself: the Allow value "allows all outbound network traffic, whether or not it matches an outbound rule", and "the default setting when managing a computer is Allow". Inbound, for contrast, defaults to Block.

On macOS there is no outbound policy to check at all: Apple describes its firewall as protecting a Mac "from unwanted contact initiated by other computers", and neither that page nor its platform security guide mentions outgoing connections anywhere. On Ubuntu the answer is stronger still, because the ufw manual says "on installation, ufw is disabled with a default incoming policy of deny, a default forward policy of deny, and a default outgoing policy of allow". Disabled. ufw status verbose prints Status: inactive, so the policy is not even in effect. Fedora and RHEL use firewalld, whose defaults I have not checked, so take this as covering those three systems and no others.

A browser fetching a page is outgoing traffic. So unless somebody added a blocking rule deliberately, your built-in firewall is the least likely explanation for this error, and it is the first thing nearly every guide tells you to disable.

There is a real exception, and it deserves to be checked first rather than last. Third-party outbound filters do the opposite of the built-ins by design: tools like Little Snitch or GlassWire, and the firewall components bundled into security suites, ask permission for each application's outgoing connections and deny until you answer. If one is installed, it is a genuine candidate, and it is exactly the sort of thing that blocks one destination while everything else keeps working.

Checking one is the same three steps whichever product it is. Open its rule list and look for an entry naming your browser, or the destination, with a deny action. Open its log or history and look for a blocked entry timed to the moment your page failed, which is the thing that actually proves it. Then, if you find one, allow that one rule rather than pausing the whole product, because pausing it teaches you nothing about which rule was responsible.

When you suspect the path rather than a setting, two probes from our side separate "the world cannot reach it" from "you cannot reach it": whether the host answers at all before HTTP is involved, and whether the port itself is reachable from outside your network.

One case where a proxy really is involved and the message is still not this one: if a proxy answers and demands credentials, you get a different error entirely, which we cover in when the proxy does answer, and demands a password. A proxy that talks to you is not a proxy you need to hunt for.

When Only One Site Fails, and Two Messages People Confuse With This One

The most common version of this problem in the wild is not what the guides are written for. One site fails, sometimes intermittently, while everything else loads normally. Every checklist that begins with restarting your router is written for a person who has no internet at all, and that person is not the one searching this phrase.

For the single-site case, the four questions above are the whole method, and the answer is usually on the other side. A host that refuses or resets one connection and serves everyone else is having its own problem, or has made a decision about you. Neither is fixed from your settings screen.

Intermittent is its own signal. A configuration error is not intermittent; it fails every time until you change it. Something that works, then does not, then does again points at load, rate limiting or a route, and the log from Section 3 tells you which.

Two other messages get conflated with this one. Windows has its own wording about failing to detect a network's proxy settings, which comes from the Windows troubleshooter rather than from Chrome. And "proxy firewall" is a category of enterprise appliance, which is what the two words return without Chrome in the query. If a name lookup is what failed, our guide to the DNS-shaped cousin of this message is the right page.

The Short Version

Here is the whole thing in one line before the detail. The message is a guess on five of the six codes that print it, it is right on the sixth, and the only suspect on your own machine worth real time is a third-party outbound filter, which no error code will name for you.

Checking the proxy and the firewall is a suggestion, not a finding. Chromium's own string file defines it as a link that calls toggleHelpBox(), so clicking it expands a panel and nothing else. It appears for six error codes, chosen by the code alone, with no reference to whether you have a proxy configured.

Read the ERR_ line underneath instead. Refused means something declined you, which is usually the far end. Reset means a connection was cut mid-flight. Timed out means silence. Those are three different problems. Filtering can produce a reset or a timeout, depending on whether it answers or stays silent, but a refusal usually comes from the far end. The rare TLS downgrade code is the one that genuinely points at interception.

Before changing anything, answer four questions: does another site work, does another browser fail, does another network work, and what does the network log say. Then remember that the firewall built into your operating system allows outgoing traffic by default, which makes it an unlikely culprit and a poor thing to disable on a hunch. A third-party outbound filter is the exception, and the one worth checking early.

And if you want to know how the far end sees you before you start, our homepage check reports the address your connection is arriving from and how it is classified. That is context rather than a diagnosis; the log in Section 3 is still the thing that tells you what failed.