This reference groups the codes that appear most often in proxy workflows and gives the first diagnostic step for each.
401 and 407 are different
A 401 means the destination rejected your application credentials. A 407 means the proxy rejected your proxy credentials. They look similar in logs and are frequently confused.
If you see 407, check the proxy username, password, and encoding. If you see 401, the proxy is working and the destination is the problem.
403 and 429 mean the target is pushing back
A 403 is a refusal. It can come from bot management, a geo restriction, a login wall, or a rule that blocks the exit IP range. A residential IP from the right country may resolve a geo restriction; it will not resolve a fingerprint mismatch or an account requirement.
A 429 is a rate limit. The correct response is to slow down and respect the Retry-After header when it is present. Rotating IPs to evade a rate limit is both ineffective and hostile; most mature targets rate-limit by account, cookie, or fingerprint as well.
502 and 504 usually come from the gateway
A 502 indicates that the proxy could not get a valid response from the upstream peer or target. A 504 indicates a timeout while waiting. Both can be transient.
Retry with a small delay and a different session if the problem persists. If every request returns 502, check the target from a direct connection to determine whether the destination is down.
Codes that are not errors for your pipeline
A 301 or 302 is a redirect. Follow it deliberately rather than treating it as a failure, and make sure the client is not silently dropping the proxy configuration on the new request. A 304 can be a sign that caching is working as intended.
- 407: fix proxy credentials or allowlisting.
- 401: destination credentials, not the proxy.
- 403: inspect fingerprint, geo, and IP reputation.
- 429: slow down and honour Retry-After.
- 502/504: retry with backoff; check target health.
Read the body before acting on the code
The status code is only the first signal. A 200 response can still be a challenge page, a consent wall, or an error rendered with a friendly layout. A 403 can be a temporary rate-based refusal or a permanent policy decision.
Log a small fingerprint of each response: content type, length, title, and whether the expected element was present. Comparing fingerprints across runs is often faster than reading full pages, and it catches silent failures that a status-code-only monitor would miss.
A retry policy per status family
Group statuses into families and give each one a policy. Success statuses proceed. Redirects are followed within a limit. Client errors are not retried blindly; they need a configuration or targeting change. Rate limits retry after a delay. Server and gateway errors retry with backoff and a cap.
Keep the policy in code rather than in individual scripts. When a new workflow is added, it should inherit the same rules. That consistency is what makes incident reviews useful: a failure means something changed, not that a different script had a different idea about retries.
Proxy-generated versus origin-generated responses
A status code can come from the proxy or from the destination, and the two need different responses. Proxy errors often omit the target's usual headers, or include a server header naming the proxy software. Origin errors usually carry the site's own security headers and error layout.
When a code is ambiguous, request a known endpoint through the same proxy. If the proxy returns a clean success there, the failure belongs to the target. If it fails identically, the problem is upstream of the site.
Keep the distinction in your logs by recording which endpoint produced the response. Mixing the two inflates target error rates and hides proxy instability, which makes both problems harder to fix.
Key takeaways
- Identify whether the code came from the proxy or the destination before changing anything.
- 429 is a signal to reduce load, not to rotate harder.
- Transient 502/504 responses should be retried with backoff before escalation.
Frequently asked questions
Why do I get 407 only on some requests?
The client may be sending proxy authentication on some code paths but not others, or a redirect may be dropping the proxy configuration. Inspect the full request chain, not just the first hop.
Should I retry a 403?
Usually not without a change. A 403 is a policy decision. Retrying the same request from the same fingerprint tends to produce the same result and adds load to the target.
What does a 200 response with unexpected content mean?
The target served a page, but it may be a challenge, a consent screen, or a regional variant. Check the body and headers rather than trusting the status code alone.
Need proxies for this workflow?
Graviix provides residential, mobile, datacenter, and static ISP proxies with country and city targeting, rotating or sticky sessions, and a documented HTTP API.
