Skip to main content
When something goes wrong, the error either comes from us (the proxy) or from the target site you asked for. Telling them apart used to require guesswork. Now it doesn’t:
Every error generated by the proxy carries an X-Proxy-Error response header with a stable code like PX1002. If that header is absent, the response came from the target site and we passed it through untouched.
The response body repeats the code on its first line, so you can read it without inspecting headers:
On https:// URLs, most clients hide this. An HTTPS request opens a tunnel with CONNECT, and when that fails, libraries like Python requests, Node axios and Go’s http.Client raise a connection error instead of returning a response — so the header and body never reach your code. You get the status only: Tunnel connection failed: 502 Bad Gateway.The code is still on the wire. curl -v shows it, and the table below maps each status back to its possible causes. On http:// URLs the header is always readable.
Where you can read the code, match on it rather than on the HTTP status: statuses are shared with the target site, while the codes are ours alone and will not change.

Errors you can fix

These mean the request needs to change. Retrying it unchanged returns the same error.
A 407 now only ever means your credentials or your data balance. It is never a problem on our side, so re-sending the password will not help when the cause is PX2002.

Errors worth retrying

These are conditions in the exit network. The same request will often succeed a moment later.
Use exponential backoff and rotate to a new session-SESSION_ID between attempts. Hammering the same session and the same narrow targeting tends to hit PX1002 repeatedly.

Errors about the destination

Errors from the target site

If a response has no X-Proxy-Error header, it came from the site you requested and reached you exactly as they sent it. We never rewrite a target’s status code, headers or body. This is why matching on the PX code matters: a 403 from us (PX1003) and a 403 from the target site mean completely different things and need completely different fixes.

Handling errors in code

On http:// URLs, read the header directly:
On https:// URLs, catch the proxy error and branch on the status in its message:
To see the exact code while debugging an HTTPS failure, use curl -v and read the CONNECT response:

Reading the code on HTTPS

When you only have the status, this is what it narrows down to:

Connection-level failures

Some failures happen before any HTTP response exists, so they carry no code:

Still stuck?

Reach out at team@roundproxies.com or visit the Help Center. Quote the PX code and the time of the request — it tells us exactly which stage failed.