Concurrency
How the network holds as parallel sessions ramp: 1 → 4 → 8 → 16.
metric: max concurrency cleanTwenty sites. Roughly 2,400 requests per provider, per run. Residential today. Mobile, ISP, datacenter, scraping APIs and SERP APIs are on the way.
Decodo and DataImpulse tied for the top. Full run: see the data →
| # | Provider | Success | Timeout | p50 latency | Cost / 1k | Ceiling |
|---|---|---|---|---|---|---|
| 01 | decodo | 76.9% | 0.1% | 1,191 ms | $0.63 | c8 |
| 02 | dataimpulse | 76.8% | 2.8% | 2,114 ms | $0.15 | c16 |
| 03 | oxylabs | 72.4% | 0.3% | 1,180 ms | $0.86 | c8 |
| 04 | webshare | 71.7% | 0.5% | 1,242 ms | $0.51 | c8 |
| 05 | shifter | 70.1% | 4.5% | 2,402 ms | $0.33 | c8 |
| 06 | byteful | 69.3% | 1.4% | 961 ms | $0.46 | c8 |
Run: 2026-09-15 / 16 · residential proxies · sequential across providers · no retries · from probe_set.json
Every card links to that provider's residential report tab. Numbers from the 2026-09-15 / 16 run.
Every headline number on this site comes from one of these.
How the network holds as parallel sessions ramp: 1 → 4 → 8 → 16.
metric: max concurrency cleanHow often IPs actually change across the pool.
metric: unique IPs per 1kDoes a sticky session actually hold the same IP over time?
metric: session hold rateCountry and ASN distribution. Uniqueness and repetition.
metric: ASN + country spreadDoes a proxy tagged as US actually egress from the US?
metric: geo match %Connect + response time under load. p50 and p95.
metric: ms per requestSuccess, block, and timeout across the full 20-site set.
metric: success / block / timeout %A proxy that works for SERP tracking is not the same proxy that works for Amazon price monitoring. One report per workload as I run each one.
I've been using proxies for scraping and SEO work for years. Every provider says the same things: millions of IPs, fast, high success rate, rotating residential. None of those tell you what happens when you actually put eight concurrent sessions through the network on a site behind PerimeterX.
So I started testing them myself. What began as a script to check if a provider could handle my SERP scraper turned into twenty sites and roughly 2,400 requests per provider, a ranking that moves month to month. proxy.report is where I publish what I find. Read the full story →
No newsletter yet. RSS and GitHub are enough.
Every page here is one of four things. Here's the state right now: done in yellow, coming in gray.
One essay per provider: opinions, tradeoffs, verdict.
What I measure and why it matters when you actually scrape.
How providers hold up under real workloads.
Annual rankings per proxy type. The commercial pages; rankings still come from the same test data.
Some providers are affiliate partners. Some aren't. Rankings come from the same test data everything else uses. If a provider I earn from loses on the numbers, they lose on the page. Every provider page tells you whether I make money if you buy through it. See the full affiliate log.
I re-run the full 20-site test monthly. Every review cites the specific run it was written against. When numbers change, the review and the changelog both update.
I started with residential because my first use case was SERP tracking. Mobile, ISP, datacenter, scraping APIs, and SERP APIs are all coming. Each provider page will grow a new report tab as the data lands.
The test scripts are being cleaned up for public release. Once they're on GitHub, you can run the same script against the same sites and check whatever I've written.
See the roadmap. Short answer: more providers, more proxy types, and use-case-specific essays.