How to read the rankings

A leaderboard looks simple: tool names, a few numbers, a rank. But if you don't know how those numbers are produced, it is easy to draw the wrong conclusion, for instance crowning a tool that was tested twice during a quiet hour as "the fastest VPN in China". Each column has a rule behind it, and the rules match GreatFire's Circumvention Central on purpose, so the two boards can be compared side by side.

Medians, not averages

The speed, latency and stability columns are all medians. Take every test of a tool within the selected period, sort them by speed, pick the middle one. That's the tool's "speed (median)".

The mean would be a poor choice, because circumvention speed data is badly skewed. A tool that normally does 1 MB/s produces a 20 MB/s reading one night, maybe because the route was empty, maybe because the tester forgot to clear a local cache. The mean jumps; the median barely moves. The same holds in the other direction: a single test that got throttled to zero won't drag a normally solid tool to the bottom. GreatFire's approach is to use medians, and we kept it.

Latency and stability follow the same logic. A single test's latency is already the median of that test's twenty samples, and the board then takes the median across tests: a median of medians, which is deliberately insensitive to outliers.

Why at least five tests across 48 hours

To be ranked (we say "to enter the pool"), a tool needs at least 5 tests in the selected period, and the first and last of those tests must be at least 48 hours apart.

Five is a floor, not a statistically rigorous threshold, but it stops the most common noise: someone installs a new tool and runs it three times in a row — same route, same hour. The 48-hour requirement solves a different problem. Five tests in one afternoon and five tests spread over a week carry very different amounts of information. The Great Firewall behaves differently by time of day; evening peak and 3 a.m. can be two different networks. Data spanning at least two days has lived through a full daily cycle.

Tools that fail these conditions aren't hidden. They still show speed, latency, stability and test count, but the rank column reads "—" and they sink below the ranked tools. Hover over the dash and you'll see the threshold. If your favourite tool is sitting there, the quickest fix is to run a test yourself; a few more runs on different days and it will enter the pool.

How the rank is computed, and why ties happen

The rank is not the speed column sorted. It combines all three metrics:

1. For every tool in the pool, compute a speed rank, a latency rank and a stability rank. A rank for one metric = 1 + the number of pool members that are strictly better on that metric. Higher speed is better, lower latency is better, higher stability is better.
2. Average the three ranks into a score. Lower is better.
3. Sort by score, ascending. That is the final "ranking".

Step 1 uses what's called competition ranking: if three tools all measure 5.0 MB/s and nothing beats them, they all get speed rank 1 and the next tool gets 4, not 2. Because of this, scores can collide, and the board will show tied ranks. That is not a bug; it means the data genuinely can't separate them.

One detail: if a tool is missing a metric entirely (say none of its tests recorded stability), that metric's rank is set to "pool size + 1", behind everyone. Missing data never gets a free pass.

An example. Four tools in the pool. Tool A is 1st on speed, 3rd on latency, 1st on stability: score (1+3+1)/3 ≈ 1.67. Tool B is 2nd, 1st, 1st: score 1.33. B ranks above A even though A is faster, because B is good at everything. This is why "fastest" and "ranked first" are often different tools.

The "services only" toggle

Each tool in the catalogue carries a provider_type: service (a commercial provider) or self-hosted (client software you point at your own server: Shadowsocks clients, V2Ray, sing-box and so on).

With "services only" on, the pool gets one extra condition: only service tools are ranked. The reason is that a self-hosted tool's "speed" is really a measurement of whatever server and route the tester bought, not the software. Two people both running sing-box, one on a Hong Kong BGP box and the other on a bargain US-West VPS, produce a median that describes neither. Commercial providers, on the other hand, put all their users through the same pool of exit nodes, so their median actually means something.

Turn it on when you're shopping for a provider. Turn it off when you want to see how self-hosted setups are doing in general.

The GreatFire rank column

The rightmost column is "GreatFire rank". It isn't copied from the upstream page. Every time we sync, we store GreatFire's aggregates for that period and location (each tool's median speed, latency, stability, test count and time span) as a snapshot, then run exactly the same algorithm described above on that snapshot.

So the only difference between our rank and the GreatFire rank is the dataset. Ours uses every test in our database (imported plus tests run here); GreatFire's uses their aggregates as of the latest snapshot. When the two disagree, it's usually one of three things: tests run on this site nudged a tool up or down, the snapshot is a few hours stale, or the period boundaries differ by a few hours between the two sites. A difference of a place or two is normal. A large gap is worth a closer look.

The filters

The default period is 60 days, same as GreatFire. You can pick today, 7 days, 30 days, 60 days, 90 days or all time. Shorter windows rank fewer tools but reflect "right now"; longer windows are smoother but can include routes that have since been blocked.

The location filter is the location the tester chose, not one inferred from IP; once you're through a tunnel your IP is abroad anyway, so inference would be meaningless. Operating system comes from the browser's User-Agent.

"Source" lets you show everything, only GreatFire imports, or only tests run on BreakHub. The latter is a much smaller sample for now, but it's the only data with full per-test detail attached.

How fresh is the data

Imported GreatFire data syncs incrementally every hour at fifteen past, with a full reconciliation daily at 03:30 UTC. Tests submitted here are stored immediately; the rankings are cached for five minutes, so you'll see your own run on the board within five minutes at most. The "last sync" line at the bottom of the page shows the most recent successful import.

FAQ

Why isn't the #1 tool the fastest one? Because rank combines speed, latency and stability. A tool that's near the top on all three beats a speed champion with the worst latency in the pool.

I just ran a test. Why does my tool still show "—"? Ranking needs at least five tests spanning 48 hours or more. Run a few more on different days and it will appear.

Why do our rank and the GreatFire rank differ? Same algorithm, different dataset. We include tests run on this site, and the snapshot lags by a few hours. A place or two of drift is expected.

Can the median be gamed? It's much harder than a mean. To lift a median you'd have to make more than half of all tests high, across at least 48 hours. We also keep the ability to hide obviously bogus records.