Test if your site is blocked in China — evidence before rebuild
Before you rebuild for Mainland China, prove reachability with China Network Diagnostics — timeouts, DNS fail, and TLS/connect fail as evidence, not a guess from an overseas monitor.
Do not rebuild for Mainland China until you have reachability evidence. A China access ticket is a measurement problem first: run China Network Diagnostics from Mainland China nodes, read timeouts / DNS fail / TLS-connect fail as consequences, then decide the smallest honest next move. An overseas uptime green light — or a single “China check” screenshot — is not enough for go/no-go.
What “blocked in China” testing means
Hard names for this decision:
- Mainland China vantage — Probes that originate inside Mainland China networks. US/EU monitors answer a different question.
- Reachability consequences — What you can observe: DNS failure, TCP/TLS connect failure, HTTP timeout or non-usable status, and (when available) uneven city/ISP results. “Blocked” is a label for those consequences — not a myth about the brand.
- China Network Diagnostics — Chinaready’s objective evidence tool: public overview at
/diagnose; entitled teams run HTTP / PING / DNS from Mainland China nodes in Client Workbench Diagnostics. - Hard path failure vs soft failure — Hard: connect never completes or DNS never answers across nodes. Soft: connect works but latency, loss, or city variance makes the product unusable.
- HTML host vs critical path — A pass on the marketing hostname can still leave fonts, tags, auth, or APIs dead for China users.
- Evidence before rebuild — Architecture and ICP programs start after you know which hop failed. Sibling maps: Website not working in China (triage) and Website accessible in China (access architecture).
Vocabulary first. Next: what must be true before you trust a result.
What must be locked before you trust a result
Missing any of these stops your product team from an honest go/no-go — you will argue mythology instead of evidence.
| Precondition | Why your process stalls |
|---|---|
Exact hostname / URL customers use (apex, www, app, deep link) | Probing the wrong name produces false “works / blocked” fights |
| Mainland China vantage (Diagnostics or equivalent in-country probes) | Overseas monitors prove overseas reachability only |
| Inventory of critical hosts on the journey (HTML, static, API, third parties) | One blocked dependency can kill a “green” document host |
| Agreement on what “pass” means (connect + primary journey, not logo load) | Teams ship a screenshot and call it launch |
| Owner for interpret → decide (not “run tool, ignore CSV”) | Evidence without a decision owner becomes theater |
Chinese-language provider context and ISP diversity sit beside the probe. Your team usually cannot close a China block debate from HQ Wi‑Fi alone.
Evidence path with China Network Diagnostics
| Stage | Decision / outcome |
|---|---|
| 1. Lock target | Customer hostname(s) and critical third-party hosts |
| 2. Run Diagnostics | China Network Diagnostics overview → Workbench HTTP / PING / DNS from Mainland China nodes when entitled (Workbench blog) |
| 3. Read consequences | Timeout, DNS fail, TLS/connect fail, status/timing — across nodes, not one sample |
| 4. Classify | Hard path failure · soft failure · dependency / architecture issue |
| 5. Decide before rebuild | Smallest honest next step — cleanup, termination change, filing/host path, or deeper triage |
China Network Diagnostics in Client Workbench — multi-node HTTP / PING / DNS from Mainland China, with summary metrics and city/region ranking so one green check does not close the ticket.
How to read the evidence (selection gate)
Wrong label chooses the wrong program. Use the full set before you fund a rebuild:
| Evidence pattern | Usual meaning | Next decision |
|---|---|---|
| DNS fails across Mainland China nodes | Resolution / path problem for that hostname | Fix DNS or hostname strategy before CDN shopping |
| TCP/TLS never completes (timeout / reset) | Hard reachability failure to that host | Confirm across cities/ISPs; then termination or block hypothesis |
| HTTP times out or never usable | Path or origin unreachable from China vantage | Do not call it “CDN tuning” until connect works |
| Connect OK, high latency / city variance | Soft failure — usable for some, dead for others | Performance / edge design — not a single “blocked” slide |
| HTML host OK, critical third party fails | Dependency break on the journey | Delete/replace that host on the China path |
| Overseas monitor green, Diagnostics red | Wrong vantage was driving the debate | Prefer Mainland China evidence for China users |
Necessity: product and sales often jump from one complaint to “rebuild in China.” Without this classification, you buy the wrong stack.
Why one green check still misleads
Overseas green → false confidence. Different DNS and network boundaries mean “up globally” is not “works in Mainland China.”
Single node green → incomplete story. One Wi‑Fi or one city can disagree with multi-node Diagnostics (city/ISP spread is the point of Mainland China probes).
HTML pass + blocked dependency → dead product. Shells that wait on fonts, tags, CAPTCHA, or auth fail even when the document host connects.
“Blocked” without hop → wrong rebuild. Filtering is one hypothesis. Soft failure and dependency breaks need different work than a full in-country rebuild.
VPN success → wrong sample. Corporate egress is not customer ISP reality in Mainland China.
Tool run without decision owner → delay. Evidence only matters when someone classifies the pattern and picks the next gate — triage (not working) or access architecture (accessible).
What blocks honest measurement
- HQ-only monitors driving China tickets — Prove from Mainland China vantage before architecture debates.
- Testing only the marketing apex — App, API, and asset hosts are part of “the site.”
- Calling every failure “Great Firewall” — Measure the consequence first; label after evidence.
- Skipping third-party hosts — Analytics, fonts, and CAPTCHA often explain “site blocked” reports.
- Screenshot culture — One laptop photo is not multi-node evidence.
- Rebuild-first budgeting — ICP, hosting, and CDN programs start after Diagnostics classification, not before.
- No Workbench entitlement when you need depth — Public overview at
/diagnoseexplains the product; contract-gated Workbench runs are how entitled teams keep CSV-grade evidence beside the release ticket.
What “proven” means: Mainland China Diagnostics (or equivalent) shows the first broken hop; the failure class is agreed; the next program matches that class. US laptop greens do not close the ticket.
When you need a China landing partner for evidence
Most product teams need a China landing partner to run and interpret Mainland China vantage checks, align provider consoles, and turn evidence into cutover — not another overseas rebuild cycle. Your team still owns the architecture decision; the partner path makes multi-node proof and the follow-on gates executable when China-side rails are not already in-house. Start with China Network Diagnostics; use Client Workbench Diagnostics when your engagement includes it.
What we can offer?
When the question is whether your site is blocked in Mainland China, Chinaready helps you prove reachability consequences first — then choose triage, acceleration, or hosting — instead of rebuilding on a guess. We do that through:
- China Readiness Assessment — Frame the go/no-go with Mainland China evidence (including China Network Diagnostics and Workbench probes when entitled) so sales and engineering argue the same failure class before budget moves.
- China Access Acceleration — After Diagnostics classifies the hop, fix the proven path: edges, dependency cleanup, and cutover checks so “fixed” means Mainland China users connect and complete the journey.
- China Product Hosting — When evidence shows overseas termination is the real blocker, place the right origins on Mainland China infrastructure and align filing/host bind when you claim an in-country site.
- Mobile App Distribution — Extend the same hostname inventory to app deep links and APIs so a website “unblocked” story does not leave the product dead in WebViews or stores.
Contact us when China access debates keep restarting without Mainland China evidence and you need an evidence-led decision.
Frequently asked questions
How do I test if my website is blocked in China?
Run reachability checks from Mainland China vantage points — not only an overseas uptime tool. Chinaready China Network Diagnostics (/diagnose and Client Workbench) probes HTTP, PING, and DNS from Mainland China nodes so you see timeouts, DNS failure, or TLS/connect failure as evidence before you rebuild.
What does “blocked” mean in a Diagnostics result?
Treat “blocked” as a consequence you can measure — hostname does not resolve, TCP/TLS never completes, or HTTP times out from Mainland China nodes — not a brand rumor. Soft failures (slow or uneven across cities) and third-party dependency breaks need a different fix than a hard path failure.
Is one green check enough to say the site works in China?
No. A single vantage or a pass on the HTML host alone can miss ISP or city variance and blocked third-party hosts on the critical path. Use multi-node evidence, then decide whether the next move is dependency cleanup, termination change, or a larger architecture program.
Where do I run China Network Diagnostics?
Start with the public product overview at /diagnose. Signed clients run HTTP, PING, and DNS checks from Mainland China nodes inside Client Workbench Diagnostics — see the Network Diagnostics in Workbench blog for how results and CSV export work.
Should we rebuild the site as soon as China users complain?
Not before evidence. Prove the first broken hop from Mainland China, classify hard block vs soft failure vs dependency issue, then choose the smallest honest fix. Sibling Guides cover outage triage and accessibility architecture once the measurement story is clear.
Can our team finish China access proof from HQ monitors alone?
Usually no. Overseas dashboards prove overseas reachability. Mainland China vantage probes, Chinese-language provider context, and cutover ownership are rails most product teams lack in-house — that is when a China landing partner becomes the realistic path.
