The same code arrives from different layers: your client, the proxy service, the platform, and the protection sitting in front of it. This table saves time spent on the wrong hypothesis.
| Code | Who usually issued it | What to do |
|---|---|---|
| 407 | proxy service | check credentials or the IP binding in your dashboard |
| 403 | platform | repeating leads nowhere, the question is address reputation |
| 429 | platform, sometimes the package | respect Retry-After, lower the rate, spread load across addresses |
| 502 and 504 | proxy node or target server | retry with a pause, swap the address if it repeats |
| 503 | protection in front of the site | read the body, a verification page often sits there |
| 200 with no data | platform | a silent refusal, verify response content, the status code proves little |
| Connection refused | your side | wrong port or the service is not listening |
| Timeout | network or node | check node availability, raise the client timeout |
Order of probes, cheapest first: read the full header set of the response, repeat the request with no proxy, repeat from the same address against a different site, repeat the same page from a different address. The first two close most cases.
curl -i -x socks5://user:pass@host:port https://example.com/page
The -i flag matters: without it the headers disappear, and the headers are where the culprit shows. Values in the x-ratelimit family normally come from the platform, while retry-after is set by whichever layer stopped the traffic.
When refusals hit every address and every destination at once, the package is the source. A package with no request counter removes that hypothesis from the investigation entirely.