JustProxies

Reference

Error reference

4-min readerrors
Every code we routinely emit, mapped to whether it's ours or the target's problem and whether to retry. Skim the table; deeper discussion below.

Ours vs. theirs

We pass target responses through unchanged. If a target returns 403, you see a 403. If we have something to say (auth, policy, capacity), we wrap it in our own status code with an X-Proxy-Reason header explaining why.

Quick rule of thumb
407, 451, 502, 503, 504 with an X-Proxy-Reason header are ours. Everything else is the target talking back.

Auth and access codes

407 means we couldn't authenticate the request. 451 means the request violated our Acceptable Use Policy — see /aup. Both are terminal — no retry will fix them.

Upstream / target codes

Most production pain is target-side: 403/429/5xx from anti-bot systems. The single most effective remedy on rotating products is a retry — the next exit IP clears the previous block more often than not.

Diagnostic headers

On every response we add three headers that cost nothing to inspect:

  • X-Proxy-Exit-Country — ISO-2 of the exit country we routed through (e.g. DE).
  • X-Proxy-Poolresidential, mobile, datacenter, or datacenter-static.
  • X-Proxy-Reason — only on 4xx/5xx that we generate. Plain-text single-line explanation.

Retry decision table

CodeSourceMeaningRetryGuidance
200targetOKdon’tNothing to do — the request landed.
302 / 301targetRedirect from the targetdon’tFollow it (most clients do automatically). Not a proxy issue.
401targetTarget says you aren’t authenticateddon’tYour auth on the target site is missing/wrong — not a proxy problem.
403targetTarget blocked the requestmaybeCommon when a target ASN-blocks. On rotating products, retry — the next exit IP often clears it. Persistent 403 means picking a stronger pool (residential / mobile).
407proxyProxy authentication requireddon’tYour proxy credentials are missing or wrong. Re-check USER:PASS, especially for embedded special characters that need URL-encoding.
429targetTarget rate-limited the requestretryBack off, then retry — ideally with a different exit (drop the sticky token if any). On rotating products this is straightforward.
451proxyAcceptable Use violationdon’tWe blocked a request because the destination violates our AUP (sanctions list, CSAM, etc). Order is suspended pending review.
502proxyUpstream pool errorretryThe pool couldn’t complete the connection. Retry; if it persists, check /status and email support with the timestamp.
503proxyConstraint can’t be honouredmaybeCountry/carrier targeting requested but no inventory available right now. Drop the constraint or wait a few seconds; check the X-Proxy-Reason header.
504proxyUpstream timeoutretryThe exit IP took too long to reach the target. Retry on rotating products; on static, swap the IP via support if the same one keeps timing out.
522targetCloudflare connection-timed-outretryOften transient on the target side. Retry once. If repeated for the same target, lower concurrency.
Connection resettargetTarget dropped the TCP connectionretryAlmost always target-side. On rotating products a retry usually picks a different exit and recovers.
Found a gap, or something wrong?
A real human reads support email.