Read the error, find the hop: which part of the chain broke
Almost every proxy support conversation starts the same way: it is not working. The reason that is hard to answer is that “it” is four different things in a trench coat.
A proxied request is not one connection. It is a chain, and each link fails with its own signature. Learn the signatures and you can usually diagnose the problem before anyone else looks at it.
The chain
407: the proxy did not accept you
A 407 is the proxy saying it does not recognise your credentials. It never reached the target, so nothing about the target is relevant.
In practice it is nearly always one of three things: the password is not what you think it is, the plan has expired, or the username is subtly wrong — a stray space, the wrong separator, or a parameter appended in a format the server does not parse.
Worth knowing: on most services the proxy password is not your account password. It is a separate key from the dashboard, and regenerating it invalidates the old one everywhere you had it configured.
Refused or reset before anything happens
If the connection drops before authentication is even attempted, you never got as far as the proxy caring who you are.
The most common cause by a distance is an IP whitelist. If your account has one or more addresses on it, connections from anywhere else are refused outright. That produces “connection was reset” rather than a clean authentication error, which is why it fools people — it looks like a network fault, not a permission one.
This catches people out most often when a VPN is involved, because VPN exit addresses rotate. The address whitelisted yesterday may not be the one leaving today. If a whitelist is set and you cannot connect, check your current outgoing address before anything else.
The other candidates are ordinary: a firewall on your side, a corporate network blocking non-standard ports, or the wrong hostname entirely. It is worth checking the hostname character by character — a single missing letter can resolve to somebody else’s server, which will happily accept a connection and then never answer.
502 and timeouts: the hop failed
This is the middle of the chain. The proxy accepted you and tried to reach the target through an exit address, and that leg did not complete.
On residential networks this is normal at some rate, because the exit is a real consumer connection that can drop at any moment. A single 502 means nothing. A sustained rate of them means something, and the useful question is whether it is concentrated on one country, one port, or one target.
If it is concentrated on a country, you are asking for somewhere with less capacity than your request rate needs. If it is concentrated on a target, that site is likely refusing the connection at a lower level. If it is spread evenly, look at your concurrency.
403, 429 and captchas: the target decided
Here the whole chain worked. Your request arrived, and the site chose not to serve it.
This is the category people most often misattribute. A 403 is not a proxy failure — it is proof the proxy succeeded, because something had to arrive for the site to refuse it.
Changing address sometimes helps and often does not, because modern bot detection looks at far more than the address: TLS handshake characteristics, HTTP header order, and behaviour over time. A clean address with an obviously automated client is still an obviously automated client.
The thirty-second test
One command separates the first three stages from the last. Point your proxy at an endpoint that has no opinion about you:
curl -sS -x "http://USERNAME:PASSWORD@HOST:PORT" -w "\nstatus=%{http_code}\n" https://api.ipify.org
If that returns an address and a 200, the chain is fine end to end. Every failure you are seeing belongs to the target, and no amount of credential-checking will help.
If it returns 407, your credentials or plan are the problem. If it hangs or resets, you have not reached the proxy — check the whitelist and the hostname. If it returns 502, the hop is failing, and the country or your concurrency is the thing to look at.
Run it before you open a support ticket, and include the result when you do. It converts “it is not working” into a specific question, which is the difference between a day of back-and-forth and a five-minute answer.
If you want more depth on individual causes, why a proxy connection gets reset covers the first stage in detail, and why IP checkers flag proxies covers the last.
ProxyOmega