Why Are My Proxies Slow? 9-Point Troubleshooting Checklist

Your scraper was flying yesterday. Today every request crawls. Before you blame the proxy — or your provider blames your code — work through this 9-point checklist. Each point includes how to test it and how to fix it, with copy-paste commands. Most "slow proxy" problems resolve in the first three.

First: measure properly

Don't trust vibes. Establish a baseline without the proxy, then compare. Use curl's timing variables to split a request into stages so you can see exactly where time goes:

# Baseline: direct connection
curl -o /dev/null -s -w \
  "namelookup: %{time_namelookup}s | connect: %{time_connect}s | tls: %{time_appconnect}s | ttfb: %{time_starttransfer}s | total: %{time_total}s\n" \
  https://example.com

# Same request through the proxy
curl -x http://user:pass@proxy-host:port -o /dev/null -s -w \
  "namelookup: %{time_namelookup}s | connect: %{time_connect}s | tls: %{time_appconnect}s | ttfb: %{time_starttransfer}s | total: %{time_total}s\n" \
  https://example.com

Run each 5–10 times and take the median, not the first result (the first request pays for cold TCP/TLS/DNS setup). If the direct baseline is also slow, the proxy is innocent — the problem is your network or the target site. Only continue down this checklist if the proxy adds significant latency.

1. Overloaded shared pool

Symptom: Wildly varying response times — 400ms, then 6s, then 1s — on the same target. This is the single most common real cause: too many customers sharing too few exit IPs.

Test: Request the same lightweight URL 20 times through the proxy and look at the spread. High variance (not just high average) points at congestion or an oversubscribed pool.

for i in $(seq 1 20); do
  curl -x http://user:pass@proxy-host:port -o /dev/null -s \
    -w "%{time_total}\n" https://example.com
done

Fix: Switch to a different exit, a dedicated/static proxy, or a higher-quality pool. Budget pools that resell the same IPs to everyone are the usual culprit.

2. Geographic distance

Symptom: Consistently slow, low-variance latency. You're in Frankfurt, your target is in the US, and your exit IP is in Brazil — every request crosses three continents, twice.

Test: Check where your exit IP actually is (curl -x ... https://ipinfo.io), then compare round-trip times to exits in different regions.

Fix: Pin your exit region close to the target, not to yourself. For scraping, the proxy→target leg matters far more than the you→proxy leg. Most providers let you select country or city.

3. Concurrency set too high (or too low)

Symptom: Speed collapses as you add threads — or throughput is poor despite fine per-request latency.

Test: Benchmark at 1, 10, 50, and 200 concurrent connections and plot throughput. If throughput drops past a certain point, you're congesting the gateway, the exit peer, or tripping the target's rate limits (which then throttle you — see point 5).

Fix: Find the knee of the curve and stay under it. Too low leaves the pipe empty; too high creates a self-inflicted DDoS. Add polite delays and jitter between requests.

# Quick concurrency smoke test with curl 7.66+ parallel mode
seq 1 20 | xargs -P 10 -I{} \
  curl -x http://user:pass@proxy-host:port -o /dev/null -s \
  -w "%{time_total}\n" https://example.com

4. Target-site rate limiting / throttling

Symptom: The proxy is fast on other sites but slow on one specific target. The site may be tarpitting you — deliberately delaying responses — or serving slow 429-then-retry loops.

Test: Hit the same target directly (no proxy) at the same request rate. If it's also slow, the target is pacing you, not the proxy. Watch for Retry-After headers and 429 status codes.

Fix: Reduce request rate, rotate IPs more aggressively, respect Retry-After, and make sure your headers look like a real browser. This is target behavior, not a proxy defect — a faster proxy won't help.

5. Sticky session pinned to a slow peer

Symptom: One session is consistently slow while fresh sessions are fine — common with residential/mobile proxies where a sticky session parks you on one real device.

Test: Run requests with a fresh session ID each time vs. reusing one session. If fresh is fast and sticky is slow, you've got a bad peer.

Fix: Rotate the session (change the session parameter in your username, e.g. session_abc123 → session_xyz789) or shorten your sticky TTL. Reserve sticky sessions for logins and flows that need IP consistency; use rotating exits for bulk work.

6. DNS resolution overhead

Symptom: time_namelookup dominates in your timing breakdown, or the first request in a batch is slow and the rest are fine.

Test: Compare time_namelookup between direct and proxied requests. With HTTP proxies, DNS is usually resolved by the proxy — if the proxy's resolver is slow, every request pays for it.

Fix: Reuse connections (keep-alive) so DNS is resolved once per batch, and confirm your client isn't doing redundant local lookups. If the proxy's resolver is the bottleneck, try a different gateway.

7. Protocol choice: HTTP vs SOCKS5

Symptom: Modest but consistent overhead on every request.

Test: Benchmark the same workload over HTTP and SOCKS5:

curl -x http://user:pass@proxy-host:port -o /dev/null -s -w "http: %{time_total}\n" https://example.com
curl -x socks5://user:pass@proxy-host:port -o /dev/null -s -w "socks5: %{time_total}\n" https://example.com

Fix: SOCKS5 has less protocol overhead and handles non-HTTP traffic natively, so it's often slightly faster for raw scraping. But HTTP proxies can do connection reuse and caching tricks that win for browser-like workloads. Measure your workload — don't assume.

8. ISP throttling and time of day

Symptom: Speed degrades at predictable hours (evenings, business hours in the exit's region) and recovers overnight.

Test: Log latency over 24 hours. If the pattern follows the clock — especially the exit region's clock, not yours — it's congestion or throttling, not a broken proxy.

Fix: Schedule heavy batch jobs off-peak, distribute across regions/timezones, or move to dedicated bandwidth that isn't contended.

9. Faulty or flapping proxy rotation

Symptom: Intermittent failures mixed with slow successes — timeouts, connection resets, half the pool timing out.

Test: Test each proxy endpoint individually rather than the pool as a whole. One or two dead exits in a rotation pool will poison your averages and your retry logic.

# Test a single exit directly (replace with your endpoint)
curl -x http://user:pass@exit-1:port --connect-timeout 10 --max-time 30 \
  -o /dev/null -s -w "exit-1: %{http_code} in %{time_total}s\n" https://example.com

Fix: Remove dead exits from rotation, set sane --connect-timeout/--max-time values so one bad exit can't stall your whole pipeline, and implement circuit-breaking: temporarily drop exits that fail repeatedly.

Quick-reference summary

| # | Cause | Key symptom | Fix | |---|---|---|---| | 1 | Overloaded pool | High variance in timings | Better pool / dedicated proxy | | 2 | Geographic distance | Consistently slow, low variance | Exit near the target | | 3 | Concurrency mismatch | Throughput drops as threads rise | Tune concurrency, add delays | | 4 | Target throttling | Slow on one site only | Slow down, rotate, respect 429s | | 5 | Slow sticky peer | One session slow, fresh is fine | Rotate session / shorten TTL | | 6 | DNS overhead | time_namelookup dominates | Keep-alive, reuse connections | | 7 | Protocol overhead | Small constant penalty | Benchmark HTTP vs SOCKS5 | | 8 | Time-of-day congestion | Clock-pattern slowdowns | Schedule off-peak | | 9 | Dead exits in rotation | Timeouts mixed with successes | Health-check exits, circuit-break |

FAQ

1. What's a "good" proxy speed? For datacenter proxies, expect 100–500ms added latency on top of your baseline; residential exits typically add 0.5–2s because the traffic routes through real user devices. Consistency matters more than raw speed — stable 800ms beats jittery 200ms–5s.

2. Why is only the first request slow? Cold start: the first request pays for TCP handshake + TLS handshake + DNS (4–6 round trips). Subsequent requests on a reused keep-alive connection skip most of that. Send a warm-up request before batch jobs.

3. Does the proxy location or my location matter more? The proxy→target leg matters most. Your request travels you→proxy→target→proxy→you, but the long, repeated leg is proxy→target. Always place the exit near the target site.

4. Can a VPN-style "speed test" tell me if my proxy is fast? Only partially. Raw bandwidth tests (like speed.cloudflare.com through the proxy) measure throughput, but most scraping pain is latency and consistency. Test with your actual workload: curl -w "%{time_total}" against your real targets is more informative than any speedtest number.

Try it yourself

Before changing providers or rewriting your scraper, run the baseline-vs-proxy timing test above on your actual targets — the numbers will tell you which of the 9 causes you're dealing with. To benchmark a new proxy properly, use a proper test harness: IPStation's free proxy tester checks connectivity, exit IP, and response time in one place. If the diagnosis points at pool quality, compare IPStation's proxy plans.