In early September 2026 we handed 1 GB of residential traffic to ProxyVero, an independent proxy benchmarking platform, and asked for nothing in return except that they publish what they found. They ran automated tests against six real targets for twelve days and put the results on a public page. This post is that page, read honestly — the good numbers, the mediocre ones, and the one band we plainly fail.
Why publish someone else's scorecard? Because provider-published benchmarks are worthless and everyone in this market knows it. A number we generate ourselves, on targets we choose, with a success rule we write, is marketing. The only proxy performance data worth reading is data the provider did not get to shape — which means being willing to show it when it is unflattering.
What we controlled, and what we didn't
Being precise about this matters more than the numbers themselves.
What we gave: 1 GB of residential traffic on a normal account, no expiry, no special routing, no separate IP pool. The same gateway every customer uses — gate.proxyhat.com:8080 — with the same AI IP filter in front of it. We also confirmed our public pricing for their review page.
What we did not get: any say in the targets, the schedule, the success rules, the wording, or the verdict. We saw the benchmark page when it went live, at the same time as everyone else. We asked for no changes, and none were made.
What you should know about them: ProxyVero runs affiliate links, and they disclose it on every page. Their methodology page states that affiliate relationships do not change how success, latency or traffic are measured. That is their claim, not ours to verify — but the numbers below are visibly not the numbers a vendor would buy.
The results: six scenarios, 745 requests, twelve days
Test period 2–13 September 2026, residential proxies only, last updated 13 September 18:00 UTC.
| Scenario | Success rate | Avg. latency | Requests | Block rate |
|---|---|---|---|---|
| Generic HTTPS (ipify) | 100.0% | 605 ms | 120 | 0.0% |
| TikTok (profile page) | 99.2% | 3030 ms | 125 | 0.0% |
| Nike (retail product page) | 97.6% | 1756 ms | 125 | 0.0% |
| Instagram (profile page) | 90.4% | 1145 ms | 125 | 8.0% |
| Google (SERP, US) | 88.8% | 587 ms | 125 | 11.2% |
| Amazon (product page) | 83.2% | 2455 ms | 125 | 16.0% |
Aggregate across all scenarios: 93.2% success, 1603 ms average latency, 3543 ms at the 95th percentile, 5.9% block rate.
Where we lose
Amazon is our worst target by a distance: 83.2% success, 16% block rate, 20 blocked requests out of 125. Google is second worst at 88.8% with 14 blocks. Instagram sits at 90.4% with 10.
Those three numbers are the honest shape of a residential network against hard commerce and search targets, and we would rather you read them here than discover them in your own logs three days into a project. If your workload is Amazon product pages at volume, plan for roughly one request in six to come back blocked on a rotating residential pool, and budget retries accordingly. Cost per successful request is the number that matters — not cost per GB, and not a headline success rate.
Note also what did not fail: timeouts were zero across every scenario, and the generic HTTPS endpoint returned 100%. Connectivity and authentication are not the problem. Anti-bot systems on specific targets are.
What a 16% block rate actually costs
Turn the success rate into attempts per success and the pricing conversation gets simple. At 83.2% you need 1 ÷ 0.832 = 1.20 attempts per successful Amazon page, so your effective cost per success is 20% above your cost per request. Google at 88.8% costs you 12.6% on top. Instagram at 90.4% costs 10.6%. The generic HTTPS endpoint at 100% costs nothing extra.
That is the number to carry into a provider comparison. A pool that is 15% cheaper per gigabyte but blocks twice as often on your target is more expensive, and no amount of pool-size marketing changes the arithmetic. Run the multiplication on your own targets before you commit to anyone — including us.
The headline number is the least useful one on the page
ProxyVero says this themselves, in a note directly under their own summary table: aggregate figures blend scenarios of very different difficulty, and their band thresholds are absolute reference bands rather than scenario-normalised grades. A provider tested mostly against easy endpoints will out-score one tested against Amazon and Google, without being better at anything you care about.
The comparison that makes this concrete: on the same scenario set, the neighbouring providers on their leaderboard score 93.1%, 93.1% and 93.3%. We score 93.2%. Four providers inside two-tenths of a percentage point is not a ranking — it is a measurement telling you that at this level the aggregate has stopped discriminating. Read the per-scenario rows instead.
The band we fail
Against ProxyVero's own reference bands, our results land like this:
| Metric | Our result | Their "good" band | Verdict |
|---|---|---|---|
| Success rate | 93.2% | > 95% | Fair |
| Avg. latency | 1603 ms | < 500 ms | Poor |
| P95 latency | 3543 ms | < 800 ms | Poor |
| Block rate | 5.9% | < 2% | Poor |
| Sample size | 745 | ≥ 1,000 | Fair |
We are not going to talk our way out of the latency row. Residential proxies route through real consumer connections, and end-to-end latency through a home line in Jakarta is not going to look like a datacenter round trip — the 3030 ms TikTok figure and the 587 ms Google figure in the same test are the same network on different targets. But a sub-500 ms band applied to residential traffic is a bar we do not clear, and pretending otherwise would defeat the point of publishing this at all. If your workload is latency-critical rather than detection-critical, static ISP proxies are the better product, and we would rather tell you that before you buy traffic.
The sample-size row is worth flagging too: 745 requests over twelve days is enough to see shape, not enough to settle small differences. Treat any gap under a couple of percentage points between providers on this data as noise.
What this test cannot tell you
One honest gap: we advertise an AI IP quality filter that scores routes before traffic is sent through them, and this benchmark cannot isolate its effect. There is no control group here — no parallel run with the filter disabled — so the results show what the network does with the filter on, and nothing about what it would do without. ProxyVero's review correctly labels the filter as provider-stated. If anyone tells you a single-provider benchmark validates a specific internal mechanism, they are overreading it.
The same caution applies to geography. All six scenarios ran against US-facing targets. Nothing on that page tells you how the network behaves from Brazil, Vietnam or Nigeria, and we would not claim otherwise.
How to read a benchmark page before you scale
Whatever provider you are evaluating, ours included, the same four checks apply:
- Find your target in the per-scenario table. If the scenarios tested are not the sites you actually hit, the aggregate tells you nothing about your workload.
- Check the sample size and the window. A 99% success rate over 40 requests is a rumour. Look for hundreds of requests across at least a week.
- Separate blocks from timeouts. Blocks mean anti-bot systems recognised the traffic; timeouts mean the network failed. They have completely different fixes, and only the second one is the provider's to solve alone.
- Convert to cost per successful request. A cheaper GB that blocks twice as often is more expensive. Multiply your price per GB by your expected retry rate on your targets before comparing anything.
The ProxyHat pages on ProxyVero are here: the benchmark for live measured data, the profile for what we offer, and the review for their read on pricing and fit. The benchmark page is the one that updates.
What we're doing with this
Amazon at 83.2% is the line we want to move, and moving it is a routing and IP-quality problem rather than a marketing one. The next benchmark window will say whether we managed it, and we do not get a vote in what it says. That is the entire value of the arrangement.
Test it yourself
An independent benchmark is a starting point, not a substitute for your own numbers. Point a few hundred requests at your real targets, count successes rather than responses, and compare cost per successful request across whatever providers you are considering. Pay-as-you-go traffic starts at $5, credits roll over, and nothing here requires a subscription to find out.
And if you run an independent testing platform and want to benchmark us: we will give you traffic, we will answer questions about the network, and we will not ask to see the results first.
