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 | Proxy Cyber 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#
- A reset can come from the client, proxy path or destination. Record whether it happened during CONNECT, TLS negotiation or data transfer; test the same small URL directly and through the proxy to narrow down the failing hop.
- An idle timeout can come from the client, gateway, exit or destination. Record the elapsed time and compare the client’s connect/read limits with the assigned service settings. A connection reset does not by itself prove that the residential exit went offline; reproduce the error with a small request before changing the configuration.
- TLS errors through the proxy: never normal. Check for a local interceptor (corporate proxy, antivirus) between you and the gateway.
Step 4: decide#
- Correct the credentials or parameters before retrying repeatedly. A failed request can still transfer bytes; check the recorded usage and applicable billing terms rather than assuming that every error is free.
- Gateway found no exit → widen the location.
- Target blocks the exit type → move the target to a stronger network: datacenter → residential → mobile.
- Classify the response before retrying. A 403 may indicate an access rule that another IP will not resolve. For 429, respect Retry-After and reduce the request rate; use bounded backoff for temporary connection or server failures. Retry state-changing operations only when you can prevent duplicate actions.
- Target broken → wait.
Questions people ask#
Does Proxy Cyber ever return 429?
A 429 can be returned by a destination or an intermediary that applies a rate limit. Inspect the response headers and the CONNECT exchange to identify the source. Preserve Retry-After when present, lower concurrency and keep a short log of timestamps and request IDs for support; changing IP is not a substitute for respecting the limit.
Am I billed for failed requests?
Estimate traffic from a representative test, then compare the balance before and after it. Response bodies, uploads, browser assets and retries all affect consumption. Confirm the applicable metering and refund terms before paying; this guide does not promise that failed requests are free or that unused funds are automatically refundable.