"Is this proxy fast?" actually contains three separate questions: how quickly does it respond (latency), how much data can it carry (bandwidth) and how reliable is it (success rate)? Once you learn to measure all three separately, choosing a proxy turns from guesswork into engineering.
Metric 1: Latency
The time it takes for the request to go out and the response to come back; measured in ms. The most practical measurement is to time a small request sent through the proxy:
curl --proxy ip:port -o /dev/null -s -w "%{time_total}s\n" https://api.ipify.orgRun this command 5-10 times and look at the average; a single measurement is misleading. Reference values: under 80 ms is excellent, up to 150 ms is good, over 250 ms is slow. For a deeper look at the concept, see our latency article ; for a ready-made measurement, the ping test tool and proxy checker is at your service.
Metric 2: Bandwidth
Download a reasonably large file through the proxy and measure the time:
curl --proxy ip:port -o /dev/null -s -w "%{speed_download} B/s\n" https://target/fileContext matters when interpreting the result: for text-heavy scraping even 5-10 Mbps is more than enough; for media downloading you want 50+ Mbps. Datacenter packages lead by a wide margin in bandwidth; residential speeds vary depending on the actual home connection — this is not a flaw, it is the nature of the type.
Metric 3: Success Rate
This is the most critical metric in production: what percentage of the requests you send return a valid response (2xx)? To measure it, send 100 requests to your target through the proxy; take the 2xx / total ratio. Above 95% is healthy, below 90% is a sign of trouble. A low rate is not always the proxy's fault: the target's protection, a wrong header set or an aggressive pace can also cause it.
Common Mistakes in Measurement
- Deciding on a single measurement: Networks fluctuate; take at least 5-10 samples for every metric.
- Testing against the wrong target: A measurement against a site that does not resemble your own target does not represent production.
- Not taking a baseline without the proxy: Measure your direct connection first; only then can you see the difference the proxy makes.
- A test not spread over time: Free addresses can be fast at the top of the hour and slow during the evening peak; spread your decision across the day.
Quickly Eliminating Free Addresses
In the the last measured latency of each address is shown with a colour code: take the green ones (under 80 ms) first, then run the three metrics above against your own targets. This two-minute screening saves you hours of struggling with slow addresses.