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 (5)
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 🙃
Thanks, these are really useful, and two of them map directly onto how we run things today.
Hour of day / interleaving. Fair hit. Right now each daily run goes scenario by scenario, and within a scenario providers run back to back in a fixed order, so the same providers always hit Amazon earlier in the window than others. Your point is exactly why that matters: the order can show up as a provider effect. We're looking at interleaving providers request by request inside the window and shuffling the order each day. It's also a good reminder that a single daily window describes that window, not a 24-hour average. We should say that more clearly in the methodology.
Amazon's 200-status throttle page. Agreed, status alone undercounts it badly. We already classify by page content. A 200 response with the captcha / "continue shopping" interstitial counts as a block, alongside 403/429/503. If you've seen 200-status variants beyond those, I'd love to know which markers you used. Amazon has a few interstitials and I'd rather not miss one.
Client machine. Every probe runs from the same Linux server with the same code for every provider, so the client is constant across providers. But you're right that absolute numbers are tied to that environment, especially on Google. We haven't published the client details yet, and adding them to the methodology is a good call.
Curious about the Windows vs Linux gap on Google. Did it look like TLS/HTTP fingerprint differences, or something at the network level?
Thanks :) For Amazon we also match ref=cs_503 (the "Something went wrong" page, about 1 in 8 came with a 200), Akamai's /_sec/verify / bm-verify and AWS WAF's gokuProps. And we only count a success when the results are actually on the page.
The Windows vs Linux gap was with real browsers, not plain HTTP, and it looked like the browser, not the network. A Linux container on another connection didn't reproduce it though, so I don't have a clear answer yet.
Curious about Google: do you require actual results on the page to count a success? In our runs, clients without JS got a 200 with no results, just a page asking to enable JavaScript.
Thanks, Alexandr, this is really useful.
On Amazon: we already catch the captcha and "continue shopping" interstitials, but not ref=cs_503 or the Akamai / AWS WAF markers you mentioned. They're now in our detection, in logging-only mode for a few days so we can see how often they show up before they affect any public numbers.
On Google: partly. We first look for real result markers (the results container, result links, data-ved attributes), and that covers the normal case. But there's also a fallback that accepts a clean 200 page above a certain size when no consent or "sorry" page is detected, and your JS-wall example is exactly what could slip through it. We're now measuring how often that fallback fires, per provider. If it's material, we'll switch to "results on the page or it doesn't count" and note the change date in the methodology and reports.
We've also started randomizing provider order on every run, following your first comment.
Interesting that the Windows/Linux gap disappeared in a container on another connection. That points more to browser/environment fingerprint than network. Thanks again, this thread has been more useful than most feedback we get.
Glad it helped! 😄 Heads-up on that fallback: the no-JS page is around 90 KB, so a size threshold won't catch it. Our classifiers handle it, and the Amazon cases too. They're open if you want to compare: github.com/nodemaven/proxy-benchmark