Last month we published our first monthly proxy benchmark: 50 providers, six real-world targets. The September 2026 edition is out, and the test cohort is much larger: 80 residential proxy providers and 115,192 requests, all sent through the same scenarios, timeouts and classification rules.
Here is what the data shows, plus a short pandas script so you can check every number yourself.
September at a glance
| Metric | September 2026 | vs August |
|---|---|---|
| Providers tested | 80 | +31 new, 6 exited |
| Total requests | 115,192 | +131.1% |
| Avg success rate | 87.4% | +6.9 pp |
| Avg latency | 1.36s | +0.06s |
| Overall block rate | 10.0% | −6.4 pp |
One caveat before reading anything into the month-over-month column: 31 providers joined the test cohort in September. The August and September cohorts are not the same set of providers, so these deltas are not a like-for-like comparison.
1. Target difficulty matters more than which provider you pick
Same providers, same rules, six targets:
| Scenario | Requests | Success rate | Avg latency | P95 latency | Block rate |
|---|---|---|---|---|---|
| ipify (generic HTTPS) | 19,191 | 98.1% | 0.61s | 1.97s | 0.0% |
| Nike | 19,271 | 97.9% | 1.99s | 4.17s | 0.0% |
| 19,421 | 96.7% | 1.28s | 3.20s | 0.5% | |
| TikTok | 18,451 | 95.9% | 1.13s | 2.70s | 0.1% |
| 19,436 | 76.4% | 0.80s | 1.24s | 21.9% | |
| Amazon | 19,422 | 60.1% | 2.78s | 4.81s | 37.1% |
That is a 38-percentage-point spread between the easiest and the hardest target. Any benchmark that only measures a generic HTTPS endpoint will report something close to 98% for nearly everyone, and that number tells you very little about Amazon or Google.
If your workload hits high-friction targets, treat the generic connectivity number as a smoke test, not a performance metric.
2. On hard targets, failures are blocks, not timeouts
A reader on our August post made a good point: rate limits and timeouts need different fixes. A 429 usually means you should back off, not buy more capacity or retry harder.
So we split the failures in the September dataset:
| Scenario | Success | Block rate | Timeout rate |
|---|---|---|---|
| Amazon | 60.1% | 37.1% | 0.2% |
| 76.4% | 21.9% | 0.1% | |
| 96.7% | 0.5% | 0.1% |
On Amazon and Google, almost every failed request was a block-like response, not a network problem. The proxies connected fine; the target refused them.
For your retry logic, that means:
- Retrying the same request through the same pool rarely helps. The failure is about how the request looks to the target, not about the connection.
- Look at fingerprinting, headers, session behavior and request rate before blaming the proxy network.
- Timeouts and blocks should be separate metrics in your monitoring. A pipeline whose success rate drops because of blocks needs a different fix from one that drops because of timeouts.
3. The Top 10 are separated by just 3.3 percentage points
Ranking rule: weighted success rate across all six scenarios, with average latency as the tie-breaker. Only providers with at least 1,500 requests in the month are eligible (more on that below).
| Rank | Provider | Requests | Success | Avg latency | P95 latency | Block rate |
|---|---|---|---|---|---|---|
| 1 | Evomi | 1,791 | 94.0% | 1.02s | 1.85s | 5.9% |
| 2 | EnigmaProxy | 1,791 | 93.8% | 1.78s | 3.69s | 5.9% |
| 3 | 1024Proxy | 1,799 | 93.2% | 1.70s | 3.97s | 4.3% |
| 4 | Databay | 1,790 | 93.2% | 1.14s | 2.23s | 6.5% |
| 5 | SpyderProxy | 1,770 | 91.8% | 1.03s | 2.23s | 7.7% |
| 6 | FleetProxy | 1,791 | 91.2% | 1.11s | 2.55s | 8.4% |
| 7 | Anonymous Proxies | 1,792 | 90.9% | 1.32s | 2.49s | 8.9% |
| 8 | SerpProxies | 1,555 | 90.9% | 2.08s | 4.30s | 9.0% |
| 9 | ProxyHat | 1,755 | 90.7% | 1.35s | 3.54s | 8.4% |
| 10 | Aceproxies | 1,790 | 90.7% | 1.05s | 1.92s | 9.3% |
With a 3.3 pp gap between #1 and #10, the headline success rate stops being the deciding factor. Look at the other columns instead:
- Latency varies a lot more than success does. EnigmaProxy is #2 on success, but its average latency is 1.78s against Evomi's 1.02s, and its P95 is twice as high.
- Tail latency matters for concurrency planning. SerpProxies holds 90.9% success, but with a 4.30s P95. If you run many concurrent workers with tight timeouts, plan for the P95, not the average.
4. The overall #1 is not the hard-target #1
If you only care about Amazon and Google, the ranking changes. Combining just those two scenarios (providers with at least 500 requests on them):
| Provider | Amazon + Google requests | Success |
|---|---|---|
| 1024Proxy | 607 | 83.2% |
| Evomi | 601 | 82.5% |
| Databay | 600 | 82.0% |
| EnigmaProxy | 601 | 81.9% |
| SquidProxies | 581 | 77.5% |
1024Proxy is #3 overall but #1 on the two hardest targets. The top four are still within about 1.3 percentage points of each other, so treat this as a shortlist rather than a winner. The broader point stands, though: pick providers on the targets you actually scrape, not on the overall average.
5. Methodology change: why we raised the ranking threshold to 1,500 requests
In August, the Top 10 required at least 200 requests. That turned out to be too low. Providers that had only just joined the benchmark could top the table with a few days of near-perfect results, before they had seen a bad day. We call this the honeymoon effect.
From September, Top 10 eligibility requires at least 1,500 requests in the month, which takes most of a month of daily testing. As a result:
- 50 providers qualified for the ranking this month.
- 4 providers cleared 95% success with fewer than 1,500 requests. They are still in the full dataset and the distribution charts, but they are kept out of the Top 10.
Earlier editions keep the rule they were published under.
6. Outages are real, and we keep them in the data
We log an endpoint incident when a provider has a full day with zero successful requests across every live scenario. September had seven:
| Provider | Date | Main failure | Success impact |
|---|---|---|---|
| NovaProxy | Sep 1 – Sep 2 | Connection errors | −5.3 pp |
| SquidProxies | Sep 5 | Timeouts | −3.3 pp |
| Proxy4U | Sep 8 | Connection errors | −2.9 pp |
| Packetstream | Sep 9 | Connection errors | −2.9 pp |
| CatProxies | Sep 13 | Connection errors | −3.0 pp |
| SotaProxy | Sep 23 | Connection errors | −8.6 pp |
| Geonode | Sep 24 | Connection errors | −2.9 pp |
Six of the seven were connection errors. That data stays in the rankings, because it reflects real service availability. If your pipeline depends on a single provider, a one-day full outage is something to plan for.
Six providers also exited testing during the month (Astro, Cliproxy, IpnProxy, Kookeey, Live Proxies and Omegaproxy), either because their endpoints stopped responding or because testing access ended. Their data from before the exit date stays in the cohort totals. Data from the exit date onward is excluded, and exited providers are not ranked.
7. Biggest movers
Among providers with enough samples in both months to compare fairly:
- Improvers: Aceproxies (+13.0 pp), Dataimpulse (+11.9 pp), Kindproxy (+11.7 pp)
- Decliners: NovaProxy (−11.8 pp, including a two-day incident), 711Proxy (−9.1 pp)
Reproduce it yourself
The full September dataset is public as CSV and JSON: one row per provider and scenario, with request counts, success rate, average and P95 latency, block rate and timeout rate.
This script rebuilds the scenario table and the block-vs-timeout split above:
import pandas as pd
url = "https://www.proxyvero.com/reports/2026-09/data.csv"
df = pd.read_csv(url)
# Rates are percentages per provider × scenario, so weight them by request count.
for col, rate in (("ok", "success_rate"), ("blocked", "block_rate"), ("timeouts", "timeout_rate")):
df[col] = df["requests"] * df[rate] / 100
by_scenario = df.groupby("scenario")[["requests", "ok", "blocked", "timeouts"]].sum()
for col in ("ok", "blocked", "timeouts"):
by_scenario[col + "_%"] = (100 * by_scenario[col] / by_scenario["requests"]).round(1)
print(by_scenario.sort_values("ok_%", ascending=False))
Change the groupby to "provider", or filter scenario_slug to the targets you care about, and you have your own ranking for your own workload.
Full report and methodology
- Full September 2026 report: proxyvero.com/reports/2026-09
- How we test: proxyvero.com/how-we-test
- Live leaderboard: proxyvero.com/benchmarks
The October 2026 report will be published in early November.
Which targets or metrics should we add next? Tell us in the comments. Last month's feedback is why the block-versus-timeout split is in this post.
Top comments (1)
Nice that you split blocks from timeouts. Two things that moved my own numbers a lot when we benchmarked Amazon and Google:
Also worth recording the client machine: the same code and gateway got very different Google results from a Windows box and a Linux VPS 🙃