Without a proxy, a request goes from you to the site. With one, it goes from you to the proxy, from the proxy to the site, and back the same way. Each leg adds round trips, and HTTPS adds more: the CONNECT exchange, then the TLS handshake through the tunnel. On a residential network there is often a further leg, from the provider's gateway to a consumer device and its home connection.
How to measure it
curl breaks a request into phases:
curl -s -o /dev/null -x http://USERNAME:PASSWORD@HOST:PORT \
-w 'proxy connect %{time_connect}s tunnel+TLS %{time_appconnect}s first byte %{time_starttransfer}s total %{time_total}s\n' \
"https://api.ipify.org?format=json"
Through a proxy, time_connect is the time to reach the proxy, time_appconnect adds the tunnel and the TLS handshake with the site, and time_starttransfer adds the site's own response time. Run it the same way without -x to see what the proxy costs you.
Read it properly
One request tells you almost nothing. Run a few dozen, report the median and the 95th percentile, and test from the region your scraper will run in, against the target you care about. A proxy that is quick to an echo service can be slow to a distant site. How to test a proxy provider has a script for exactly this.
Common confusion
- Ping is not proxy latency. An ICMP ping to the proxy measures one leg, and many proxies do not answer pings at all.
- Latency is not bandwidth. A fast link can still have slow round trips. For scraping many small pages, latency and concurrency decide throughput far more than bandwidth does.