Proxy errors are annoying in a very particular way.
They're vague enough to be useless, but specific enough that you feel like you should be able to work it out.
Good news: each one is actually telling you something quite precise. Once you know the translation, most of them take under a minute to fix.
Here's the list I wish I'd had years ago.
ERR_PROXY_CONNECTION_FAILED
The single most common one, and the most misunderstood.
What it means: your browser couldn't reach the proxy at all. Not that the website failed. The proxy itself never answered.
Usually because:
- The proxy is dead. Free ones die constantly.
- You typed the port wrong.
- Your network blocks that port.
The fix: stop debugging your browser and test the proxy. Run it through our proxy checker. If it's dead, take the next one on the list. Nine times out of ten that's the whole story.
People lose entire evenings to this one. The proxy died. That's it.
407 Proxy Authentication Required
What it means: the proxy exists, it heard you, and it wants credentials.
Usually because: you're using a proxy that needs a username and password and you gave it neither, or you're behind a corporate proxy that wants your work login.
The fix: supply the credentials. In a browser you'll get a prompt. In code, most libraries take them in the URL as user:pass@host:port.
If you got this from a supposedly free public proxy, it isn't public. Move on.
403 Forbidden
This one confuses people because the proxy worked perfectly.
What it means: your request reached the website, and the website said no.
Usually because:
- The site blocks datacenter IP ranges
- That IP is already flagged from someone else's behaviour
- Your request looks automated
The fix: different problem, different tools. Try another proxy first, ideally from a different range. If every one fails on that site, it's blocking the type rather than the address, and you can read why in residential vs datacenter proxies.
If you're scripting, check your headers too. A default library user agent is an easy thing to block, which we cover in what is a user agent.
502 Bad Gateway and 504 Gateway Timeout
What they mean: the proxy tried to reach the site on your behalf and the attempt failed or ran out of time.
502 is “I tried and got nonsense back”. 504 is “I tried and nobody answered”.
Usually because: the proxy is overloaded, or the connection between proxy and site is bad.
The fix: retry once, then swap proxies. These are almost always the proxy struggling rather than anything you did. If one address gives you these repeatedly, it's tired. Let it go.
ERR_TUNNEL_CONNECTION_FAILED
What it means: the proxy couldn't set up an HTTPS tunnel.
Usually because: it's an HTTP-only proxy and you're asking for an HTTPS site. Which is nearly every site now.
The fix: use a proxy that supports HTTPS. Our proxy list labels protocol, so filter for it rather than guessing.
This error is basically the proxy admitting it's not equipped for the modern web.
It Works, Then Stops After a Minute
Not an error code, but the most maddening behaviour there is.
What's happening: either the free proxy hit its limit, or it died mid-session, which free proxies do without warning.
The fix: accept it and plan around it. Keep three or four working proxies on hand rather than one. When one dies you swap in seconds instead of starting over.
Treat free proxies as disposable. They are.
Two Errors That Aren't Really Proxy Errors
These two send people down the wrong path constantly, so they're worth naming.
Certificate warnings. Your browser complains the connection isn't private while a proxy is on. Sometimes that's the proxy inspecting your traffic, which is worth knowing about. Often it's just a badly configured server. Either way, don't click through it out of habit. That warning exists for a reason.
429 Too Many Requests. Nothing to do with the proxy at all. The site is rate limiting you. Your proxy is working perfectly, you're just asking too fast. Slow down, add delays, and spread requests across more addresses.
Swapping proxies won't fix either of these, though people try for ages.
The Debugging Order That Saves Time
When something breaks, go in this order. It sounds obvious and almost nobody does it.
- Is the proxy alive? Check it. Don't assume.
- Right protocol? HTTPS site needs an HTTPS or SOCKS proxy.
- Right port? One wrong digit produces an identical error to a dead server.
- Does it work without the proxy? Rules out everything else in one step.
- Try a different proxy. If number two works, number one was the problem.
Step one solves most of it. Most proxy errors are not configuration mysteries. They're a dead server and a person who assumed otherwise.
More on keeping a working set: how to check if a proxy is working.
Bookmark this page if you script a lot. Future you, staring at a 502 at one in the morning, will be glad of it.
And keep a spare proxy or two ready before you need them. Almost every long debugging session on this list started with someone having exactly one address and refusing to believe it had died.
