Proxy slow or timing out? Measure each hop, read your speed test results, and fix the slow link with proven tweaks for residential and datacenter proxies.

Why is my proxy slow? How to measure and fix proxy latency

Your proxy connects and reports the correct IP, yet pages load slowly and your scraper keeps timing out.

When a proxy is slow, the cause is rarely one thing. Proxy latency is the sum of several hops: your machine to the proxy server, the proxy to the exit IP, the exit IP to the website, and the website's own response time. Any one of them can be the bottleneck. Fix the wrong one and nothing changes.

This guide shows you how to measure each hop, read the numbers, and fix the part that's actually slow. If you haven't run a basic check on your proxies yet, start with our guide on how to test proxies before you use them.

Where proxy latency comes from

Every proxied request travels a chain, and each link adds its own delay. Here's the path a typical request takes:

Hop	What happens	What slows it down
1. You → proxy server	Your client connects to the proxy	Distance to the proxy, a busy local network, a VPN in the path
2. Proxy → exit IP	The proxy routes your request to the IP that will send it	An overloaded proxy server, a weak or distant exit device
3. Exit IP → website	The exit IP connects to the site and fetches the page	Distance between the exit IP and the site's servers
4. Website response	The site builds and returns the page	Heavy pages, a slow server, or a site slowing down flagged IPs

Distance hurts more than it looks. Light in fiber needs about 5 milliseconds to cover 1,000 km (CommScope), so every 1,000 km adds roughly 10 ms to each round trip. Routers add more on top.

And one HTTPS request through a proxy makes several round trips before the first byte arrives. There's the TCP connection, the CONNECT request that opens the tunnel, the TLS handshake (one round trip with TLS 1.3, two with TLS 1.2), and then the request itself. A detour that costs 100 ms per round trip can add half a second to every new connection.

Is your residential proxy slow compared with a datacenter one? That's expected, to a point. A residential proxy sends your traffic through a real home connection, and home connections were never built to serve as servers:

Limited upload. The page travels back to the proxy over the home line's upload channel. Most cable and DSL plans upload at a fraction of their download speed.
Shared bandwidth. The household streams, games and downloads on the same line.
Unstable devices. Exit devices sit on Wi-Fi or mobile data and can drop offline mid-session.

Datacenter proxies run on servers with fast, symmetric links, so they win on raw speed. Residential IPs win on trust. The goal isn't to make a residential proxy as fast as a datacenter one. It's to find out whether yours is slower than it should be.

How to run a proxy speed test that actually tells you something

A single number tells you the proxy is slow. It doesn't tell you why. A useful proxy speed test sends the same request with and without the proxy, then splits each one into phases.

Start with a baseline. Request your real target directly, then through the proxy, 20 times each. This loop logs connect time, TLS time, time to first byte (TTFB) and total time for both:

URL="https://example.com"

PROXY="http://USER:PASS@HOST:PORT"

FMT='%{time_connect} %{time_appconnect} %{time_starttransfer} %{time_total}\n'

for i in $(seq 20); do

  curl -s -o /dev/null --max-time 30 -w "direct $FMT" "$URL"

  curl -s -o /dev/null --max-time 30 -x "$PROXY" -w "proxy  $FMT" "$URL"

done > results.txt

Then pull the median and the worst TTFB for each:

for label in direct proxy; do

  grep "^$label" results.txt | awk '{print $4}' | sort -n |

    awk -v l="$label" '{a[NR]=$1} END {print l, "TTFB median:", a[int((NR+1)/2)], "worst:", a[NR]}'

done

The gap between the two medians is your real proxy overhead. The worst result matters just as much. A proxy with a fine median and a 6-second worst case will still stall your scraper.

One detail to keep in mind: through a proxy, curl's connect time measures the connection to the proxy server, not to the website (curl docs). Everything after that, including the tunnel and the TLS handshake with the site, shows up in the later phases. Our proxy testing guide has the full timing command with every phase labeled.

To get numbers you can trust:

Test your real target. A proxy can be quick to a CDN and slow to the site you need.
Test one IP, then many. Run the loop on a sticky session to measure a single exit IP, then on a rotating endpoint to see how much IPs vary.
Test at different times. Residential pools are busier at some hours than others.

If you'd rather skip the terminal, CoreProxy's Speed Test and Proxy Benchmark tools give you a quick read. Online tools run from their own servers, though, so treat their numbers as a rough guide, not a match for your setup.

How to read your results

Each phase points to a different hop. Find the phase where the proxy run pulls away from the direct run, and you've found your slow link.

What you see	Likely cause	Where the problem sits
High connect time	The proxy server is far from you, or your own network is slow	You → proxy
Fast connect, big jump at the TLS phase	The exit IP is far from the website, or the exit device is slow	Proxy → exit IP → website
Fast TLS, slow first byte, but direct is fast	The site is slow to answer this IP, often because the IP is flagged	Website response
Slow first byte both direct and through the proxy	The website itself is slow	Not the proxy
Fast first byte, slow total time	Low throughput: a weak home connection or a heavy page	Exit IP or page size
Good median, terrible worst case	Some IPs in the pool are weak, or the line gets congested now and then	Individual exit IPs
Slow at certain hours only	Peak load on the proxy pool or the target	Timing

Two patterns cover most cases.

If the slowdown starts at the TLS phase, think geography. Your exit IP is probably far from the site's servers, and every round trip pays for it.

If the slowdown shows up in the worst cases, not the median, think individual IPs. A rotating pool will always contain some weak exit devices. One bad draw can turn a fast request into a timeout. If those requests fail outright with a 504, our guide on fixing proxy errors covers that error in detail.

How to fix a slow proxy

Match the fix to the hop you found. Most slow proxies speed up with one or two of these changes.

Move the exit IP closer to the target. This is the biggest win when the delay starts at the TLS phase. Pick a country or city near the site's servers, not near you. A German shop is best reached through German or nearby EU IPs. Not sure where a site is hosted? Look up its IP with our IP Location tool.

Reuse connections. Every new connection pays for the TCP, CONNECT and TLS round trips again. Keep connections open and send many requests through them. In Python, a requests Session pools connections for you. In Playwright or Puppeteer, keep one browser context per task instead of launching a new one per page.

Hold sticky sessions. Rotating on every request means a new exit IP, a new connection and a new chance of landing on a weak device. For multi-step tasks, keep one IP for the whole session. CoreProxy's Rotating Residential proxies support sticky sessions of up to 7 days.

Drop slow IPs fast. Set your timeout at a few times your median, not at 60 seconds. When a request crosses it, retry on a fresh IP instead of waiting it out. Cap your retries so one stubborn page can't stall the whole job.

Spread the load. A home connection can only carry so much. Hundreds of parallel requests through one sticky IP will saturate it. Spread concurrent requests across more IPs.

Send less data. Total time grows with page size, and on residential IPs the home line's upload speed sets the pace. Block images and fonts, and use the site's JSON endpoints where they exist. Our guide on cutting proxy costs covers this in detail, and the same changes save bandwidth too.

Use the right proxy type. If the site doesn't block datacenter traffic, Static Datacenter proxies are the fastest option. If you need residential trust with steadier speed, Static Residential (ISP) proxies keep one IP for as long as you need it, without a pool of home devices behind it.

When the slowdown isn't the proxy

Sometimes the proxy takes the blame for someone else's delay. Rule these out before you switch providers.

Your own network. If the direct run in your speed test is slow too, the problem is your line, not the proxy. Also check for a VPN running underneath. It sends every request to the VPN server first, which adds a full extra hop. Leftover proxy settings from old software can do the same.

The website is slowing you down. Anti-bot systems don't always block suspicious traffic. Some slow it down or add a challenge page instead. If the first byte is only slow on certain IPs, or CAPTCHAs start to appear, the IP's reputation is the likely cause. Check it with our guide on proxy IP reputation and blacklists, and see how to avoid Cloudflare blocks if the site uses it.

Your client is doing too much. A headless browser downloads scripts, images and fonts and runs JavaScript before a page counts as loaded. Run a plain curl request to the same URL through the same proxy. If curl is fast and the browser is slow, the proxy isn't your bottleneck. The page weight is.

A slow proxy is a measurement problem first. Time each phase, compare it against a direct baseline, and the slow hop usually shows itself. Fix that hop, then run the test again to confirm.

If your current pool can't keep up, CoreProxy offers residential, static residential, datacenter and mobile proxies in 195+ countries, so you can route through a location right next to your target. Get started with CoreProxy and run your first speed test today.