How we test, and how a verdict is decided

Every verdict on this site comes from the same procedure: fetch the URL from inside mainland China and from outside at the same time, then explain the difference. This page describes the measurement, the rules that turn measurements into a verdict, and what those verdicts cannot tell you.

The measurement

A test fetches one exact URL — scheme, host and path together — from several probes inside mainland China and from a control probe outside it, normally in the United States. Each probe records how the request ended (the curl exit code), the IP the name resolved to, whether the answer came from a host that runs no DNS resolver, how many bytes arrived, and the final address after redirects. One test is therefore a handful of measurement rows, and a verdict is the comparison between them. Because each URL is tested in its own right, a site's home page and one of its articles can carry different verdicts, and so can its http and https addresses.

What the detectors look for

Four independent detectors read those rows. Each one looks for a specific mechanism, and the most severe signal decides the test's verdict — so a URL is "blocked" as soon as one mechanism is proven, even if the others stay silent.

DetectorWhat it comparesNeeds a working control
Connection resetCompares whether each mainland China probe hit a TCP reset / connection error that the US control did not (curl exit code; skipped when the site is hosted inside mainland China).No
DNS poisoningCompares the IP each mainland China probe resolved the domain to against the US control, and flags answers from known-invalid DNS servers.No
Redirect inside mainland ChinaCompares the country of the final (post-redirect) URL — a mainland China probe diverted to a server inside mainland China means the request was redirected.No
Failed to loadCompares whether each mainland China probe could actually download the page (curl exit + bytes received) when the US control succeeded.Yes

When the control itself fails

Sometimes the outside control cannot fetch the page either — the site is down, or it rejects our probe. The older tools discarded such tests entirely, which silently threw away real censorship: washingtonpost.com sits behind bot mitigation that breaks the control's connection on every run, so hundreds of tests were discarded while every probe inside mainland China was being reset. Here each detector is judged on the evidence it actually needs. A DNS answer forged in transit is still forged, and a reset is still a reset, whether or not the control finished its own download. Such a test can convict but never clear a URL: two probes failing the same way tells you nothing about interference, so "not blocked" is never concluded from a broken control.

The verdicts

A URL's headline is the verdict of its conclusive tests over the last 90 days.

  • Blocked — the Great Firewall interfered with the request — a reset connection, a forged DNS answer, or no content where the control got a page.
  • Redirected inside mainland China — the request reached a server, but a different one: probes inside mainland China end up on a host inside the country while the control does not.
  • Intermittent — conclusive tests disagree. Some probes or some days are disrupted and others are not, which is what partial or unstable blocking looks like.
  • Not blocked — probes inside mainland China get the same page as the control.
  • Not enough data — nothing conclusive in the window. Usually the site is unreachable everywhere, or too few tests have run.
  • Unresolvable — there is nothing left to measure: the name no longer resolves anywhere, so the address is dead rather than censored.

The 90-day window

The headline percentage is the share of conclusive tests in the last 90 days that were disrupted; inconclusive tests are excluded rather than counted as clear. The window matters: blocking changes, and a verdict from 2014 says nothing about today.

When a URL has no conclusive test in the window — most often because it stopped being tested — the page falls back to the most recent conclusive verdict it does have and labels it with that year. A verdict marked "as of 2019" is the last thing we can honestly say, not a claim about the present.

Limits

  • Censorship is not uniform. The Great Firewall behaves differently by province, network and moment, and our probes sit in a few fixed places — a "not blocked" verdict means our probes got through, not that everyone does.
  • We measure the network, not the page. A site that loads but is censored internally, or that blocks Chinese users itself, looks unblocked to us.
  • Tests are unevenly spaced. Popular URLs are tested constantly, obscure ones may not have been touched for years, so "last tested" matters as much as the verdict.
  • A single test can be wrong. Networks fail for ordinary reasons; the 90-day aggregate exists precisely so one bad run cannot flip a verdict.
  • Historical data carries its own history: the probe network, the tooling and the verdict rules have all changed since 2011, and known-bad measurement periods are excluded.

Common questions

What does a timeout mean?
The probe waited for the server and nothing came back. On its own that is not proof of censorship — sites go down. It counts as interference only when the control fetched the page normally at the same moment, which is what the transfer detector checks.
Why do two addresses on the same site have different verdicts?
Because they are separate tests. The Great Firewall can block one hostname, one path or one scheme and leave the rest alone, so news.example.com may be blocked while example.com is not. Each URL page lists the related addresses so you can see the divergence.
Why does a page say "not enough data"?
Either too few tests have run in the window, or the tests that ran could not distinguish censorship from an ordinary failure — typically the site was unreachable from everywhere. It means we will not guess, not that the URL is fine.
How often is a URL tested?
It depends on the URL. Prominent sites are tested many times a day; the long tail far less often. Every page shows when it was last tested, and you can trigger a fresh test yourself from the URL's page.
Should I rely on a single test?
Use it as evidence, not proof. One test shows what happened at one moment from a handful of vantage points; the calendar and the 90-day figure are what you should quote.

Citing and reusing this data

All of it is open. Every URL page has a JSON endpoint, the search and browse layers have documented endpoints, and per-test measurement rows are downloadable. When citing a verdict, include the URL, the date and the window it covers. Data & API