Response codes through a proxy
The same number arrives from four different places: your client, the proxy service, the network in between and the platform itself. Filter by code or by layer and the guessing stops.
| Code | Who returned it | What it means and what to do |
|---|
Read the layer before the code
Most time lost to debugging goes on treating a platform refusal as a proxy fault. The quickest separation is a sequence of four probes, cheapest first: read the full header set, repeat the request with no proxy at all, repeat from the same address against a different site, then repeat the same page from a different address. The first two close most cases within a minute.
407 and 403 are not neighbours
407 comes from the service and means the connection itself was refused: wrong credentials, or a machine whose address is not bound in the dashboard. 403 comes from the target site and means the request arrived and was turned away. Repeating a 403 changes nothing, while a 407 is fixed in the dashboard in under a minute. Addresses whose reputation stays under your own control come from server addresses on dedicated hardware.
Headers carry the answer
Run curl with the -i flag so headers survive. Values in the x-ratelimit family come from the platform and state the allowance directly. Retry-After names the pause the platform expects. A body that arrives with status 200 and no data at all is a refusal wearing a success code, which is why a marker check belongs in every collection loop.
When every address returns the same thing
Refusals that hit every address and every destination at the same moment point at your own side or at the package, not at reputation. Check the bound address first, then the thread count against the cap. A package with no counter on volume removes one whole class of hypothesis from the investigation.