Website not working in China — DNS, CDN, and deps
Most “website not working in China” reports are DNS, overseas edges, blocked deps, or ICP mismatch — not a firewall blackout. Diagnose from Mainland China, not only a china firewall test.
Most “website not working in China” reports are not a random Great Firewall wipe. Mainland China users typically hit a different DNS answer, an overseas edge with high loss, a page that depends on blocked third-party hosts, or a filed domain still terminating abroad. A china firewall test is one useful signal — not the whole diagnosis. Product teams cannot treat a global uptime dashboard as enough: start from a Mainland China vantage on DNS → TLS → HTML → waterfall, then fix the first broken hop.
Preconditions
Before you rebuild the stack or buy a “China CDN” SKU, lock these facts. Missing any of them turns triage into mythology.
| Precondition | Why DIY stalls |
|---|---|
Exact hostname customers type (apex / www / app) | Fixing the wrong name produces “sometimes works” tickets |
| Mainland China vantage for DNS, TLS, and waterfall | US/EU monitors prove overseas reachability only |
| Inventory of critical hosts (HTML, static, API, third parties) | One blocked script can kill a 200 OK document |
| Clarity on intended termination (overseas-only vs Mainland China origin) | Global CDN ≠ in-country delivery |
| If you claim a China site: ICP path + host bind plan | Filing number in the footer with overseas DNS is both access and compliance debt |
Chinese-language provider consoles, local synthetic checks, and ISP diversity are part of this floor. Your team usually cannot close a China access incident from HQ screenshots alone.
Core path
| Step | Check from Mainland China | Broken looks like |
|---|---|---|
| 1. DNS | A/AAAA/CNAME for the customer hostname | NXDOMAIN, wrong region, overseas-only answers |
| 2. TCP / TLS | Port 443 handshake and cert name | Timeout, reset, cert/host mismatch |
| 3. HTML | First-byte and document download | Extreme TTFB or blank after connect |
| 4. Critical assets | JS/CSS/font/image hosts on first paint | Document OK; shell never hydrates |
| 5. App APIs | Auth, config, XHR/fetch hosts | UI loads; login or data hang |
| 6. Third parties | Analytics, tags, CAPTCHA, chat, CDNs | One blocked host blocks the page |
| 7. Compliance path | If China site: ICP + host bind | “Launched in China” with overseas origin |
Failure modes you will actually see
A) Soft failure — overseas origin + global CDN: connect works, product feels dead; Singapore/US checks stay green.
B) Hard failure — timeout / reset: confirm across China ISPs, not one Wi‑Fi.
C) Document OK, product dead — Google Fonts, googleapis.com, overseas auth, or US-only APIs never load.
D) Compliance mismatch — ICP number shown while DNS still points overseas (see ICP domain-DNS Guide).
Same-day triage: capture URL → China vs home DNS diff → China TLS on HTML host → waterfall → mark delete / replace / accept per host → only then choose China edge, dependency rewrite, or dual-hostname design. Do not start with “buy a VPN for the team” as the product fix.
China firewall test vs architecture failure
When stakeholders ask “is it the Great Firewall?”, run a china firewall test (or Great Firewall checker) on the customer hostname and on each critical third-party host — then keep going:
| Signal | What it usually means | Next move |
|---|---|---|
| Firewall tester: blocked | Possible URL/IP filtering or severe path failure | Confirm across ISPs; do not stop at one tool |
| Firewall tester: OK, site still dead | Soft failure — DNS, latency, TLS, or deps | Full Mainland China DNS → TLS → waterfall |
| HTML OK, one third party blocked | Document loads; product shell dies | Delete/replace that host on the China path |
| Filed ICP, DNS still overseas | Compliance + access mismatch | Align termination — see ICP domain-DNS |
“Check China firewall” and “test Great Firewall of China” queries are the right first question for a hard block. They are the wrong last answer for most B2B SaaS and marketing sites, where overseas CDN + blocked fonts/analytics explain the ticket.
Linked reasoning
Overseas-only monitor green → false confidence. Different DNS and dependency graphs mean “up globally” is not “works in China.”
China firewall test green + broken journey → still broken. Testers that only probe the HTML host miss blocked fonts, tags, CAPTCHA, and APIs on the critical path.
HTML 200 + blocked third party → dead product. Shells that wait on fonts, tags, or CAPTCHA fail even when the origin is reachable.
Asia PoP ≠ Mainland China termination. APAC edges outside Mainland China leave a cross-border penalty; filed in-country sites need approved Mainland China hosts.
Single hostname for global + China → forced compromise. When China needs different DNS, CDN, or origin, a dedicated China hostname (or explicit dual path) beats silent geo magic.
Employee VPN success → wrong sample. Corporate split tunnels are not customer ISP paths.
Difficulty and blockers
- Google and blocked defaults — Fonts, Tag Manager, reCAPTCHA, Maps, Firebase-class endpoints. Prefer delete or China-safe replace on the China hostname.
- API / deep-link splits — Marketing host works;
api.still overseas. Inventory every hostname on the critical path. - IPv6 / dual-stack — Broken AAAA or middleboxes produce “works abroad, fails in Shanghai.” Test both families.
- DNS chain surprises — Anycast that China ISPs reach poorly; CNAME chains that re-exit overseas; high TTL leftovers after cutover; apex/
wwwonly one fixed. - False narratives — “China banned our brand,” “ICP first or nothing works,” “global CDN automatically fixes China,” “it works on our China teammate’s laptop.” Prove filtering only after DNS, TLS, and dependency hosts are clean.
What “fixed” means: China vantage DNS matches intended termination; TLS succeeds; primary journey works on mobile and broadband; top waterfall third parties are China-reachable or removed. US laptop screenshots do not close the ticket.
Evidence tools and help
Chinaready network diagnostics (in Client Workbench) is a Mainland China vantage troubleshooting tool — run DNS / connectivity checks against the hostnames customers actually use, instead of trusting overseas uptime alone. See Network Diagnostics is live in Client Workbench. The tool will expand toward full-page fetch with a browser-style response waterfall so your team can pin blocked or slow assets more precisely.
When the first hop is unclear, or cutover needs hands-on validation across ISPs and provider consoles, in-China expert collaborative troubleshooting is a service Chinaready can provide — local engineers work the evidence path with your product team, not another remote guess from HQ monitors.
For stack and dependency choices (fonts, analytics, auth, CDN-class products), use the Chinaready Landscape alternatives index so your team can self-serve map global tools to Mainland China–ready options before you rebuild.
China landing partner
Most product teams need a China landing partner (or equivalent in-country ops) to run Mainland China vantage checks, interpret provider consoles, and align DNS / hosting / filing — not another overseas rebuild cycle. Your team still owns architecture choices; the partner path makes evidence and cutover executable when China-side rails are not already in-house. Diagnostics and Landscape alternatives support self-serve triage; expert in-China collaboration covers the cases that stay ambiguous after the first tool pass.
What we can offer?
When Mainland China users cannot open your site, Chinaready helps you prove the first broken hop — DNS, TLS, blocked deps, or filing/host mismatch — and choose the smallest fix, instead of another overseas rebuild. We do that through:
- China Readiness Assessment — Run an evidence pass (including Workbench network diagnostics and, when needed, in-China expert collaboration) so you know whether the failure is DNS, a third-party host, termination, or compliance mismatch before you change architecture.
- China Access Acceleration — Fix the proven path: China-reachable edges, dependency cleanup, and cutover checks so “fixed” means Mainland China users complete the journey, not a green HQ monitor.
- China Product Hosting — Move the right origins onto Mainland China termination when the evidence shows overseas hosting is the real blocker (and align ICP/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 marketing-site repair does not leave the product dead in WebViews or stores.
Contact us when China access tickets keep restarting at mythology and you need an evidence-led fix plan.
Frequently asked questions
Why does my website work everywhere except Mainland China?
Global uptime checks usually hit overseas vantage points. Mainland China users often resolve different DNS, traverse a different network boundary, and load third-party scripts that never reach them — so “up globally” and “works in China” are different facts.
Is the Great Firewall always the cause?
No. A china firewall test or Great Firewall checker can show a hard URL block, but many “website not working in China” cases are ordinary architecture — overseas origin and CDN, Google fonts or analytics, hard-coded overseas APIs. Treat filtering as one hypothesis after DNS, TLS, and dependency checks.
Is a China firewall test enough to diagnose the outage?
Useful, not sufficient. Firewall testers answer “is this hostname/URL filtered?” They do not replace Mainland China DNS, TLS, HTML, and waterfall checks that catch soft failures — high latency, wrong termination, or one blocked third-party host killing an otherwise reachable page.
Can a global CDN alone fix China access?
A global CDN can improve some paths but does not create a Mainland China termination point or replace Internet Content Provider (ICP) filing when you need an in-country site. Slow or flaky is different from filed and locally hosted.
How do I confirm the real failure mode?
Test DNS, TCP/TLS, HTML, and third-party waterfall from a Mainland China network. Chinaready network diagnostics in Client Workbench is a Mainland China vantage troubleshooting tool for that path; compare answers to your overseas monitor and fix the first broken hop.
Does ICP filing make the site automatically reachable?
Filing aligns legal hosting — it does not magically fix blocked fonts, overseas-only APIs, or DNS that still points abroad. Traffic for filed properties must terminate on the approved Mainland China hosts. Overseas monitors alone are not enough; most product teams need Mainland China vantage checks — and often a China landing partner — before a rebuild is justified.
