Proxy Error Meaning: The Three Layers, and Who Can Actually Fix Each One

The proxy error meaning you are looking for depends on which of three different things you are actually looking at, and almost every guide on this subject blurs them together. A message from your browser, a status code from a server, and the question of which server sent it are not the same problem.

That third one decides everything. A 502 produced by your proxy and a 502 passed along from the website look identical on your screen. One you can fix in a minute. The other is somebody else's server, and no amount of changing proxies will touch it.

So this is a diagnostic rather than a dictionary. What the three layers are, how to tell in about two minutes who actually generated the error, what the codes that matter really mean with a source attached, and which of them are genuinely not yours to fix.

Author: Christopher Vance Web Infrastructure Specialist

I spend my time on both ends of this: the proxy side and the server side. From the server side, most of what people call a proxy error is the origin having a bad day and the proxy faithfully reporting it. From the proxy side, the interesting failures happen before any HTTP status exists at all. The first question is never what a code means. It is who sent it.

And one thing worth saying plainly, because we sell no proxies and can afford to: several of these cannot be fixed by you, and switching provider will not change them. Knowing which errors are yours saves money as well as an afternoon.

Proxy Error Meaning: Three Different Things With One Name

The question people actually type is what is proxy error, or what does proxy error mean, or just proxy server error, and the answer that comes back is a list of HTTP status codes. That answer is incomplete in a way that wastes people's time, because a large share of proxy failures never reach the point where a status code exists.

If your browser cannot reach the proxy at all, nothing has replied and there is no 502, no 407, no status of any kind. What you get is your browser's own error, generated locally. And there is a second case, which almost nobody writes about: a server did reply, with a number, and your browser decided not to show it to you. Both land on the same screen. Section 3 is where they separate, and that is a different category from anything the ranked guides cover.

The third row is the one with no indicator light, and it is the one that decides whether you have a five-minute job or no job at all. If the mechanics of what sits between you and a website are unfamiliar, our explanation of how a proxy server works and where it sits in a network covers the shape of it.

Before any of that, though, there is a question worth thirty seconds, because a surprising number of proxy errors turn out not to involve a proxy.

First: Is a Proxy Even in the Path?

People arrive at this question with a proxy configured somewhere and assume it is involved. Often it is not. The setting is on a screen nothing is reading, or it was cleared, or the failure is happening at a layer the proxy never touches.

There is a header for exactly this. MDN describes it in one line: "The Via request and response header is added by proxies, both forward and reverse", and it exists for "tracking message forwards", "avoiding request loops", and "identifying the protocol capabilities of senders along the request/response chain".

Read it in your browser's network tab: open developer tools, switch to the Network panel, reload the failing page, click the request, and look through the response headers for Via. If it is there, the message was forwarded by at least one intermediary. While you have that list open, look for a second header called Proxy-Status as well. It is rarer and it says far more, and Section 4 is where it earns its keep. One trip, two headers.

Two limits matter more than the test does. It needs a response to read, so if your browser never reached the proxy there are no headers to inspect at all. And a forward proxy handling HTTPS opens a tunnel and never touches the messages inside it, so it cannot add a header to them. On an HTTPS page, which is nearly all of them, a Via you can see almost certainly came from the destination's own CDN rather than from yours. Read it as evidence that an intermediary exists, never as an identification of which one.

That second test is the one nobody runs, and it resolves more of these than any setting change. Once you know a proxy is genuinely involved, the next question is which layer you are looking at.

The ERR_ Codes: What Chrome Is Actually Telling You

When you see err proxy connection failed on a Chrome error page, you are not looking at an HTTP status. You are looking at a Chromium network error, and Chromium publishes what every one of them means in its own source. This is the layer the guides on this topic leave out, and it is the layer most people are actually staring at.

These are read from Chromium's net_error_list.h, with the numeric values the browser uses internally.

Two of those repay a second look. ERR_PROXY_CONNECTION_FAILED covers two quite different faults in one message, name resolution and socket connection, which is why "unable to connect to proxy server" can mean a typo in the hostname or a firewall between you and a perfectly healthy machine. Chromium adds a limit that saves a lot of wasted searching: "Note that this does NOT include failures during the actual \"CONNECT\" method of an HTTP proxy." If the CONNECT is what failed, you are looking at a different code.

And ERR_TUNNEL_CONNECTION_FAILED is the one people misread most. The proxy was reachable. It answered. It then declined to open a tunnel to the destination you asked for, which on a corporate network usually means the destination is blocked rather than the proxy being broken.

And there is a reason that one tells you so little, which took reading Chromium's own connection code to find. When a proxy answers a tunnel request with any status other than 200 or 407, Chrome throws the response away on purpose. The comment beside that decision says it plainly: "Ignore response to avoid letting the proxy impersonate the target server", followed by the admission that "We have seen proxy 403, 404, and 501 response bodies that contain a useful error message."

So the proxy replied, it may well have explained itself, and your browser hid the explanation on purpose. Worth knowing before you spend an hour assuming nothing answered. Curl will show you what was said, because it has no user to protect from a hostile intermediary, and Section 5 has the exact string it prints.

Wording varies wildly and people search whichever string they were shown, but it sorts into two families with opposite diagnoses. One means nothing at the proxy answered: cannot connect to proxy, proxy server not responding, web proxy not responding, the configured proxy server is not responding, error proxy connection failed. One condition, five spellings.

The other says the reverse. The proxy failed to connect to the web server means the proxy answered you perfectly well and then could not reach the site, which is the far half of the journey. Checking your own settings will not move it.

Where Chrome gets its proxy from in the first place is its own question, and we took it apart in where Chrome's proxy settings really come from. None of these ERR_ names is an HTTP status code. So when you do have a number instead, the next question is not what it means but who put it there.

Who Generated This: Your Proxy, or the Website?

Here is the problem in one sentence. A 502 that your proxy produced because its own upstream failed, and a 502 that the website produced and your proxy politely handed you, arrive in exactly the same shape. Same number, same category, no label saying which. Nothing in the response is obliged to tell you.

The word "obliged" is doing real work there, because a standard way to tell you does exist and almost nobody uses it. RFC 9209, Standards Track since June 2022, defines the Proxy-Status response header for exactly this problem. Its abstract says it exists "to convey the details of an intermediary's response handling, including generated errors."

It is the right instrument because it names names. Each entry identifies the intermediary that added it, in a fixed order: "The first member represents the intermediary closest to the origin server, and the last member represents the intermediary closest to the user agent." Two examples printed in the RFC:

The error types are specific in a way a three-digit code cannot be. connection_refused is "The intermediary's connection to the next hop was refused". http_response_incomplete is "The intermediary received an incomplete response to the request from the next hop". Read either on a 502 and you know which hop failed and how, with no testing at all.

Two catches, and the RFC is candid about the first: "Intermediaries determine when it is appropriate to add the Proxy-Status field to a response." It is optional, and its own security section explains the reluctance, since the field means "information about the intermediary's configuration and backend topology can be exposed". Most proxies and most CDNs therefore send nothing at all.

The second catch is the same physics that limits Via. Your own forward proxy would have to put this on a response it generated, and on an HTTPS request the only response it generates is to the CONNECT, which Section 3 just showed you Chrome throws away. So a Proxy-Status you can actually read in the network tab has most likely come from the chain on the destination's side. That is still useful, and it is still not a statement about your proxy.

Check for it first anyway, because when it is there it costs you one glance. Then, for the overwhelming majority of the time when it is absent or not yours, do this instead.

You separate them by changing one variable at a time. Four steps, about two minutes, and it settles the question that the rest of this page depends on.

Do that before you change a setting, buy anything, or open a ticket. If it produced a number, Sections 5 and 6 tell you what the number is worth. If it produced nothing at all, skip to Section 7.

502, 504 and the Codes You Probably Cannot Fix

Proxy error 502 and its sibling 504 are the ones that fill the search results, and they are also the ones most often misdescribed. Both are defined around the idea of a server acting as an intermediary, which is precisely why they show up when a proxy is in the path.

So what is a 502 proxy error, exactly? MDN's definition of 502 Bad Gateway: it "indicates that a server was acting as a gateway or proxy and that it received an invalid response from the upstream server." Something answered, and what it said was broken. That is the whole 502 proxy error meaning, and notice what it does not say: nothing in it identifies which intermediary.

504 Gateway Timeout is the sibling, and the distinction matters more than most pages admit. MDN again: it "indicates that the server, while acting as a gateway or proxy, did not get a response in time from the upstream server in order to complete the request", and "This is similar to a 502 Bad Gateway, except that in a 504 status, the proxy or gateway did not receive any HTTP response from the origin within a certain time." A 502 means a bad answer arrived. A 504 means none did.

That is the specification's distinction, and it is worth holding lightly, because implementations do not keep to it. Apache returns a 502 when it cannot read a status line from the backend at all, which is the textbook description of a 504. So treat the pair as a hint about what happened upstream, never as proof. The isolation test tells you more than the choice of number does.

One entry there is worth arguing with, because the search volume insists on it. A 500 proxy error is barely a category. Unlike 502 and 504, the definition of 500 says nothing whatever about intermediaries. Proxies can still emit one; the number is simply silent on where the fault sits, which makes it the least diagnostic code on this page.

Notice that the right-hand column almost never says "yours". That is the honest shape of this topic, and it is why the isolation test comes before the table rather than after it. The one row where changing something on your side genuinely helps is 403, because that is usually the site deciding it does not want this particular request, which we cover in why websites block your IP address.

Which is why the wording of an error page is worth more than the number on it, and none of the pages ranking for this topic goes near this. Plenty of people arrive here having pasted one into a search box as proxy error reading from remote server. That string is Apache's: in mod_proxy_http.c it calls ap_proxyerror(r, HTTP_BAD_GATEWAY, "Error reading from remote server"), and builds the page with the number followed by the words Proxy Error above the note "The proxy server could not handle the request". Apache runs in both modes, so that names the software rather than whose side it sits on, but if you did not configure an Apache proxy yourself, the likeliest reading is a reverse proxy in front of the site.

Curl signs its work too, and in the opposite direction. Run it through a proxy that refuses your tunnel and it prints CONNECT tunnel failed, response 502, which really is about the proxy you configured. Note what curl does that Chrome will not: it shows you the status the proxy actually sent, which is the payoff promised in Section 3. There is a dating trick here as well. The older string is Received HTTP code 502 from proxy after CONNECT, or Received HTTP code 503 from proxy after CONNECT for any other number. Nothing has emitted it since curl 7.87.0 in late 2022. A guide still offering it as current is telling you how old its research is. Checked against curl 8.22.0 on 25 September 2026.

Which leaves the one code on that table that needs no test at all.

407 Is Not 401, and One Header Proves It

A 401 and a 407 both mean somebody wants credentials. They differ in who is asking, and the response itself carries the evidence.

A 401 arrives with a WWW-Authenticate header: the website wants you to log in. A 407 arrives with Proxy-Authenticate, which MDN describes as containing "information on how to correctly authenticate requests" to the proxy. Different header, different party, and no ambiguity about which one is asking. It is the one status code where the isolation test in Section 4 is unnecessary, because the answer is already in the response.

Which also makes it the most fixable of the lot. Somebody gave you a proxy and did not give you the credentials, or the ones you have no longer work. In a browser the proxy's own sign-in box appears and you type them there. Everywhere else they go in the proxy URL:

If the credentials are right and the 407 keeps coming, stop editing and go and ask. A 407 that survives correct credentials is the proxy's operator telling you something about your account, not a setting you can find.

Applications do not always surface it that cleanly. A client can meet a proxy demanding authentication and report something of its own invention instead, which is what happens in the OneDrive error Microsoft never documented. Which raises the last case, and the strangest one: the failures that produce no error at all.

When the Proxy Is Not Working and Nothing Is Broken

A whole category of proxy server problem produces no error at all. The proxy not working complaint here is that traffic is simply not going through it, and the reason is almost never the proxy. Ask why is my proxy not working when nothing on screen looks broken and the honest answer is usually one of three things, none of which is a faulty proxy.

The commonest version on Windows: you set a proxy, and something ignores it. That is not a fault, it is architecture. Windows keeps more than one proxy configuration and different software reads different ones, which we mapped in where Windows actually keeps its proxy settings. A browser obeying a setting while a command-line tool ignores it is the expected outcome, not a malfunction.

The second version is a setting that reverts. On a managed device, policy re-applies the configuration on its own schedule, so clearing it by hand lasts until the next refresh. The tell is that nobody touched the machine and it changed anyway.

The third is worth checking before either: the proxy works perfectly and you are testing it wrong. A saved field proves only what was typed, a point we made at length in what configuring a proxy actually does. Whether the outside world sees a proxy is a question only the outside world can answer, using the check in Section 2. All three are why advice on how to fix proxy server settings usually misses: in a proxy server not working case the settings are correct and simply unread.

If the failure turns out to sit below all of this, at name resolution rather than proxying, our guide to fixing IP address not found errors covers that layer.

That is every case this topic contains. What is left is the order to take them in.

The Order That Saves an Afternoon

Most answers to how to fix proxy error problems hand you a list of settings to change, in no particular order, with no way of knowing when to stop. Here is everything above compressed into the sequence I would actually run instead. It is short on purpose, and the order is the point.

One note on the other guides, since you will probably read a few. I checked all seven pages ranking for this on 25 September 2026. Two of them cite specifications and are worth your time: Coronium attributes 504, 429 and 407 to their RFCs, and WebScrapingAPI covers RFC 9209. None of the seven mentions the ERR_ layer, which means every one of them explains status codes to a reader who is often staring at a string that is not one. Credit on the other side too: Nimbleway's 502 advice carries the line most of that set will not print, "You may just need to wait until the web server admin fixes the issue."

The Short Version

The proxy error meaning that matters is structural, not a definition. An ERR_ name is your own browser describing a failure, and it may be hiding a status code it decided you should not see. A status code that does reach you says something answered. And whether your proxy produced that code or relayed it from the website is the question with no indicator light, which you settle by testing rather than guessing.

Almost all of it is written down. Chromium publishes what each of its network errors means and why it withholds what it withholds. MDN publishes what each status code means. RFC 9209 even defines a header whose entire job is to name the intermediary that generated the error, which is exactly the question you arrived with, and which most proxies quietly decline to answer.

Run the isolation test before you change anything: the same URL without the proxy, the same URL from outside your connection, a second proxy if you have one, and a proper look at the headers. Two minutes, and it tells you whose problem this is.

And if it is a 502 or a 504 from a struggling origin, the honest answer is that it is not yours, and no purchase changes that. To see what the far end makes of your connection, our IP trust score checker reports how the address you are leaving from is classified, which is where most of these investigations should have started.