Start with a 60-second diagnosis
Before changing anything, find out where the problem is:
- Test the proxy with cURL against a neutral site such as httpbin.org/ip. See Webshare with cURL.
- If cURL fails, the problem is the proxy, credentials, plan or network.
- If cURL works but your app fails, the problem is your app's proxy configuration.
- If both work on httpbin but fail on your target, the target is blocking or rate-limiting you.
Also check Webshare's status page for incidents and the dashboard for plan usage.
407 Proxy Authentication Required
The proxy rejected your credentials. Causes, from most to least common:
- Typo or stray space in the username or password. Copy them again from the dashboard.
- Special characters in the password breaking the proxy URL. URL-encode them or pass credentials separately.
- Mode mismatch. Direct-mode credentials used on the backbone gateway, or backbone credentials on a direct IP. See backbone vs direct connection.
- IP authorization expected, but your IP changed. Update the allowlist. See IP authorization.
- Tool doesn't send credentials (Chrome flags, Selenium). Use the tool's auth method or IP authorization.
Connection refused or cannot connect
- Wrong port or host.
- A firewall, office network or antivirus blocking outbound proxy ports.
- The plan expired or the proxy was replaced. Download a fresh list.
- Using SOCKS5 settings with an HTTP-only client, or the reverse.
Timeouts and slow responses
| Pattern | Likely cause | Fix |
|---|---|---|
| Timeouts only at high concurrency | Plan thread limit | Lower concurrency or raise threads. See bandwidth and threads |
| One or two IPs always slow | Bad proxies | Replace them |
| Residential slow in a small city | Few IPs online there | Target state or country instead |
| Everything slow suddenly | Incident or target slowness | Check status page and target directly |
| Slow only on one site | Target throttling | Slow down per IP |
Always set timeouts in your code so a slow proxy fails fast and retries.
403, 429 and CAPTCHAs
These come from the target site, not Webshare.
- 403 on every request: the site likely blocks datacenter ranges. Move that target to rotating residential.
- 429 Too Many Requests: you're too fast per IP. Add delays and spread requests across more IPs. See rate limiting and proxies.
- CAPTCHAs: a mix of IP reputation and fingerprint. Improve headers and browser fingerprints, use residential IPs, and slow down. See CAPTCHAs and proxies.
Provider-side refusals
If one domain fails instantly on residential traffic with a proxy error (not a site page), it may be on Webshare's restricted list. See restricted sites and KYC and contact support.
Budget tip: You can test most of this guide for free: Webshare gives every new account 10 datacenter proxies and 1 GB of bandwidth a month without a credit card. Move to a paid plan once the pilot works. See our complete Webshare guide.
Wrong country or city
- Proxy lists: check the plan's location settings; replace IPs that geolocate wrongly.
- Residential: check the targeting parameters in your username.
- Databases disagree: an IP can be "Chicago" in one database and "Illinois" in another. Check with several.
Bandwidth ran out
If everything stops working near the end of a billing period, check usage in the dashboard. Upgrade the plan or wait for the reset, and reduce usage by blocking images and media. See bandwidth and threads.
The IP isn't changing
- Direct IPs never rotate. Rotate in code or use the backbone with the rotate option.
- A session username keeps the same IP on purpose.
- Your HTTP client may reuse a keep-alive connection to the gateway; some clients keep the same exit for a connection. Create a new connection per request when you need a new IP.
When to contact support
Contact Webshare support with: the proxy (or gateway) you used, the time, the target domain, the exact error and a cURL command that reproduces it. That gets answers much faster than "my proxies don't work".
A troubleshooting flowchart in words
- Does cURL work against httpbin.org through the proxy?
- No: check credentials, mode, IP authorization, plan status and network. Stop here until it works.
- Yes: continue.
- Does cURL work against your target?
- No: the target is blocking. Check for challenge pages, slow down, try another product.
- Yes: continue.
- Does your app work against httpbin.org?
- No: your app's proxy configuration is wrong. Compare the exact proxy URL with the cURL command.
- Yes: continue.
- Does your app work against your target?
- No: the difference is in headers, TLS, cookies, concurrency or rate. Compare with cURL and reduce concurrency.
Proxy tip: If your residential usage goes up and down, compare Geonode: its per-GB residential bandwidth doesn't expire, so you only pay for what you use. See Webshare vs Geonode.
Error reference
| Error | Usual cause |
|---|---|
| 407 | Credentials, mode or IP authorization |
| 502 or 503 from the proxy | Upstream problem or provider-side refusal; retry, then check status |
| Connection reset | Thread limit or network filtering |
| SSL errors | Wrong proxy scheme (https vs http) or interception on your network |
| 403 from target | Block; change product or method |
| 429 from target | Rate limit; slow down |
Prevent problems before they start
- Monitor success rate per target and alert on drops.
- Keep timeouts and retries consistent across tools.
- Reload proxy lists regularly.
- Track bandwidth against your plan.
Most "proxy outages" turn out to be target changes or local configuration drift, and good monitoring shows that within minutes.
A real-world example
A scraper's success rate on one marketplace drops from 95% to 40% overnight. The team follows the flowchart: cURL to httpbin works, so the proxies are fine; cURL to the marketplace returns challenge pages from every IP, including fresh replacements. The marketplace has started blocking datacenter ranges. They move that domain to rotating residential traffic, success returns to 93%, and the rest of the scraper stays on datacenter IPs. No proxies were replaced unnecessarily.
If you're still shortlisting, compare this setup with the options in our best proxies guide, and use our cheap proxies guide to estimate what a sensible budget looks like.
Key takeaways
- Start every investigation with a cURL test against a neutral site, then against your target.
- 407 errors are almost always credentials, mode mismatches or IP authorization.
- Errors only at high concurrency point to thread limits; 403 and 429 come from the target.
- Provider-side refusals on one domain may be residential restrictions.
- Good monitoring of success rates per target catches most problems quickly.
FAQ
Why do my Webshare proxies work in the browser but not in Python?
Usually a proxy URL format problem or missing HTTPS proxy setting. Use the same URL for both http and https keys. See Webshare with Python.
Why do I get CAPTCHAs on every request?
The target is likely suspicious of your IP type or fingerprint. Try residential IPs, slower rates and realistic browser settings.
Are Webshare proxies down?
Check the status page. If it's green and cURL fails, check credentials and plan status.
Why do I get 502 errors from Webshare?
A 502 from the proxy usually means it couldn't complete the upstream connection. Retry, check the target, and check the status page.
Why do some proxies in my list fail and others work?
Individual IPs can be down or blocked on a target. Replace or exclude them.
How do I reach Webshare support?
Use the support channels listed in the dashboard and help centre, and include a cURL command that reproduces the issue.
Editorial note: Proxy providers change their pools, features and prices often, so treat any figures here as typical ranges at the time of writing and confirm current terms with the provider before you buy.