How to Test Proxy Speed: Measuring Latency and Throughput

The numbers to measure

For scraping and social accounts, latency and TTFB usually matter more than throughput, since each request moves only tens to hundreds of kilobytes. For files and video, throughput is the number to watch.

Quick checks with a web tool

The fastest check is to paste the proxy into the proxy speed test or the proxy checker to see whether it works and responds quickly. These measure from the tool's server to the proxy, not from your machine, so they are good for comparing proxies and spotting a faulty IP, but they do not replace a measurement from the machine that runs your tools.

Detailed timing with curl

curl has a -w option that prints the timing of each phase. Run it from the machine or server that will use the proxy, against the site you will actually work with:

• curl -x http://user:pass@ip:port -o /dev/null -s -w 'connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total} speed=%{speed_download}' https://target-site/
• time_connect: time to connect to the proxy, which depends on the distance between you and the proxy.
• time_appconnect: when the TLS handshake with the target completes through the proxy tunnel.
• time_starttransfer: time to first byte, including the site's own processing time.
• speed_download: average download rate in bytes per second. To measure throughput, fetch a reasonably large file from a source you are allowed to use rather than a small HTML page.
• Run it 10 to 20 times, record the results and take the median. Run once without the proxy as a baseline.

Bulk measurement with Python

To compare many IPs, write a small script: for each proxy, send a few requests to the same URL, time them with time.perf_counter() or read r.elapsed.total_seconds() in requests, then compute statistics.median(). Use a separate requests.Session() per proxy to see both cases: the first request opens a new connection, later ones reuse it and run faster.

Set a timeout on every request and record failures separately; a fast IP that fails one time in five is not better than a slightly slower, stable one. Proxy configuration in code is covered in the Python requests proxy setup.

How location affects speed

Every proxied request travels two legs: from you to the proxy, then from the proxy to the site. Total latency is the sum of both plus the site's processing time. The same proxy can be very fast for someone nearby and slow for someone far away, and fast for a site hosted near it but slow for one on another continent.

• You are in Vietnam, using a Vietnam proxy for a Vietnamese site: both legs are short and latency is lowest.
• You are in Vietnam, using a US proxy for a US site: the first leg crosses an ocean so latency is noticeably higher, but the second leg is short. That is the unavoidable cost of a US IP.
• You are in Vietnam, using a US proxy for a Vietnamese site: the traffic crosses the ocean twice, the slowest case. Only do this if you truly need a US IP.
• Tools on a server: placing the server near the proxy shortens the first leg.
• For users in Vietnam, proxies in Japan, South Korea, Singapore or Hong Kong usually show lower latency than US or UK proxies, simply because they are closer.

Reading the results

• High but steady connect time: usually distance, not a fault. Pick a closer proxy if the task allows.
• Low connect time but high TTFB: the target is slow or throttling you; compare with a different site.
• Large swings between runs: check your own network (Wi-Fi, an active VPN, other traffic) before blaming the proxy.
• Throughput far below your connection: check concurrent connections and try a different download source.
• If you have ruled these out and the proxy is still unusually slow, read why is my proxy slow and open a ticket with your measurements.

Frequently asked questions