Some links are affiliate links. We only recommend networks we've tested. Read our methodology →
How we test

Benchmark methodology.

How we test 100+ proxy networks against the same workloads, every night, since March 2024 — on hardware you could rent for the price of a coffee. Fully replicable on a single t3.medium.

100+
Networks tested nightly
8
Workloads / provider / night
200
Concurrent sessions
Mar '24
Running since
01

The rig

A single AWS t3.medium in eu-west-1. Node 20.x, undici as the HTTP client for raw runs, Playwright when JavaScript rendering is needed (e.g. anti-bot-heavy retailers). Runs nightly at 02:00 UTC, logs to S3, aggregated daily into a public sheet.

01

Connect

Provider's documented entry endpoint, via their SDK or raw HTTP.

02

Fire

8 workloads, concurrency 200, 10k requests/provider/night.

03

Score

3-gate success check on every response, latency captured client-side.

04

Publish

Logs to S3 → aggregated into the public benchmarks dashboard.

Each provider exposes a documented entry endpoint — e.g. brd.superproxy.io:22225 for Bright Data. We use the provider's SDK where they publish one (Python, Node), raw HTTP otherwise. We pay full retail for every account — no comp accounts, no "press" tier.

InstanceAWS t3.medium
Regioneu-west-1
RuntimeNode 20.x
HTTP clientundici / Playwright
ScheduleNightly · 02:00 UTC
Log storeS3 eu-west-1
02

Targets

Eight workloads per provider per night, each one a real job buyers actually use proxy networks for. Geos and volumes are fixed so runs are comparable night to night.

WorkloadGeoVolume
1Google SERPUS · UK · IN · DE250 queries × 4 · from 1,000 keywords
2AmazonUS · UK · DE150 pages × 3 · from 600 ASINs
3Walmart · Best Buy · TargetUS50 product pages each
4Cloudflare-fronted retailNike · Adidas · Footlocker30 pages each · incl. restricted SKUs
5Social (mobile network)Instagram · TikTok20 sessions each, where offered

The full keyword and ASN list is published on our benchmarks dashboard →, refreshed nightly.

03

Success criteria

For a request to count as a "success" we require all three gates to pass. Any one failing marks the request a miss — this is what keeps stripped 200s and silent CAPTCHA pages out of the numbers.

1

HTTP 2xx within 12s

A 2xx status code returned inside a 12-second timeout. Timeouts and 4xx/5xx count as failures.

2

Body above a minimum length

Response body length above a target-specific floor — catches stripped or empty responses dressed up as a 200.

3

No anti-bot challenge

No CAPTCHA or anti-bot challenge string in the body, matched against a per-target regex list.

04

What we measure

Five metrics per target, per provider, every night. Latency percentiles are measured client-side and include connection setup plus first byte.

Success rate

Successes ÷ total requests, per target, per provider.

P50 / P95 / P99 latency

Client-side, connection + first byte. Errors discarded.

Throughput

Average successful requests per minute at concurrency 200.

Ban rate

Share of requests returning a CAPTCHA / anti-bot body.

Pool freshness

Share of unique IPs seen across a rolling 7-day window.

05

What we don't claim

Our numbers come from one vantage point (eu-west-1) and a fixed target list. Treat them as relative comparisons between providers run on the same harness — not as a guarantee of what you'll see in production.

Real-world performance depends on your origin region, your target site's anti-bot regime that day, your concurrency, and your session strategy. A provider that scores 99.4% on our SERP test in April 2026 may score 95% in your stack with different headers and a different rotation pattern.

We publish the absolute numbers because they're useful for relative comparison between providers tested with the same harness. Treat them that way.

06

Reproducing our numbers

Email [email protected] and we'll send the most recent run logs for any provider, plus the test harness on request. We can't share other providers' API credentials, obviously — you'd bring your own. Find a bug in our methodology and we'll fix it and credit you in the changelog.

07

Methodology changelog

Every change to the rig, target list or scoring is dated here. We never silently re-baseline.

2026-05-04Added Cloudflare-fronted retail (Nike / Adidas / Footlocker) as a dedicated workload, including known-restricted SKUs, to better separate premium unblocker tiers from raw residential.
2026-02-18Tightened the success gate: body-length floor is now target-specific rather than a global threshold, removing false positives on lightweight category pages.
2025-11-02Raised standing concurrency from 150 to 200 sessions across all workloads to reflect typical production scraping loads.
2025-06-30Introduced pool-freshness tracking over a rolling 7-day unique-IP window.
2024-03-01First nightly run. 200-keyword SERP + Amazon workloads on a single t3.medium in eu-west-1.