What to look for when choosing a circumvention tool

People shopping for a circumvention tool get lost in two places: a pile of protocol names that read like passwords, and a pile of reviews that contradict each other. The first problem is fixable with one sentence per protocol. The second is fixable by trusting no review (this site included) and looking at what the data says.

The common protocols, one line each

• Shadowsocks: a lightweight encrypted proxy. Client and server share a password and wrap traffic in an AEAD cipher. Simple, fast, widely implemented. But because the stream looks like random bytes from the first packet, it has been the subject of active-probing research for years.
• VMess: the native protocol of the V2Ray project. Shadowsocks plus a user ID and a time check, so client and server clocks must roughly agree.
• VLESS: VMess with the built-in encryption stripped out. It does not encrypt on its own and leaves security to the TLS layer beneath it, which is why it is almost always paired with TLS or Reality.
• Trojan: pretends to be an ordinary HTTPS website. The server really does host a site with a real certificate; connections that know the password are proxied, everyone else gets a normal web page.
• Hysteria: runs over QUIC (UDP) with aggressive congestion control of its own. On lossy cross-border links it is often much faster than TCP-based schemes; the price is that UDP is easier for carriers to throttle or drop.
• Reality: a TLS disguise layered on VLESS. The server needs no domain or certificate of its own; it "borrows" a real website's TLS handshake, so a prober that connects sees that genuine site.

Traditional VPN protocols (WireGuard, OpenVPN, IPsec) have a hard time in mainland China because they were never designed to hide. WireGuard's handshake has a fixed shape, OpenVPN has recognisable headers, and a DPI box spots them instantly. Excellent for privacy, a target for censorship.

The protocol is not the whole story. The same protocol with a different server configuration, node location or client implementation feels different. That is also why the rankings group by tool name: users can say which provider or app they use, but often cannot say what protocol runs underneath.

Self-host or subscribe

Self-hosting means renting a server abroad and installing Shadowsocks, sing-box or similar yourself. The upside: nobody else shares your IP, nobody keeps logs on your behalf, and speed depends only on the data centre you choose. The downside comes from the same fact: once that IP is blocked, you are offline until you swap addresses and reconfigure, and blocks tend to arrive on precisely the days you need the connection most. Maintenance is a real cost too: server software needs updates, certificates expire.

Providers, often called "airports" in Chinese-speaking communities, sell subscriptions: one link, dozens of nodes, a client that switches between them automatically. Their core value is redundancy; one node dies, others remain. The risks are of a different kind: the provider may vanish, may log your traffic, may throttle you at peak hours. The "services only" toggle on the rankings isolates this category, and these tools usually have more tests simply because they have more users.

There is no universal answer. People who enjoy tinkering and care about privacy lean towards self-hosting; people who just want video to play buy a subscription. Plenty keep both, one as a backup.

What free tools cost

Free tools come in two kinds. Commercial free VPNs have to survive somehow: bandwidth caps, ads, selling your traffic data, and in the worst cases injecting content into your pages or harvesting credentials. They tend to be slow, have few nodes, and give you no way to verify what they actually do.

The other kind is the non-commercial project. Tor and its Snowflake bridges, Psiphon and the like are backed by foundations or research groups whose purpose is to get censored people online. They are usually not fast (Tor takes three hops, Snowflake relays through volunteers' browsers), but their transparency and motives are far better than a commercial freebie's. On the rankings you can see that such tools rarely post high speed medians, yet their stability is often perfectly good.

Cross-checking with this site's data

Wherever you heard about a tool, come to the rankings and do a few things:

1. Read the median, and the test count next to it. A tool ranked first on 6 tests is less trustworthy than one ranked fifth on 200. The threshold for ranking is at least 5 tests spanning 48 hours; tools that just cleared it swing a lot.
2. Check the time span. The provider page has a daily timeline; it shows whether speed is steady or whether a few great days are propping up the number.
3. Compare the two sources. Tests run on this site and tests imported from GreatFire are labelled separately. If their medians disagree sharply, the sample is thin or the two tester populations differ.
4. Use the provider page's breakdowns. Split by region, operating system and version. Some tools get noticeably faster or slower between versions, and a pooled median hides that.
5. Look at whether stability is 100%. Stability checks that images load at their expected dimensions; anything below 100% often means hijacking, injection or connections dropping mid-way. Fast but unstable is exhausting to use.

Details of all of this are in How to read the rankings and How we measure.

Run a test yourself

The data comes from users, and you can add to it. Open the test page, pick your region, say whether you are using a circumvention tool, and enter its name. One convention when naming: if you use a subscription service, enter the provider's name rather than the client's. "Clash" or "v2rayN" tells nobody anything, since the same client connects to any provider. The test takes a minute or two; the result enters the rankings anonymously, recording only the country of the exit IP, never your real address.

FAQ

Is a newer protocol always better? Not necessarily. New protocols usually exist to counter new blocking techniques, but they also carry more implementation bugs and fewer client options. Many tools that sit near the top for months use protocols that are years old; they just run good nodes with good configuration.

Should I just buy whatever is ranked first? First place means the best average of speed, latency and stability ranks under the current filters, nothing more. Set region and operating system to match your situation first, then compare test counts and time spans among the top few, and try one that offers a trial or a short subscription.

A tool shows "—" instead of a rank. Is it bad? It just lacks data: fewer than 5 tests, or a span shorter than 48 hours. You can run a few tests yourself and help it qualify.

Updated evidence

This automatically maintained evidence supplement is separate from the original editorial guide. Its update does not mean the whole guide was reviewed again.

Evidence updated 2026-10-26

Field evidence update

Observation window (UTC): 2026-09-26 – 2026-10-25 — the last 30 completed UTC days at the time these figures changed.

This field-data supplement contains 4320 visible tool tests: 4319 GreatFire imports and 1 BreakHub visitor submissions. It refreshes measured context; it does not revise or independently fact-check the guide's explanatory prose. Hidden, direct-connection and junk-name rows are excluded, and spelling aliases are grouped. The 779 sampled tools include 107 with at least 5 tests spanning 48 hours, of which 64 are marked as services. 672 tools do not meet that floor. A missing rank means insufficient coverage, not poor performance.

The largest tool contributes 15.4% of tests; records span 30 UTC days and 4 reported location categories. Counts describe submissions, not independent people or balanced experiments. 0 tests lack speed, 1 lack latency, and 0 lack stability; a median may therefore use fewer readings than the headline test count.

Applying this evidence to the guide

Use the 64 eligible service entries as candidates for closer inspection, not an automatic shopping list. A client name can cover many independently configured routes. Match your region and operating system in the rankings, compare the imported and visitor source filters, then inspect the provider's timeline. When your own setting is thinly sampled, try a short test period and measure your connection on separate days. IP information is a separate check; performance figures do not establish privacy or reputation.

Import quality and provenance

In the last seven completed UTC days ending 2026-10-25, GreatFire synchronization recorded 166 successful runs and 9 failed runs; successful runs reported 2897 newly inserted records (which may include historical records and direct-connection tests outside this supplement). These are operational counts, not a completeness guarantee. Publication requires a successful import within 36 hours and a visible imported result within 72 hours. A newer check alone does not change this supplement's update date.

Imported measurements are attributed to GreatFire Circumvention Central and its methodology; visitor measurements were submitted to BreakHub. Review test history and switch source filters when the two populations differ.