# Troubleshooting proxy errors: 407, 400, 402, 403, 429, 502 and timeouts

Half of proxy troubleshooting is knowing who answered: the gateway or the website. The status code and where it appears tell you, and each combination has one fix.


## Step 1: who answered?

Run the failing request with `curl -v`. A status on the `CONNECT` line, before `Connection established`, comes from the gateway; a status after it comes from the destination. Browsers show gateway failures as `ERR_TUNNEL_CONNECTION_FAILED` or `ERR_PROXY_CONNECTION_FAILED`.


## Step 2: gateway codes

| Code | ProxShift meaning | Fix |
| --- | --- | --- |
| 407 invalid_credentials | Username or password rejected | Copy the pair again; check for trailing spaces; whitelisted IP changed? |
| 400 invalid_parameter | A username parameter is unknown or malformed | Check keys and values: -cc-gb not -cc-uk, -city- without spaces, -ttl- from 1m to 24h |
| 402 insufficient_balance | No traffic or balance left | Top up; check the sub-user ceiling if you use one |
| 403 blocked_destination | Port or destination not allowed | Port 25, UDP and IPv6-only targets are refused by design |
| 502 no_exit_available | No exit matches the location right now | Widen: drop -city- or -asn-, keep -cc-; retry in a minute |
| 502 exit_failed | The exit failed before the target | Retry once; the next connection picks another exit |
| 504 target_timeout | The destination did not answer in time | Retry; check the target from another network |


## Step 3: destination codes

| Code | Likely cause | Fix |
| --- | --- | --- |
| 403 (site page) | Exit type or fingerprint rejected | Residential or mobile exit; realistic client headers; sticky session for flows |
| 429 | Per-IP rate limit | Rotate per connection; lower per-exit rate; honour Retry-After |
| 200 with empty data | Soft block | Treat like 403; inspect content, not status |
| 302 to a challenge page | Bot check | Slow down; real browser for that target; better exit type |
| 5xx | Target trouble | Back off; not a proxy problem |


## Connection-level failures

- `ECONNRESET`, `Connection reset by peer` mid-transfer: the household exit dropped. Retry once; on a sticky session the gateway rebinds to a new exit in the same location.
- Idle timeouts: the gateway closes connections idle for 60 seconds. Long-polling needs a fresh connection.
- TLS errors through the proxy: never normal. Check for a local interceptor (corporate proxy, antivirus) between you and the gateway.


## Step 4: decide

1. Credentials or parameters wrong → fix and retry (no cost).
2. Gateway found no exit → widen the location.
3. Target blocks the exit type → move the target to a stronger network: datacenter → residential → mobile.
4. Target rate-limits → rotate more and slow down; never both hammer and rotate.
5. Target broken → wait.


## Questions

**Does ProxShift ever return 429?**

No. The gateway has no request-rate limit; a 429 always comes from the destination.

**Am I billed for failed requests?**

Connections that fail before reaching the target are not billed. A 403 or 429 page from the destination is billed for its size, usually a few kilobytes.

Source: https://proxshift.com/guides/troubleshoot-proxy-errors