Proxy Troubleshooting
An ordered checklist for the common failures: authentication errors, a proxy that seems unused, refused requests, and results from the wrong location.
Last updated
Most proxy problems present as a small number of symptoms with a large number of causes. Work down this list in order; the early steps catch the majority of cases.
Step 1: Confirm the endpoint works
Test the endpoint on its own with the Proxy Checker.
- It works. The problem is in your client or your code. Go to step 3.
- Authentication fails. Go to step 2.
- It does not connect at all. The endpoint or the address is the problem. Regenerate it from the Endpoint Generator using Replace.
Step 2: Authentication errors
| Check | Detail |
|---|---|
| Correct sub-user | The username must match a sub-user that exists and is provisioned |
| Correct password | Rotating a password changes it immediately; update the consumer |
| No stray whitespace | A copied password with a trailing space fails as if it were wrong |
| Not the account login | Sub-user credentials are separate from your sign-in password |
If the credential was recently rotated, see Reset a Sub-user Password for the update order.
Step 3: The proxy appears to be unused
The symptom is that a site reports your own address. The endpoint works when tested directly, so the client is not applying it.
Common causes:
- The client has its own proxy setting that the environment does not override, or the reverse.
- An exclusion list, sometimes
no_proxy, contains the target host. - The language or library in use requires explicit configuration and does not read the environment.
- Credentials were placed in a field the client does not read.
The language-specific shapes are in Code Snippets. Confirm the fix by re-checking the exit address, not by assuming.
Step 4: Requests are refused
The endpoint works, the client uses it, and the target still refuses.
| Situation | Likely cause |
|---|---|
| Refused only through the proxy | The address is treated as unsuitable; replace it |
| Refused with and without the proxy | The target is refusing the request pattern, not the address |
| Refused after a period of success | You have exceeded what the target tolerates; slow down |
The second row is the one to notice. If a direct request is also refused, rotating addresses will not help. Lower the request rate, and check whether a login or a cookie is required.
Step 5: Results come from the wrong place
The endpoint works but prices, rankings or content reflect the wrong market.
- Check the endpoint and note its Exit IP.
- Look that address up with IP Lookup.
- Compare the result with your targeting.
If the address is in the wrong place, widen the targeting, because narrow city-level targeting succeeds less reliably than country level. See Geo-Targeting. If the address is right and the result is still wrong, the target may be personalising by account or cookie rather than by address.
Step 6: Slow or timing out
- High added latency. Check the endpoint; if the added latency is high, replace it.
- Timeouts set too low. A request with an aggressive timeout fails on an endpoint that would otherwise succeed.
- Too much concurrency. Many parallel requests through one endpoint are slower and more likely to be refused than a paced sequence.
- Wrong workload for the address type. Heavy page fetches through an endpoint are slow by nature; fetching a structured response instead is usually the fix.
Step 7: The browser is involved
If the work happens in a browser, three checks settle most browser-specific problems: the endpoint itself, the address location, and whether the browser is leaking your real address. The third is the WebRTC Leak Test, and a leak invalidates everything else.
Gathering information before asking for help
If you escalate, include these four details:
- Which endpoint, described by its host and port.
- The exact command or code and its output.
- The time, with timezone.
- Whether the failure is consistent or intermittent.
Those four turn a support round trip into a diagnosis.