Method paperThe rules behind our panels
Test registry access. Keep the limits clear.
A failed lookup says nothing about a supplier. This page explains our dated portal tests. It shows what we sent, what came back and where the test stops. The rules grew from mistakes in our own reports.
Short answer
Record the date, network, client and result. Test control hosts in the same session. A script with browser headers is still a script. Check the response body before saying a page loaded. A failed test does not tell you why it failed.
Five rules before you act on a failed lookup
- 1. Name the network. State where each request ran: a mainland home connection, an overseas proxy or another named node. Keep paired results separate. Two networks can get different answers from the same URL.
- 2. Controls in every session. Each round requests one Chinese government host (
www.gov.cn) and one Chinese commercial host (www.baidu.com) from the same machine, moments apart. If a control fails, exclude the round from conclusions about general availability. Keep its observations with the exclusion reason. A successful control does not rule out a target-specific routing or protection issue. The controls verdict is recorded in the published data, machine-readable, per round. - 3. Paired user agents. Compare a plain command-line request with one carrying a desktop-browser user agent. A browser user agent is not a browser session. Report each run’s actual counts; the 8 August panel had one CLI request and three browser-UA requests per target, with one of each per control.
- 4. Record the first answer. Redirects are not followed and requests are not retried. A 301 is an observation. It is not an obstacle. If you test retries or follow redirects separately, retain the first response and label each later step. These scripts do not measure what a buyer’s browser would have done.
- 5. Keep missing status distinct from an HTTP response. A zero is the probe’s placeholder for no recorded HTTP status. Read the saved error to identify the observed failure stage. It is not an HTTP status code. A response code alone cannot identify the origin server or a network cause.
| What the probe records | What it means | Did a server answer? |
|---|---|---|
200 | HTTP response recorded; inspect the body | Yes |
301 | Redirect offered. Not followed: recorded as the first answer | Yes |
403 | Forbidden; the code alone does not identify why | HTTP response recorded |
412 | Precondition Failed under standard HTTP semantics | HTTP response recorded |
| no status | No HTTP status recorded; inspect the saved error | No HTTP response recorded |
Correction, 8 September 2026: this page now separates HTTP observations from browser success and causal claims. Standard status meanings were checked against RFC 9110. We kept the old source files.
Two ways to misread the observations
On 7 August 2026 we withdrew a general claim about overseas access. The tested proxy also failed on government hosts outside China. That made a China-wide conclusion unsupported; it did not establish the precise cause.
A saved 9 August comparison contains three government files: two provincial PDFs and one central-government page. All three returned 200 direct and no recorded status through the proxy. The government control also had no status through the proxy; the commercial control returned 200. We excluded that path from general availability conclusions. This small set cannot establish that every .gov.cn host was unreachable.
On 8 August, zxgk.court.gov.cn returned 403 to the CLI request and 200 to browser-UA requests. On 9 August, CLI requests to that host and wenshu.court.gov.cn recorded connection timeouts, while browser-UA requests returned 200. The saved 9 August results show that difference. They do not establish a filtering rule or a successful browser search.
Reproducing it
- Procedure. The host probe used HTTPS GET with a 25-second timeout. It did not follow redirects or retry. It sent CLI and browser-UA requests, with controls in the same session. Counts vary by run; read the saved attempts. The separate file test requested three named file URLs. No company search or CAPTCHA step was tested.
- Published runs. Published files vary in detail: some contain request rows and others contain summaries. Check the linked file before assuming that it includes every attempt. See doi.org/10.5281/zenodo.21859883, alongside the panel and the registry record the runs feed.
- Disagreement is data. If you run this from another network or date and see something different, that is not a contradiction — vantage and date are part of the result. We publish corrections with attribution, including ones that contradict us; one is already on the registry-availability page.
What this method cannot do
- It measures doors, not rooms. A 200 on a front page does not mean a search completes — interactive paths can require verification steps a front-page probe never touches.
- Two vantage points are two, not all. A home connection in another place may get a different result. Two tested paths cannot stand for all users.
- It cannot explain, only observe. The method records HTTP responses and request errors. Controls help interpret a comparison; they do not isolate a target, route or filtering cause.
- Nothing about any company. A failed request says nothing about a company. It does not prove that a record is missing or hidden.
For a buyer, the next step is a dated company record check. Keep the exact host, date and request details if access fails. Leave the supplier’s identity unresolved until you can read the record.
The method applied again, two weeks later, including the round we threw away
A method is worth what it does on its second run. This one was re-run on 22 August 2026 against the same target set, and both halves of what came back are reported here.
| Vantage | Controls | Outcome |
|---|---|---|
| Domestic (Shanghai node) | Both healthy | 7 of 8 status pairs unchanged; zxgk CLI changed from 403 to 200 |
| Overseas (via proxy) | Government control returned nothing; commercial control 200 | Voided in full |
Rule 2 excludes a round with a failed control from general availability conclusions. The overseas round is retained with that limit. Its failure does not locate the cause or show what another overseas user would see.
The retest used a Shanghai node on a later date. Both place and time changed. We cannot tell which change caused the new result. The public retest summary lists all eight status pairs and the excluded overseas round. Its historical causal interpretations exceed those observations.
The same discipline applied to a measurement that is not about availability
The same habits help with other tests: keep a fixed sample, date each result and explain excluded data. The provider field test of 21–22 August 2026 used a different set of rules.
| Discipline | Availability probe | Registry fill-rate run |
|---|---|---|
| Frame fixed in advance | 8 hosts, chosen before probing | 45 company codes in the retained provider run |
| Controls | 2 control hosts every round | Selected empty-result probe informs the classifier |
| Bad rounds discarded | Overseas round of 22 Aug voided | Classifier corrected: 300000 had been read as failure |
| Date stated | Yes, on every claim | Yes, on every table |
The provider run had its own error. Its notes say an empty-result code was first read as a failure. Fixing that rule did not prove that the returned records were complete or that a company had no adverse records.
The retest summary is published as china-official-source-retest-2026-08-22.json. That public file does not contain the per-company records. The provider-run notes describe the error-code correction; the summary alone cannot verify every company result.
Questions about the method
Why do Chinese government websites seem unreachable from outside China?
A failed request can have several causes. Our saved proxy comparison had a failed government control as well as failed target requests. We excluded it from general availability conclusions. It does not prove a geographic block or explain the network cause.
How do you tell a blocked website from a broken measurement?
Use same-session controls and retain the response and error details. If a control fails, exclude the round from general availability conclusions. If controls succeed, the target result still needs investigation; routing and protection systems may differ.
Why does the same official site work in a browser but fail from a script?
A browser user agent is not a browser session. Our saved court-host requests differed between CLI and browser-UA requests. We did not test a full browser search or isolate a filtering rule. A buyer may see a different result.
Citing this method
You may quote or adapt this method, including for paid work. Keep the network and date with each result. The underlying runs are open data: doi.org/10.5281/zenodo.21859883.
Currawong, “Measuring China official source availability: the method”, paired-vantage, paired-client availability measurement with same-session controls, distilled from measurements of 5–9 August 2026.
https://currawongweb.com/verify/is-a-chinese-site-blocked-or-broken/
Browse all measured studies and methods in the research index.
This page describes a measurement procedure. It is not legal advice, and it is not a statement about any company or about conditions on any network or date beyond the observations cited.
Being pushed to pay a deposit right now? The checks that matter before money moves are free to read. Time needed depends on the evidence you have.
If you want these records pulled for your own supplier: the “Just check who they are” selection of the report menu covers them, packs from $26.55. Delivery follows the window on your order confirmation. First paid order: unhappy for any reason, tell us within 14 days of delivery and it is refunded in full.