The short version: proxy errors split cleanly into two groups, and knowing which group you are in saves most of the debugging. Anything in the 4xx range that comes from the proxy means your request never left our network. Anything that comes from the target means it did leave, and the site made a decision about it. Fix the first kind in your config; fix the second kind by changing which IPs you are using.
The ones that come from the proxy
These never reach the site you were trying to load.
| Code | What it means | Usual cause |
|---|---|---|
| 407 | Credentials refused | Auth disabled in your client, wrong field order, or an empty balance |
| 502 | Gateway could not reach upstream | Bad target hostname, or the exit node dropped mid-request |
| 503 | No exit available for your filter | Targeting so narrow nothing matches - a city with a thin pool, plus an ISP filter on top |
| 429 | Rate limited | Too many concurrent sessions from one sub-user |
407 is far and away the most common, and it is worth being precise about because the fix depends entirely on which of the three causes you have. If your dashboard shows bandwidth remaining and you still get 407 on every request, that is not a configuration problem and no amount of re-entering the password will help - test the credentials, then talk to support.
The ones that come from the target
Different animal entirely. The proxy did its job.
| Code | What the site decided | What to change |
|---|---|---|
| 403 | This IP is not welcome | IP type - move from datacenter to residential |
| 429 | Too fast from this IP | Rotation frequency, or add delay |
| 503 / 522 | Challenge page, often Cloudflare | Fingerprint and headers, not the IP |
| ECONNRESET | Connection killed mid-flight | Usually TLS fingerprint. Your client looks automated |
The distinction that trips people up: a 403 and a Cloudflare challenge look similar in logs but have opposite fixes. A 403 is a verdict on your IP. A challenge is a verdict on your client - same IP, different browser, different result. Rotating IPs against a fingerprint problem burns bandwidth and changes nothing.
How to tell which group you are in
Two commands settle it.
# does the proxy work at all?
curl -x http://USER:PASS@resi.spyderproxy.com:5000 https://ipinfo.io/ip
# does it work against your actual target?
curl -x http://USER:PASS@resi.spyderproxy.com:5000 https://your-target.exampleIf the first fails, stop - it is credentials or balance, and nothing about the target matters yet. If the first returns an IP and the second fails, the proxy is fine and you are looking at a targeting or fingerprint problem.
That order matters more than it sounds. Most of the debugging time we see people lose goes on investigating the target when the first command would have failed too.
The errors people misread most often
407 with a visible balance. Intuitively this should be impossible. In practice a sub-user can end up in a state where the account shows bandwidth but the gateway rejects it. If you have confirmed the credentials are right and you still get 407, escalate rather than reconfiguring.
Intermittent 502s. A handful across thousands of requests is normal - residential exits are real devices on real connections, and some of them go offline mid-request. Retry once. If it is more than roughly one in fifty, something else is wrong.
Everything works in curl but fails in the browser. Almost always the browser is doing something curl is not: DNS outside the tunnel, WebRTC, or a stored session. Our DNS leak test and WebRTC test will show you in a few seconds.
Works on the first request, dies after that. You are on rotating when you wanted sticky. Any flow with a login or a cart needs the same IP for its duration.
A note on retries
Retry logic hides problems. If you retry three times on failure and your success rate looks acceptable, you may still be failing two thirds of your first attempts and paying for all of it. Log the first-attempt rate separately from the eventual one. The gap between those two numbers is the real measure of whether your setup works, and it is the number that shows up on your bill.
If that gap is large, the fix is usually IP type rather than more retries. Protected targets that reject datacenter IPs will often accept residential ones on the first try.
Frequently asked questions
What does proxy error 407 mean?
407 is the proxy refusing your credentials. Nine times out of ten it is one of three things: authentication is switched off in your client, the username and password went into the wrong fields, or your bandwidth balance is empty. It is never a problem with the target site - your request never got that far.
Why do I get 403 through a proxy but not without one?
The proxy worked. The target site looked at the IP it received and decided it did not like it. That points at pool quality or IP type rather than configuration - datacenter ranges get 403s on protected targets that residential IPs walk straight through.
Is ECONNRESET a proxy problem or a target problem?
Usually the target. A reset arrives after the connection is established, which means your request reached the site and something there ended it - rate limiting, a fingerprint check, or an outright block. If it happens on every site including plain HTTP ones, then suspect the proxy.
Does a proxy error mean I lost bandwidth?
Only if data moved. A 407 costs you nothing because authentication failed before any traffic passed. A 403 does consume a little - the request went out and a response came back. Large numbers of 403s are worth fixing for that reason alone.