Our testing principles
Every scraping tool on 5Proxy is scored against the same rig, the same targets and the same 72-hour window. We do not accept vendor-supplied benchmarks, vendor-run trials, or 'optimised' accounts. Where a vendor grants us a trial, it is a standard self-serve plan bought or requested under the same terms any reader would get.
A benchmark is only useful if it is reproducible. That is why we publish the rig, the concurrency profile, the target mix and the weightings below — so an engineering team can rebuild the test internally and check whether our numbers hold for their own targets.
Scores decay. Any tool we have not re-tested within two quarters is flagged on its review page, and the rating is treated as provisional until the next run.
- +Same rig, same targets, same window for every tool in a cohort.
- +No vendor-supplied numbers, no vendor-configured accounts.
- +Self-serve plans bought at list price wherever a card is accepted.
- +Raw request logs retained so any figure can be re-derived.
The test rig
Benchmarks run from three regions simultaneously so a tool cannot win on proximity alone. Each region issues the identical request plan, and results are reported per region as well as blended, because a scraper that is excellent in Ashburn and mediocre in Singapore is a different purchase decision than one that is uniformly good.
Requests carry realistic headers and a plausible navigation pattern. We do not hammer endpoints, we honour published rate limits, and we back off on 429 rather than pushing through it — both because it is the ethical way to test and because ignoring backoff produces block rates that tell you nothing about production behaviour.
| Component | Specification | Why it matters |
|---|---|---|
| Runner | 4 vCPU / 8 GB cloud instances in Frankfurt, Ashburn and Singapore | Removes single-region bias from latency and block-rate figures. |
| Concurrency | 25 parallel workers, 200 ms jitter, exponential backoff on 429 | Mirrors a realistic production crawler instead of a burst test. |
| Volume | 10,000 requests per target, per tool, per region | Large enough for the success-rate delta between tools to be significant. |
| Targets | 12 live sites across e-commerce, travel, SERP, social and job boards | Covers Cloudflare, DataDome, PerimeterX and plain-origin defences. |
| Window | 72 continuous hours, repeated quarterly | Captures peak-hour degradation and pool rotation behaviour. |
| Validation | Gold set of 500 hand-labelled records per target | Distinguishes a 200 OK from an actually usable payload. |
How the 0–10 score is built
Every tool receives a single headline score out of 10. It is a weighted composite of six pillars, each normalised to a 0–10 sub-score before weighting, so a tool cannot buy a good rating with cheap pricing alone.
Success rate carries the most weight because a scraping tool that fails silently is worthless regardless of price. Pricing is judged on effective cost per 1,000 successful requests — retries included — not on the headline sticker price, which is how most vendor comparison tables mislead.
| Pillar | Weight | What we actually measure |
|---|---|---|
| Success rate | 30% | Share of requests that return the expected DOM or JSON on protected targets, measured over 10,000 requests per target. |
| Speed & stability | 20% | Median and p95 time-to-first-byte, plus the standard deviation across a 72-hour window. |
| Data quality | 15% | Field-level completeness and accuracy against a hand-labelled gold set of 500 records per target. |
| Pricing transparency | 15% | Effective cost per 1,000 successful requests, including retries, overage and minimum commitments. |
| Developer experience | 10% | SDK coverage, documentation depth, error semantics, and time from signup to first successful request. |
| Support & compliance | 10% | First-response time on a real ticket, KYC posture, and published robots.txt / rate-limit policy. |
Measuring success rate honestly
A 200 response is not a success. We count a request as successful only when the payload contains the expected fields for that target — a product title and price, a SERP result block, a listing ID. Soft blocks, interstitials, empty shells and honeypot pages are all counted as failures even when the HTTP status is clean.
Retries are counted against the tool, not hidden. If a tool needs four attempts to fetch one page, that is four billed requests and it shows up in the effective cost figure. This is the single largest difference between our numbers and vendor marketing pages.
- +Field-level validation against a per-target schema, not status codes.
- +Soft blocks and CAPTCHA interstitials counted as failures.
- +Retries billed to the tool and reflected in cost per 1,000 successes.
- +Per-target breakdown published so one easy target cannot inflate an average.
Pricing and cost modelling
We model three workloads — 100k, 1M and 10M successful requests per month — and compute effective cost for each, adding overage, minimum commitments and any mandatory support tier. Annual-only discounts are shown separately from month-to-month pricing because most teams start monthly.
Where a vendor quotes per-GB rather than per-request, we convert using the measured average payload for our target mix and state that payload size, so the conversion can be checked.
Ethics, compliance and disclosure
We test only on targets whose terms permit automated access at the volumes we use, or on our own honeypot infrastructure that mirrors the defences of a real site. We honour robots.txt in every run, and no personal data is collected during benchmarking.
Some links on 5Proxy are affiliate links. Affiliate status has no influence on scores, rank order, or whether a tool is included in a cohort. Rankings are produced from the scoring sheet before commercial relationships are checked, and the sheet is what ships.
If a vendor disputes a number, we re-run the affected target and publish the correction with the original figure struck through, rather than silently editing it.
- +robots.txt honoured on every run; no personal data collected.
- +Affiliate relationships disclosed and excluded from scoring.
- +Corrections published with the original figure visible.
- +Raw logs available to vendors who formally dispute a result.
Who runs the tests
Benchmarks are run by the 5Proxy research desk — engineers who have built and operated production crawlers, not writers summarising vendor documentation. Each cohort is executed by one engineer and reviewed by a second before publication, and both sign off on the scoring sheet.
Every review page states when the tool was last tested and which cohort the numbers come from, so you can tell a fresh score from an ageing one at a glance.
Methodology FAQs
How often do you re-benchmark scraping tools?+
Every cohort is re-run quarterly. Any tool that has not been re-tested within two quarters is flagged as provisional on its review page until the next run completes.
Do vendors pay to be included or ranked higher?+
No. Inclusion is editorial, and rank order is produced from the scoring sheet before any commercial relationship is checked. Some links are affiliate links, which is disclosed, but affiliate status is never an input to the score.
Why is your success rate lower than the vendor's published figure?+
Because we validate the payload, not the status code. Soft blocks, interstitials and empty shells return HTTP 200 but contain no usable data — we count those as failures, and we count retries against the tool.
Can I reproduce your benchmark internally?+
Yes. The rig, concurrency profile, target mix, request volume and scoring weights are all published on this page specifically so an engineering team can rebuild the test against their own targets.
How do you compare per-GB and per-request pricing?+
We convert per-GB pricing using the measured average payload size for our target mix and publish that payload figure, then report effective cost per 1,000 successful requests at 100k, 1M and 10M monthly volumes.
What happens if a vendor disputes a result?+
We re-run the affected target and publish a correction with the original figure struck through. Raw request logs are made available to vendors who formally dispute a number.
Do you test proxies and scraping APIs the same way?+
The rig is shared, but proxy networks are additionally scored on pool size, ASN diversity and rotation behaviour, while scraping APIs are scored on unblocking success and parsed-output quality. Weightings are stated on each review.
Are the benchmarks run from a single location?+
No. Every run executes simultaneously from Frankfurt, Ashburn and Singapore, and results are published per region as well as blended so proximity cannot flatter a tool.
