Troubleshooting Proxy Connections

Before touching your scraper, bot, or browser settings, run one request straight from a terminal. This removes your tool from the equation and tells you which section of this guide to read next.

# HTTP / HTTPS proxying
curl -v -x "http://USER:PASS@<proxy-host>:80" https://example.com -o /dev/null

# Same endpoint, SOCKS5 (socks5h resolves DNS through the proxy)
curl -v -x "socks5h://USER:PASS@<proxy-host>:80" https://example.com -o /dev/null

• 407 Proxy Authentication Required — credential problem. Go to Authentication failures.
• Connection refused or timeout before any response — network path or local firewall. Go to Timeouts and resets.
• Connects, then stalls or resets mid-transfer — upstream peer or slow target. Also Timeouts and resets.
• A 403, a challenge page, or unexpected HTML — the target made a decision. Go to Blocked or unusual responses.

A 407 means the endpoint saw your request but rejected the credentials. The usual causes, in rough order of frequency:

• Copy-paste damage. Trailing whitespace, a stray newline, or a truncated username from a spreadsheet cell. Re-copy the line from the proxy generator using Copy all.
• Regenerated credentials. Regenerating proxy credentials in the dashboard invalidates the old ones immediately — every previously exported .txt list dies at that moment. Re-export and replace the lists everywhere they are used.
• Whitelist IP changed. If you use IP whitelist auth instead of a username and password, remember it matches up to 3 exact IPs — no CIDR ranges. Home connections and cloud instances change IPs; update the entry in the dashboard when yours does.
• Malformed username suffixes. -cc (country) and -co (continent) are mutually exclusive — use one or the other. City names must have spaces and diacritics stripped (São Paulo becomes SaoPaulo), and -ttl- accepts at most 86400 seconds.

A correct targeted username looks like user123-cc-US-s-mysession-ttl-600. Suffixes only ever modify the username; the password never changes. If a plain untargeted username works but a targeted one fails, the suffix syntax is the problem.

Residential IPs are real devices on real home connections, sourced from a consenting bandwidth-sharing network. A peer can go offline mid-session — that is normal behavior for this class of proxy, not an outage.

• Rotating mode: just retry. Every request gets a new IP, so a failed peer costs you one request.
• Sticky sessions: if a pinned IP dies, change the -s- session ID to any new value and you get a fresh IP. Also check the TTL — sticky sessions expire after 60 seconds by default, so a session that "resets" every minute is simply expiring on schedule. Extend it with -ttl-, up to 24 hours.
• Slow target: fetch the target once without the proxy. If it is slow directly, the proxy is not the bottleneck.
• Local firewall: some corporate networks and security tools block outbound port 80. Test from another network or ask your administrator to allow egress to <proxy-host>:80.

If the proxy connects and authenticates but the target returns a 403, an empty body, or a verification page, the target's own systems made that decision. This is not a proxy malfunction, and it is not something the platform will help you defeat.

What you can legitimately do:

• Lower your request rate and concurrency. Many "blocks" are ordinary rate limiting that clears on its own.
• Check the target's robots.txt and terms of service, and only collect public data you are permitted to access.
• Use a different geo target where that is legitimate — for example, requesting the regional version of a public page you are entitled to view.
• If the target says no even at polite request rates, accept that answer. You are responsible for compliance with every site you access.

If connections worked yesterday and fail everywhere today — including in the built-in checker — check your remaining GB in the dashboard before debugging anything else. An exhausted balance looks a lot like a technical fault.

1. 01Open the dashboard and check remaining GB on your pay-per-GB plan.
2. 02If you are out, buy more GB from balance — GB and balance never expire, so there is no rush to size the purchase perfectly.
3. 03Enable auto-replenish so a future top-up becomes data on its own: it converts every credited deposit to GB. It reacts to deposits rather than to an emptying pool, so keep an eye on remaining GB as well.
4. 04On an unlimited plan, remember it uses separate credentials from your GB plan. If the plan period ended and auto-renew was off, the unlimited credentials stop working while your GB credentials keep going — the plan's status is shown in the dashboard.

If curl works but your tool does not, the tool's proxy settings are wrong. The two classic mistakes are the wrong scheme and the wrong line format.

• Scheme mismatch. http:// credentials pasted into a SOCKS5 field, or vice versa, fail even though the endpoint supports both protocols on the same port. See HTTP vs SOCKS5 for which to pick.
• Format mismatch. A tool expecting host:port:user:pass will silently mangle a user:pass@host:port line. The generator exports every common format — including http:// and socks5:// URLs — plus a custom template with {HOST} {PORT} {USER} {PASS} for anything unusual. Export in the exact format your tool documents rather than reformatting by hand.
• DNS handling. In tools that distinguish them, prefer socks5h:// over socks5:// so DNS resolves through the proxy instead of locally.

USER:PASS@<proxy-host>:80
<proxy-host>:80:USER:PASS
http://USER:PASS@<proxy-host>:80
socks5://USER:PASS@<proxy-host>:80

The dashboard's proxy checker tests your actual credentials against the live network and streams results as they come in: exit IP, country, latency, and a working / failed / timeout verdict per line, with a summary at the end. An optional country filter lets you verify a specific geo target. The limit is 50 checks per day, so spend them on diagnosis rather than bulk validation.

Read latency with residential expectations: real home connections are slower than datacenter proxies, and figures vary by country. A handful of failed lines in a large batch is peer churn; consistent timeouts across an entire country filter is worth reporting.

If the curl test fails, the checker fails, and you have data remaining, reach the team via the support tickets page in your dashboard. Include enough detail to skip a round trip:

• What changed right before the failure started (new tool, regenerated credentials, new network, geo suffix added).
• Timestamps with your timezone, and whether the failure is constant or intermittent.
• The exact error: the curl -v output with the password redacted, or the tool's error text verbatim.
• The username suffixes in use (-cc-, -s-, -ttl-, and so on) and whether an untargeted username behaves differently.
• Whether you are on pay-per-GB or unlimited credentials, and what the built-in checker reports.