"Fast" is not one number. A proxy has a connection time, a time to first byte, a throughput and a success rate, and they fail independently — the quickest proxy in a single test can be the worst one to build on. Here is how to measure each, and how to avoid measuring noise.
Every useful proxy measurement is one of three things, and confusing them is why people argue about proxy speed without agreeing on anything.
Latency is how long it takes before anything happens: establishing the TCP connection to the gateway, completing the TLS handshake, and waiting for the target to send its first byte. This is what you feel when a page seems sluggish, and it is what dominates any workload made of many small requests. A scraper fetching ten thousand product pages lives or dies on latency; bandwidth barely enters into it.
Throughput is how many megabytes per second flow once data is moving. It only matters when you transfer something sizeable — files, images, video, large API payloads. For a page of HTML it is irrelevant, because the transfer is over before the connection ever reaches full speed.
Success rate is the share of requests that return what you asked for rather than a timeout, a reset, a captcha or a block page. For most real work this is the number that decides whether a proxy is usable, and it is the one people forget to measure. A proxy that answers in 400 ms but fails one request in five is worse than one that takes 1.2 seconds and never fails, because every failure costs a retry — which costs more time than the slower proxy would have taken, and more traffic as well.
curl can report its own internal timings, which is the cleanest way to see where the time goes. The
-w flag takes a format string of variables filled in after the transfer:
curl -o /dev/null -s \
-x http://USERNAME-country-us:PASSWORD@gw.pyproxy.com:1111 \
-w "dns: %{time_namelookup}s\nconnect: %{time_connect}s\nappconn: %{time_appconnect}s\nttfb: %{time_starttransfer}s\ntotal: %{time_total}s\ncode: %{http_code}\nsize: %{size_download} bytes\nspeed: %{speed_download} B/s\n" \
https://httpbin.org/ip
On Windows PowerShell put the format string in double quotes on a single line, or use
curl.exe from a Git Bash shell to keep the backslashes working.
Every timer is cumulative from the start of the request, so you read the gaps between them, not the values alone:
time_namelookup — resolving the gateway hostname locally. Should be near zero after the
first call; if it is not, your DNS is the problem, not the proxy.time_connect — TCP connection to the proxy established. Subtract namelookup and you
have the raw network round trip to the gateway. This is the purest measure of how far away the proxy
is.time_appconnect — TLS handshake complete through the proxy tunnel. The gap between
connect and appconnect includes the round trips to the target's TLS, so it reflects the whole path, not
just the first hop.time_starttransfer — the first byte of the response arrived. The gap between appconnect
and starttransfer is the target's own thinking time plus the return leg. If this gap is large, the site
is slow, not the proxy.time_total — everything, including receiving the body.That breakdown answers the question people actually have. If time_connect is small and
time_starttransfer is large, the proxy is doing its job and the target is slow. If
time_connect itself is large, the route to the exit is the bottleneck and picking a closer
country will help.
You cannot measure bandwidth on a 2 KB response. TCP starts slowly and ramps up, so a small transfer
measures the ramp rather than the ceiling. Use a file of at least a few megabytes and read
speed_download, which curl reports in bytes per second:
curl -o /dev/null -s \
-x http://USERNAME-country-us:PASSWORD@gw.pyproxy.com:1111 \
-w "downloaded %{size_download} bytes in %{time_total}s = %{speed_download} B/s\n" \
https://example.com/some-large-file.bin
Two rules for making the result mean anything. Pick a file hosted where your real traffic goes, not
on a CDN edge chosen for being fast — a nearby CDN measures the CDN. And cap the test with
--max-time so a stalled transfer does not run away with your traffic allowance, since on
per-gigabyte billing every test byte is a byte you paid for.
Be realistic about what to expect from residential traffic. The exit is somebody's home connection, with that connection's upload limit, its congestion and its Wi-Fi. It is not a datacentre link and it will not behave like one. That is the trade: residential addresses look like real users precisely because they are real connections, and real connections are slower and more variable than servers. If raw throughput is your priority and the address does not need to look residential, datacentre or ISP proxies are the right tool.
One request tells you nothing about reliability. Run a series and count outcomes. This loop does fifty requests and prints a status code and total time for each:
for i in $(seq 1 50); do
curl -o /dev/null -s --max-time 20 \
-x http://USERNAME-country-us:PASSWORD@gw.pyproxy.com:1111 \
-w "%{http_code} %{time_total}\n" \
https://your-real-target.example/page
done | tee results.txt
# how many of each status code
awk '{print $1}' results.txt | sort | uniq -c
# median total time
awk '{print $2}' results.txt | sort -n | awk '{a[NR]=$1} END{print a[int(NR/2)+1]}'
Read the median, not the average. One 20-second timeout drags an average upward and hides the fact that forty-nine requests were quick. Then look at the slowest few — the 90th or 95th percentile is what your users or your job will actually experience under load, and it is where proxies differ most.
Count a 000 from curl as a failure; that is a connection that never produced a status.
Count a 403 or a captcha page as a failure too, even though it returned 200 — it did not give you what
you asked for. Success rate means useful responses, not responses.
This is the part that trips up almost every proxy comparison. On a rotating residential gateway you are not connecting to one server. You send each request to the same endpoint, and the gateway sends it out through a different address on a different home connection each time. Two consecutive tests can measure two entirely different networks on two different continents.
So a single number is not a slow proxy or a fast proxy — it is one sample from a wide distribution. If you run the test once and get 2.4 seconds, run it again and get 0.6, neither is "the speed". Prove it to yourself by watching the exit change:
for i in 1 2 3 4 5; do curl -s -x http://USERNAME-country-us:PASSWORD@gw.pyproxy.com:1111 https://httpbin.org/ip done
Five different addresses is the pool working correctly, not a fault. The only honest way to describe a rotating pool's performance is a distribution: median, 95th percentile and failure rate over enough requests to be stable. Fifty is a reasonable minimum, and more is better.
When you need repeatable numbers — comparing two countries, checking whether a route degrades over time, or debugging something that only happens on one connection — you have to stop the rotation. Add a session token to the username and the gateway holds a single exit address for about thirty minutes, so every request in your test series goes through the same path.
With that in place the whole toolkit above becomes meaningful in the ordinary way: repeated runs measure one route, differences between runs are real changes rather than a different exit, and a throughput test actually describes the connection you measured. Just remember that the session is temporary. If a test series runs past the session lifetime, the later requests are on a new address and your data quietly becomes two datasets stapled together. Keep test runs comfortably inside the window, or start a fresh session for each run and record which is which.
The complementary test is the opposite: deliberately sample many exits, one request each, to characterise the pool as a whole. Both are valid. What is not valid is mixing them and calling the result a measurement.
Consumer speed-test sites are built to measure a home broadband line, and every design decision in them is wrong for proxies. They pick the server geographically closest to the address they see, open many parallel streams to saturate a link, and report the peak. Through a proxy that produces a number which describes the exit node's connection to a test server neither of you cares about.
The specific problems: the result depends entirely on which exit you happened to get, so it is unrepeatable on a rotating pool. Many of those sites use WebSockets or protocols that behave oddly through an HTTP proxy, so you may measure the proxy's handling of an unusual transport rather than its speed. They burn a surprising amount of paid traffic — a full speed test can consume hundreds of megabytes. And they say nothing at all about the number that matters most, whether your target accepts the request.
Test your own target instead. Take the exact URL your application will request, run the curl timing command against it through the proxy, run the same series enough times to get a distribution, and record median, 95th percentile and success rate. Then run the identical series without the proxy to get your baseline, and compare. The difference between those two is the honest cost of the proxy, expressed in the only terms that matter to your work.
That is also the only fair way to compare providers. Same target, same time of day, same number of requests, same concurrency. A test costs cents on per-gigabyte billing, which is why running it yourself beats trusting anybody's published figures — including ours.
Three. Connection time, which is how long it takes to establish the tunnel; time to first byte, which is how long the target takes to start answering through it; and success rate across many requests. For most work the success rate matters more than either speed figure.
On a rotating residential pool each request may leave through a different address on a different home connection, so consecutive tests measure different networks entirely. A single measurement tells you about one exit, not about the service.
No. Those sites measure parallel streams to a nearby server chosen for the best possible result, which is nothing like a proxied request to your target. Measure against the site you actually intend to use instead.
Use a session token in the username so the same exit address is held for about thirty minutes, then run your whole test series through it. That gives you repeatable numbers for one route rather than a mix of many.