Proxy Not Working? A 10-Step Checklist

“My proxy is not working” describes four different problems. Either you cannot reach the proxy, or the proxy refuses you, or the proxy reaches the site and the site refuses it, or everything works and it is slow. Each layer has its own error strings and its own fix, and most wasted hours come from applying a layer-3 fix, like rotating user agents, to a layer-2 problem, like an IP allowlist. Find the layer first.

First, find the layer

The exact wording varies by tool, but every message belongs to one row of this table:

What you see	Layer	Meaning
curl: (7) Failed to connect to … port 7777, ERR_PROXY_CONNECTION_FAILED, ECONNREFUSED, ProxyError: Cannot connect to proxy	1	Nothing answered at that host and port
curl: (28) Connection timed out before any response, ETIMEDOUT on the proxy host	1	Packets are dropped on the way to the proxy: firewall, wrong network, IPv6 resolution
curl: (5) Could not resolve proxy, ENOTFOUND	1	DNS for the proxy hostname failed
407, curl: (56) CONNECT tunnel failed, response 407, ERR_TUNNEL_CONNECTION_FAILED, Tunnel connection failed	2	The proxy answered and refused your credentials or your IP
502 or 503 with the proxy's own server header, SOCKS5: general server failure	2	The proxy accepted you but could not get an exit: plan limits, no IP for that country, gateway trouble
403, 429, a CAPTCHA page, a 200 whose body has no data	3	The target saw the request and refused it
Works but 5 to 30 seconds per request, intermittent timeouts, “proxies taking so long”	4	Latency, tight timeouts, too much concurrency for the plan, or a slow exit

The one diagnostic to memorise: point the proxy at a URL that cannot refuse you. https://ipinfo.io/json returns your exit IP and has no anti-bot layer. If that works, layers 1, 2 and 4 are fine and your problem is the target. If it does not, the target is innocent.

curl -sS -w "\ncode=%{http_code} connect=%{time_connect}s tls=%{time_appconnect}s ttfb=%{time_starttransfer}s total=%{time_total}s\n" \
  -x pr.quanticdata.io:7777 -U "USER-country-us:PASS" https://ipinfo.io/json

Layer 1: you cannot reach the proxy

• Host or port typo. Copy the endpoint string from the dashboard rather than typing it. Do not add http:// to the -x value unless the tool asks for a URL; do add it in Python, where proxies values are URLs.
• Protocol mismatch. A SOCKS5 port opened with an HTTP client, or the reverse, produces a refused connection or an empty reply, not a clean error. Check which port is which; on QuanticData the SOCKS5 endpoints are generated separately from the HTTP ones.
• Egress rules. Cloud security groups and corporate firewalls commonly allow 80 and 443 only. A proxy on 7777 or 1080 needs an explicit outbound rule. A timeout with no response at all is the signature.
• IPv6 resolution. If the proxy hostname resolves to both A and AAAA records and your host prefers IPv6 on a network with broken IPv6, the connect hangs. Force IPv4 with curl -4 to confirm, then fix the resolver order.
• DNS. If the hostname does not resolve, try from another network. A container with no resolver configured is the usual culprit.

Layer 2: the proxy refuses you

A 407 is the loudest form and has its own guide: how to fix 407 Proxy Authentication Required. The short version is credentials not sent, credentials wrong, an unencoded @ in the password, or an IP allowlist that does not contain your current egress IP. Two quieter forms are worth knowing:

• Plan exhausted or expired. A plan with zero bandwidth left, or past its term, often behaves like bad credentials. Check the balance before anything else when something that worked yesterday stops today. If a local scrape suddenly fails from a development machine, the plan balance is more likely than TLS or an allowlist.
• No exit for the request. A 502 or 503 from the gateway itself, with a country or city flag in the username, means the pool had no available IP matching the flag at that moment. Widen the target, from city to country, or retry with a new session. If your plan is IP-authenticated and you want country targeting, generate the endpoint string via the proxies endpoint with the geo parameters rather than editing the username by hand.

Layer 3: the proxy works and the target refuses it

If ipinfo.io works and your target does not, the proxy is doing its job and the site is making a decision about the request. That decision is a 403, a 429, a CAPTCHA, or a 200 with a challenge or an empty shell where the data should be. Each has a guide, but three proxy-specific causes belong here:

• Wrong IP type for the target. A datacenter exit is labelled as hosting by every IP database, and commerce, travel and social sites treat that label as a signal. A refusal that disappears on a residential exit was never about your code.
• Geo mismatch. A site that serves a country-specific storefront or blocks regions returns 403 or a redirect for the wrong exit country. Match the country flag to the market you want to see.
• A burned exit. On a rotating pool one request may land on an IP another tenant has already exhausted. A single 429 on the first request is that; retry with a new session rather than backing off for a minute.

A recurring layer-3 trap is the 200 that is not data. Rendered-only pages return an HTML shell to a plain HTTP client, and challenge pages return 200 too. Check the body length and a known selector, not just the status. The SEO audit API shows exactly what a page looks like without JavaScript versus rendered, which tells you whether the empty body is a block or a rendering requirement.

Layer 4: it works, but it is slow or flaky

“Why are my proxies so slow” has a physical answer and a configuration answer. Physically, a residential exit is a home connection: expect 300 to 1,500 milliseconds to first byte on a good day, against under 200 milliseconds for a datacenter exit, and expect variance. Configuration is where the losses usually are:

• Timeouts set for direct connections. A 5-second timeout that was fine without a proxy now kills a third of your requests. Use 30 seconds for connect and read on residential, and count the timeouts before deciding the proxy is broken.
• Concurrency above what the plan or the exit tolerates. Two hundred parallel connections through one sticky session are two hundred connections through one home router. Spread sessions, or use rotating mode for stateless fetches.
• Sticky when you wanted rotating, or the reverse. Rotating mode pays a new TLS handshake and a new exit per request; sticky mode reuses the path. For one-shot page fetches rotate; for multi-step flows stick. The rotating proxy explainer covers the trade-off.
• DNS through the proxy. With HTTP proxies the proxy resolves the target; with SOCKS5 make sure the client sends the hostname (socks5h:// in Python) or you resolve locally, leak your resolver's location and sometimes get the wrong regional server.
• Retries without a budget. Three retries on every failure triple the load exactly when the exit is struggling. Retry once with a new session, then move on and record the URL.

The curl timing line above separates these. A high connect is layer 1 or a distant gateway; a high tls with a low connect is the CONNECT tunnel plus handshake through a slow exit; a high ttfb with everything else low is the target being slow, which no proxy fixes.

The 10-step checklist

1. Fetch https://ipinfo.io/json through the proxy with the curl timing line. Note the code and the four timings.
2. If it did not connect: check host, port, protocol, and egress firewall rules. Try curl -4.
3. If it connected and returned 407: run the 407 guide's five checks, starting with plan balance and allowlist.
4. If it returned 502 or 503 from the gateway: drop city and state flags, retry with a new session.
5. If it returned 200: read the exit IP and country. Wrong country means a flag typo or an unsupported target for the plan.
6. Now fetch the real target, same command. A 403, 429 or challenge is layer 3: switch to the relevant guide.
7. Got 200? Check the body length and one known selector before trusting it.
8. Slow? Compare the four timings against a datacenter exit or a direct fetch to see which segment is slow.
9. Flaky? Count timeouts versus errors over 100 requests; raise timeouts to 30 seconds and lower concurrency before blaming the pool.
10. Still stuck? Send the provider the timing line, the exit IP, the exact error string and the timestamp. Those five facts are what support needs, and they are what this checklist produced.