A fast proxy is more than a low average.

Start with the question behind the number.

Imagine two fictional providers. Atlas A completes most requests in 300 milliseconds, but one request in twenty takes several seconds. Atlas B usually takes 450 milliseconds and varies much less. Which is faster for your application? A background collection job and an interactive lookup may give different answers. These are invented examples, but the decision is real.

Before comparing numbers, write down what your application needs: a complete response within a deadline, sustained throughput, or a consistent session. That requirement determines which measurement deserves attention. A leaderboard cannot make that choice for you.

Read the distribution.

The median, or p50, describes the middle of the observed requests. A p95 describes the point at or below which roughly 95% of observations fall. Read them together: the distance between them helps show how much slower the tail is than the typical request.

Separate successful responses from failed ones. A fast error can make an overall average look better while the application gets less useful work done. Record timeouts separately, including the timeout threshold and whether retries are counted as new attempts. Google’s SRE guidance makes the same distinction between successful-request latency and error latency.

Keep the route visible.

Your client, the provider gateway, the proxy exit, and the destination are different places. A test from London to a small US endpoint is not interchangeable with a test from Singapore to a large page in Europe. Keep the runner location, requested exit location, and destination fixed when comparing a pair of providers.

Also record response size and connection reuse. A small endpoint mostly explores request overhead; a large download adds transfer time. Starting a new connection for every request can exercise a different path from a workload that reuses connections.

Make the experiment repeatable.

Use a fixed endpoint you own or have permission to test. Document the request count, concurrency, timeout, retry policy, and test window. Repeat across several periods instead of treating one quiet minute as a permanent property of the network.

curl exposes separate timing values for connection setup, time to first byte, and total duration. Those measurements can help explain where a request spends time, provided the proxy protocol and connection setup are recorded too. A useful test report lets another engineer reproduce the conditions.

Reading the ProxyAtlas preview.

The charts on this site use deterministic synthetic numbers. They demonstrate how a provider and regional view could be explored; they cannot identify a faster provider. Use the directory to discover services, then validate candidates against your own workload before making a decision.