Most proxy purchases start in a spreadsheet. Price per GB goes in one column, advertised IP pool size goes in another, and whichever provider wins on both gets the trial. Three weeks later the SERP scraper is collecting CAPTCHAs on a quarter of its requests, the marketplace crawler is timing out on product pages, and the "cheap" provider has quietly become the expensive one — because every retry burns bandwidth you already paid for.
This happens because the two numbers buyers lean on hardest are the two least predictive of how a pool actually behaves against a defended target. A proxy provider comparison built on pricing and pool size tells you almost nothing about whether requests will succeed on Amazon at 3pm on a Tuesday.
The alternative is measurement. Below is how to evaluate providers on the metrics that correlate with outcomes — proxy success rate, latency distribution, and block rate — how to read a real proxy benchmark without being misled by the headline figure, and how to run a trial that actually predicts production behaviour.
Why Price and Pool Size Are Weak Signals
Before the useful metrics, it's worth being precise about why the popular ones fail.
The IP pool number is unaudited and mostly irrelevant
"100M+ residential IPs" is a marketing figure. No independent body verifies it, definitions vary wildly between vendors, and the number counts IPs seen at some point across some window — not IPs available to you, in your target country, right now, that haven't already been flagged by the site you're scraping.
What matters is far narrower: how many usable, unflagged IPs the pool can present in the specific geography your workload needs, and how quickly it recycles them. A 5M-IP pool with clean, well-distributed ASNs and low reuse against a given target will outperform a 100M-IP pool that has been hammered against the same target by every other customer on the platform. Pool size is a ceiling, not a performance indicator.
Price per GB is not cost per successful request
Residential proxies bill on bandwidth, and failed requests consume bandwidth. A blocked request still downloads a CAPTCHA page, a 403 body, or a soft-ban interstitial — and your retry logic then pays for the same page again.
Run the arithmetic properly. A provider at $3/GB with a 95% success rate on your target costs roughly $3.16 per GB of usable data. A provider at $2.50/GB with a 75% success rate costs $3.33 — and that's before you count the engineering time spent on retry queues and the throughput you lose to backoff. Cost per successful request is the only pricing metric worth comparing, and you cannot calculate it without performance data.
The Metrics That Actually Predict Performance
Success rate, measured per target
Success rate is the single most useful number, with one critical condition: it has to be measured against the sites you actually hit. Aggregate success rate blends easy targets with hard ones, and the blend is dominated by whatever mix the tester chose.
A pool can return 100% on a lightly-defended e-commerce site and under 75% on Google SERPs in the same test run. Both numbers are real. The average of them describes no workload that anyone actually runs.
When you see a single headline percentage, treat it as a coarse sorting mechanism — useful for excluding providers below 85%, useless for choosing between two above 92%. The per-scenario breakdown is where the decision gets made.
Latency: the average lies, the percentile doesn't
Average latency is a comfortable number that hides the behaviour that hurts you. What determines whether your crawler holds throughput is the tail — P95 and P99 — because those are the requests sitting in your connection pool blocking workers while your timeout counts down.
A pool averaging 1,900ms with a P95 of 3,800ms behaves very differently from one averaging 1,900ms with a P95 of 12,000ms, even though the headline is identical. The first needs a 5-second timeout and modest concurrency. The second needs aggressive timeouts, a much larger worker pool, and will still waste capacity.
Ask for percentiles. If a provider only publishes averages, assume the tail is unflattering.
Block rate is a different failure than an error
This distinction is where most amateur benchmarks fall apart. A request can fail because the proxy couldn't connect (a network problem, the provider's fault), because it timed out (a routing or congestion problem), or because the target site recognised the IP as non-residential traffic and served a block page (an IP reputation problem).
Only the third tells you about pool quality against that target. If your benchmark bundles all three into "failed", you can't tell whether a provider has a weak network or a burned IP pool — and those call for completely different responses. A weak network might be fixed by choosing a nearer gateway region. A burned pool against your target cannot be fixed by configuration at all.
Sample size, window, and who ran the test
A 200-request test is a snapshot, not a measurement. Anti-bot systems adapt over days, residential pools rotate, and a single afternoon's results can be flattering or unlucky by pure chance.
Look for at least a few thousand requests spread across at least a week, and be sceptical of anything self-reported. Provider-published performance data is measured by the party with the strongest incentive for it to look good, using a methodology they don't have to disclose.
Reading a Real Benchmark: A Worked Example
Abstract advice is easy to nod along to, so here's an actual dataset. ProxyVero is an independent proxy benchmarking platform that runs automated, scheduled tests against live provider pools using the same targets and timeouts for everyone, and publishes both the results and the methodology. Their residential benchmark of EnigmaProxy is a useful teaching case because the headline number and the underlying data tell noticeably different stories.
The summary figures, from a 15-day window ending 9 September 2026 across 925 requests and six real-world scenarios:
- Overall success rate: 93.0%
- Average latency: 1,898 ms
- P95 latency: 3,811 ms
- Block rate: 5.4%
Taken alone, 93% looks like a solid mid-to-upper-tier result and tells you very little. The per-scenario data is where the useful signal is:
- Nike (e-commerce): 100.0% success, 2,495 ms average latency, 0% blocked
- TikTok (social): 100.0% success, 1,190 ms, 0% blocked
- Instagram (social): 99.3% success, 2,772 ms, 0% blocked
- Generic HTTPS endpoint: 99.3% success, 724 ms, 0% blocked
- Amazon (e-commerce): 87.1% success, 3,204 ms, 5.2% blocked
- Google (SERP): 72.3% success, 834 ms, 27.1% blocked
Three things worth extracting from this, all of which generalise well beyond one provider.
The spread is the story, not the average. The same pool ranges from flawless to struggling depending entirely on the target. If your workload is social media data collection or standard e-commerce product pages, the relevant numbers here are the 99–100% ones. If your workload is SERP scraping at volume, the relevant number is 72.3% — and the 93% aggregate would have badly oversold your expected results. Two teams could read this identical page and correctly reach opposite conclusions.
Low latency can be a symptom of failure, not speed. Google shows the fastest response times of any hard target in the set at 834ms, and simultaneously the worst success rate. That isn't a coincidence, and it's the most commonly misread pattern in proxy performance data. Block pages are cheap to serve: a CAPTCHA interstitial returns almost instantly, while a genuine SERP requires the target to actually assemble and send a full page. When a scenario shows suspiciously fast responses alongside a high block rate, the pool is being rejected quickly, not performing well. Latency is only meaningful when read next to success rate.
Latency variation across targets is mostly the target, not the proxy. The same pool averages 1,190ms on one social platform and 2,772ms on another, and 724ms on a trivial JSON endpoint. Page weight, TLS negotiation, redirect chains, and origin infrastructure all contribute. This is precisely why cross-provider comparisons are only valid when every provider is measured against the identical target — which is the core of any credible benchmarking methodology.
One honest caveat on the dataset itself: 925 requests across six scenarios is roughly 155 per scenario, which is enough to establish a clear direction but not enough for tight confidence intervals on a single scenario. ProxyVero flags the sample-size band on the page rather than hiding it, and notes in their methodology that aggregate figures blend scenarios of very different difficulty. That kind of disclosure is itself an evaluation signal — a benchmark that publishes its own limitations is more trustworthy than one that doesn't.
Running Your Own Trial
Third-party benchmarks narrow the field. Your own testing picks the winner, because no public dataset covers your exact targets, geographies, and concurrency profile.
A trial that produces a real decision looks like this:
Test your actual targets. Not a generic IP-echo endpoint. Point the trial at the specific domains and page types your production job hits. Success against api.ipify.org proves connectivity and nothing else.
Test your actual geography. A pool that's strong in the US may be thin in Brazil or Vietnam. Country-level and city-level performance diverge sharply, and the advertised country list says nothing about depth.
Run for at least seven days. Anti-bot systems learn. A pool that performs beautifully on day one and degrades by day five is telling you something important about IP reuse that a 24-hour test cannot surface.
Test at production concurrency. Ten sequential requests will succeed almost anywhere. Two hundred concurrent sessions is where gateway capacity, connection limits, and pool depth reveal themselves.
Log failures by category. Separate timeouts, connection errors, non-200 responses, and block pages. The category distribution tells you what to fix and whether the fix is even available to you.
Measure sticky session integrity. If your workflow needs the same IP for a multi-step sequence — login, navigation, checkout — verify that sessions actually hold for the advertised duration under load, rather than silently rotating mid-flow.
Calculate cost per successful request at the end. Not price per GB. Bandwidth consumed divided by successful responses, multiplied by rate.
Common Mistakes That Distort Evaluations
Testing a trial pool instead of a production pool. Some providers route trial traffic through cleaner subnets. Where possible, test on a small paid plan rather than a free trial, and ask directly whether trial and production traffic share infrastructure.
Confusing your own configuration errors for provider failures. Missing or inconsistent headers, an obvious TLS fingerprint, and unrealistic request timing will get you blocked on any pool. Before concluding a provider is weak, confirm your client behaves like a browser. A large share of "the proxies don't work" tickets are fingerprinting problems wearing a proxy costume.
Reading a leaderboard position as a verdict. Rankings compress multi-dimensional performance into one ordinal. A provider ranked fourth overall may be first on the two scenarios you care about.
Ignoring sourcing and compliance. How residential IPs were obtained is a legal and reputational question, not a technical footnote. Pools built on undisclosed SDK bundling carry real exposure. Ask how consent is obtained and whether it's documented — a provider that can't answer clearly has told you the answer.
Optimising for the headline metric and forgetting operations. Support responsiveness, API quality, billing transparency, and whether unused bandwidth expires will affect your month far more than a two-point difference in success rate.
Where Proxies Fit In
Everything above assumes the underlying constraint: at any meaningful scale, data collection, ad verification, price monitoring, and SERP tracking all depend on requests originating from IP addresses that look like ordinary users in the right places. The evaluation framework exists because that dependency is unavoidable and the quality of it varies enormously.
The practical implication is that pool diversity often matters more than pool size. Different workloads have genuinely different optimal answers: SERP scraping and social platforms need residential IPs with careful rotation; high-volume, low-defence crawling runs far more economically on datacenter; account-based workflows need ISP addresses with stable, long-lived sessions. Running everything through one pool type means overpaying for the easy jobs and underperforming on the hard ones.
EnigmaProxy is built around that split, offering residential, ISP, datacenter, mobile and IPv6 pools under a single account with sticky session control and geo-targeting, so workloads can be matched to the right pool type rather than forced through one. Sourcing is documented, pricing is structured to be predictable across tiers, and the customer API handles package lookup and proxy generation programmatically — which matters more than it sounds when you're rotating credentials across a dozen scheduled jobs.
It's also why submitting to independent benchmarking is worth doing as a provider. Published third-party results, including the unflattering scenarios, give buyers something to evaluate that isn't a marketing claim — and the buyers worth having are the ones who check.
Where This Is Heading
Evaluation is professionalising. Buying decisions that were made on a pricing page three years ago are increasingly made on benchmark data, trial results, and cost-per-successful-request models. Independent platforms publishing standardised, repeatable tests are accelerating that shift, and providers unwilling to be measured will find it harder to compete for technical buyers.
Detection is moving beyond IP reputation. TLS fingerprinting, behavioural analysis, and browser attestation increasingly determine whether a request succeeds. IP quality remains necessary but is no longer sufficient — expect evaluation criteria to expand toward how well a provider's infrastructure supports realistic client fingerprints, not just clean addresses.
Compliance is becoming a purchasing filter. Regulatory attention on how residential IP pools are sourced continues to sharpen. Documented consent and transparent sourcing are moving from differentiator to baseline requirement, particularly for enterprise buyers with procurement review.
Pricing models are diversifying. Pure per-GB billing punishes exactly the workloads that are hardest to run. Time-based unlimited plans, request-based pricing, and hybrid models are spreading, and evaluating a provider increasingly means evaluating which billing structure fits your traffic shape.
Conclusion
Proxy evaluation done properly is not complicated, but it is specific. Price per GB and advertised pool size are the easiest numbers to compare and the least connected to whether your job finishes. Success rate against your real targets, latency read as a distribution rather than an average, block rate separated from network errors, and cost per successful request are what predict outcomes.
Use independent benchmarks to shortlist and to sanity-check vendor claims — reading them properly means going past the headline percentage into the per-scenario spread, and treating fast responses alongside high block rates as the warning sign they are. Then run your own trial against your own targets, at production concurrency, for long enough that the results mean something.
When the shortlist is built, the useful question stops being which provider is cheapest and becomes which provider's pool composition matches the work you're doing. For teams that need several pool types under one roof with predictable pricing and documented sourcing, EnigmaProxy is worth evaluating on exactly the terms described above — measured, against your own workload.