Proxy Index
OverviewReportsRankings
MethodologyBlogAbout
LensProxy Index
Scoring lensApplied across rankings and provider pages
Preset

A score appears only when every dimension with a positive weight has comparable evidence. Saved on this device.

Latest report
Home › Methodology
Methodology · Canonical proxy scorecard v1

How we score proxy providers

The complete definition of every check, dimension, threshold and edge case behind the eligibility gate and the graded dimensions.

6
Gate checks
6
Graded dimensions
3
Measurement nodes
7d
Window per issue
Canonical proxy scorecard v1
Scorecard version
Effective 2026-07-10
Sections
  • §1 · Gate & dimensions
  • §2 · Measurement
  • §3 · Connection
  • §4 · Exit identity
  • §5 · HTTP reachability
  • §6 · Throughput
  • §7 · Session persistence
  • §8 · Geo accuracy
  • §9 · ASN accuracy
  • §10 · Caveat codes
  • §11 · Changelog
Tools
  • Scoring scripts (MIT) ↗
  • Reference dataset ↗
  • Reproducibility guide ↗

§1 · The gate and the dimensions

We do not roll everything into one number. A provider first clears an eligibility gate — the basic plumbing, pass or fail — and then earns a grade on each of six dimensions built only from measurements that actually separate one provider from the next.

The gate: benchmarkable, or not

Six commodity checks decide whether a line is worth grading at all: can it connect, does traffic leave through the proxy, does HTTP work, is the exit ASN sane, does the country match, and can it move a real response body. These are pass/fail, not scored. Against unprotected targets almost every serious provider clears all six — which is exactly why scoring them told buyers nothing. So we gate on them and move on.

Gate
benchmarkable = connection ∧ exit identity ∧ http ∧ asn ∧ country geo ∧ throughput reachability
Reported as a line — “benchmarkable: passed 6/6 baseline checks” — not a number. A line that fails the gate is marked not benchmarkable and its dimensions are suppressed.

The six dimensions

Each dimension is graded 0–100 from inputs we already collect, and each one carries its inputs in the open so the grade is legible rather than asserted. A dimension we cannot yet grade for a line reports an honest not graded — we never invent a number to fill the slot.

  • Workload successworkload_success

    FED BY fixture success rates against real target classes, blended with browser-engine success where present.

    WHY NOT 100 real and protected targets fail some fraction of the time for everyone; a residential pool medians around the low 90s, datacenter far lower.

  • Speedspeed

    FED BY p50/p95 latency normalized against banded thresholds, plus throughput MB/s where measured.

    WHY NOT 100 latency is bounded by physics and upstream device quality; the tail (p95) is where jobs actually stall, and it never fully flattens.

  • Pool qualitypool_quality

    FED BY unique exits per attempt, repeat rate, top-exit-IP share, and exit-IP entropy from the observed exits.

    WHY NOT 100 advertised pool size is marketing; realized uniqueness and subnet spread are what a target sees, and recycling drags them down.

  • Trust & sourcingtrust_sourcing

    FED BY source-labelled IP reputation risk share, usage-type honesty (claimed vs observed), and city-level geo precision once enrichment coverage is sufficient.

    WHY NOT 100 reputation is vendor-calibrated and can be contaminated by other customers; we grade only when at least five unique exits have 80% coverage from one labelled source.

  • Sessionsession

    FED BY sticky-session hold rate and duration through the advertised window.

    WHY NOT 100 sessions degrade as upstream residential devices go offline; a long hold depends on hardware the provider does not own.

  • Value
Worked example · grading one dimensionworkload_success

Say a line runs 432 workload attempts and 192 succeed, and its browser-engine pass rate is 0%. Workload success is the blend of those two measured rates — here roughly a 22, not a 100 — because the grade is built from what actually completed against real targets, not from whether the socket opened.

request success 192/432 · browser-engine success 0% → workload success ≈ 22 / 100

How one dimension grade is actually built. The inputs travel with the grade, so a reader can see why the number landed where it did — and why a clean gate does not buy a clean dimension.

Consistency is part of the grade

We run rolling 30-day windows, so a dimension is scored across daily buckets rather than in one lucky afternoon. A provider that holds steady reads differently from one that spikes and decays, and that stability is a property of the grade — not a footnote to it.

On the legacy compositeThe old single composite score is being retired. It graded only the commodity gate checks, so it clustered near 100 and hid every measurement that mattered. We still publish it for compatibility with existing consumers, but the rankings, the reviews, and the pages now lead with workload success and the graded dimensions.
Reproducibility

Every score in every report can be re-derived from the published CSV by running the open-source scoring script for the corresponding methodology version.

Published versions
  • Gate and graded dimensions · 2026-07-10
  • Region and city composition · 2026-05-28
  • Series vantage policy · 2026-05-28
  • Reputation risk metric · 2026-05-28
  • Usage-type accuracy · 2026-05-28
  • Vantage and concurrency slices · 2026-05-28
  • Browser-engine probe metrics · 2026-05-21
  • Session persistence scoring · 2026-05-21
  • Throughput metrics · 2026-05-19
  • Trust metadata · 2026-05-18
  • Public rolling report v2 · 2026-05-17
§2 · MEASUREMENT

Three nodes, seven days, no provider on the loop.

Every score starts as raw network checks. We run the same battery from three continents over a rolling seven-day window, so a provider cannot post a number by being fast from one region or lucky on one afternoon.

Measurement nodes · cohort-median round-trip3 nodes
EUFrankfurt
426ms
USAshburn
389ms
APACSingapore
584ms

Cohort-median latency from each node to a standardized endpoint, through the proxy. The latency family score is the median across all three — not the best one.

  • 7drolling window per issue — every check is timestamped in UTC and node-tagged in the raw CSV.
  • 5,000latency samples per node, per provider; cold-start requests are discarded before the median.
  • 0advance access — no provider sees its score, the cohort, or the dataset before publication.
REFERENCE · CHECK FAMILIES

What each measured family checks — and what a single number hides.

Each family below is one input the eligibility gate and the graded dimensions are built from — not a score of its own. For each: the exact ratio we compute, why it earns its place, and the detail a single headline number can't show — drawn live from the current cohort.

§3

Connection

Core · since v1.0

A proxy that cannot establish a connection cannot be used by any higher-level workflow.

weight0.18
weight share18%
How it is scored
successful attemptseligible attempts
Weight 0.18 · normalized 0–100 per provider.

Checks whether the proxy accepts a basic TCP connection.

Scores are normalized per provider and compared within the issue cohort.

WHAT THE SINGLE NUMBER HIDES

Connection failure blocks every other signal.

Connection pass rate is the base layer. If a proxy cannot establish a TCP session, higher-level HTTP, geo, ASN, and session checks never get a chance to run.

§4

Exit identity

Core · since v1.0

Exit identity proves traffic is actually routed through a proxy and gives downstream checks a stable observed IP.

weight0.22
weight share22%
How it is scored
successful attempts
§10 · CAVEAT CODES

When a score needs an asterisk.

We attach a caveat code when a number is misleading on its own. Caveats are informational — they never change rank order.

CodeMeansEffect on score
GEO-3Country match high; sub-region match below threshold.None — informational only.
ASN-1ASN occasionally announces as hosting; mixed pool.None — informational only.
CAP-2Elevated challenge rate against one of three WAF vendors.None — informational only.
§11 · CHANGELOG

Versioned, dated, and never applied backwards.

Methodology changes are versioned and dated. Past reports are not rescored under new versions; the version each report ran under is printed on its cover.

VersionEffectiveChange
Gate and graded dimensions2026-07-10Added an additive reporting layer: an eligibility gate over the commoditized plumbing checks (connection, exit identity, HTTP, ASN, country geo, throughput reachability) and six graded dimensions (workload success, speed, pool quality, trust and sourcing, session, value) derived from existing metric snapshots. Dimensions grade only where inputs exist and report an honest not-graded status otherwise. The composite score and its weighting are unchanged.
Region and city composition2026-05-28Added observed region and city composition metrics for public rolling report geography breadth.
Series vantage policy2026-05-28Added structured series-level vantage policy evidence comparing declared worker regions against observed report regions.
Reputation risk metric2026-05-28Added high-risk IP share as a measured metric when reputation enrichment includes risk bands or risk scores.
Usage-type accuracy2026-05-28Added usage-type accuracy as a measured metric when exit enrichment includes residential, mobile, ISP, or datacenter classification.
Vantage and concurrency slices
Next

See the methodology applied.

Method matters most where it meets data. Open the latest issue to watch these rules score a real cohort, or compare the current field.

Open the latest issue →Compare the rankings →
Proxy Index

An independent benchmark of residential, ISP, mobile and datacenter proxy providers. Methodology, raw response logs and check timestamps are published with every issue.

One page per benchmark issue. No tracking pixels.

Reports

  • Latest issue
  • Residential
  • ISP
  • Mobile
  • Datacenter
  • Special reports
  • Archive

Methodology

  • Gate & dimensions
  • Measurement nodes
  • Caveat codes
  • Changelog
  • Raw datasets

About

  • How we're funded
  • Editorial independence
  • Submit a correction
  • Provider FAQ
  • Blog
  • Contact
© 2026 Proxy Index. Independent and self-funded. No provider money.
value

FED BY cost per successful request — pricing facts divided by workload success — reported as context in phase 1.

WHY NOT 100 effective cost only exists once success is measured; a cheap $/GB is worthless if the requests do not complete.

eligible attempts
Weight 0.22 · normalized 0–100 per provider.

Checks whether the proxy returns a usable exit IP through an IP echo target.

Scores are normalized per provider and compared within the issue cohort.

WHAT THE SINGLE NUMBER HIDES

No observed exit means no trustworthy proxy evidence.

Exit identity proves traffic actually leaves through a proxy. Without a usable observed IP, downstream classification and targeting metrics become unreliable.

§5

HTTP reachability

Core · since v1.0

HTTP reachability is the closest low-cost signal for whether the endpoint can carry normal web traffic.

weight0.18
weight share18%
How it is scored
successful attemptseligible attempts
Weight 0.18 · normalized 0–100 per provider.

Checks whether a proxied HTTP request reaches the benchmark target successfully.

Scores are normalized per provider and compared within the issue cohort.

WHAT THE SINGLE NUMBER HIDES

TCP success does not guarantee usable web traffic.

A reachable socket is not enough. HTTP reachability catches endpoints that connect but cannot carry normal web requests through benchmark targets.

§6

Throughput

Core · since v1.0

Large pages, media assets, and browser sessions need proxies that can move more than tiny responses.

weight0.10
weight share10%
How it is scored
successful attemptseligible attempts
Weight 0.10 · normalized 0–100 per provider.

Checks whether the proxy can complete bounded download samples against controlled targets.

Scores are normalized per provider and compared within the issue cohort.

WHAT THE SINGLE NUMBER HIDES

Tiny responses hide slow transfer paths.

Small health checks can pass while heavier pages stall. Throughput checks whether the proxy can move realistic response bodies, not just connect.

§7

Session persistence

Added in v2.0

We added session stability once it became clear that geo and ASN scores said nothing about whether a multi-step flow - login, cart, checkout - would survive.

weight0.07
weight share7%
How it is scored
successful attemptseligible attempts
Weight 0.07 · normalized 0–100 per provider.

Checks whether sticky-session follow-up requests keep the same observed exit identity.

Sticky sessions must hold through the advertised threshold without rotation or re-auth.

WHAT THE SINGLE NUMBER HIDES

Two pools, same pass-rate, different deaths.

A single pass-rate cannot show the shape of failure. Some pools hold perfectly and then cliff the instant the advertised window closes; others bleed sessions steadily from the first minute.

§8

Geo accuracy

Core · since v1.0

Geo is the most-requested targeting dimension and the easiest to fake - a pool can sell US residential while quietly announcing from a Frankfurt datacenter. This area catches the gap between the label on the tin and where the IP actually sits.

weight0.14
weight share14%
How it is scored
matching geo lookup attemptscomparable geo lookup attempts
Weight 0.14 · normalized 0–100 per provider.

Checks whether observed country matches the declared country when geo metadata is available.

Country-level disagreement is flagged when comparable lookups fall below the issue threshold.

WHAT THE SINGLE NUMBER HIDES

Country is easy. Cities are where pools split.

The headline percentage is country-weighted, so it reads high almost everywhere. The moment you target a region or a city the field spreads out - and that precision drop never shows up in the single number.

§9

ASN accuracy

Core · since v1.0

Modern anti-bot systems score the announcing ASN before they ever look at behavior. A residential IP that announces from a hosting network is flagged on arrival, so a clean ASN profile is doing quiet work on every request.

weight0.11
weight share11%
How it is scored
matching ASN lookup attemptscomparable ASN lookup attempts
Weight 0.11 · normalized 0–100 per provider.

Checks whether the proxy exits from the declared autonomous system when ASN metadata is available.

Mixed hosting/residential ranges trigger caveat ASN-1 when cleanliness falls below threshold.

WHAT THE SINGLE NUMBER HIDES

A letter grade compresses the whole pool.

Two pools can both grade A while one is 99% genuine residential ASNs and the other blends in a hosting slice it would rather you did not see. The composition is what actually trips detection.

2026-05-28
Added public time-series coverage for declared worker vantage-region and concurrency-tier success rates.
Browser-engine probe metrics2026-05-21Added browser-engine probe metric definitions for target-class success, blocks, challenges, semantic validation, and navigation latency.
Session persistence scoring2026-05-21Added session persistence as a scored family for sticky-session scraper workflows.
Throughput metrics2026-05-19Added public throughput metric definitions and chart-ready rolling time series from download sample checks.
Trust metadata2026-05-18Added public trust metadata: confidence tier, coverage warnings, sample design, methodology notes, and scraper-facing interpretation.
Public rolling report v22026-05-17Added public-safe scorecard labels, threshold meanings, metric definitions, and time-series explanations.
A note on rescoringWe do not rescore old reports under new methodology. This is intentional: a benchmark must be a record of what was measured at the time, under the rules of the time.