Why don't foreign websites work in mainland China?
Rarely because they are "blocked." Two separate gates decide whether a foreign site works in mainland China — whether the page can arrive from where it is served, and whether you are permitted to serve it from there — and when we requested 280 enterprise sites from inside the mainland, the outright-unreachable ones were the smallest group of all.
In that census (three requests per site, 28–29 August 2026, 60-second ceiling, 840 requests), 58% of sites finished every attempt, 34% finished none and 8% finished some; and inside that 34%, only 30 sites produced no response at all — the other 66 answered, usually painted something, and still never finished loading. So a reachable-looking signal (a first byte, a passing uptime check) does not mean the page works, and the genuinely unreachable hosts the Great Firewall filters — concentrated in specific Google, Meta and X properties, not whole categories — are the one part no change in delivery can fix. Yet moving delivery inside the mainland to fix the rest is itself what triggers the ICP filing requirement (State Council Order No. 292; MIIT Decree No. 33), and where your users' personal information is then served from and stored engages PIPL's cross-border rules. The sections below separate the two failures, then show why reachability and permission are decided together, once, at architecture time.
Treat the permission half as risk to map with counsel, not a verdict — which gate binds you turns on your entity, your data and who your users are. Our China team can map both gates with you →
What actually decides whether a foreign site works in mainland China
| Fact | Primary source |
|---|---|
| "Blocked" is the smallest failure, not the common one. Of 280 enterprise software and infrastructure sites requested three times each from a probe inside mainland China (28–29 August 2026, 60-second ceiling, 840 requests), 58% finished every attempt and 34% finished none. Inside that 34%, only 30 sites produced no response at all; the other 66 answered — a first byte arrived, usually a paint followed — and still never finished loading. The two failures look identical to a visitor and take different fixes. | 21YunBox China engineering team — 280-site census measured from inside mainland China, 28–29 August 2026 |
| The outright-unreachable hosts are specific, not whole categories. The 30 sites that returned nothing are dominated by around ten Google properties plus Facebook, Instagram, Twitter and X, with Snapchat also among them — a per-host reachability filter, not a ban on a type of service. In the same run Microsoft's Bing Maps host answered normally while Google Maps returned nothing, so "maps don't work in China" is false; the specific host decides. A request to a destination that does not answer is not made to answer by changing where it is sent from. | 21YunBox — 280-site census measured from inside mainland China, 28–29 August 2026 |
| A reachability check that passes does not mean the page works. Because roughly two thirds of the failed sites — 66 of 96 — answered before failing to complete, a connectivity test, a first-byte measurement or a 200-OK uptime monitor can all stay green while the page a visitor opens never becomes usable, and a test taken from outside China cannot see this failure at all. Separating the two requires a measurement taken from inside the mainland that waits for the page to finish, not just to respond. | 21YunBox — 280-site census measured from inside mainland China, 28–29 August 2026 |
| Fixing reachability by moving delivery inside the mainland opens the licensing gate. A public site served from inside mainland China must hold an ICP filing (ICP 备案) tied to a mainland legal entity. The rule is State Council Order No. 292 (互联网信息服务管理办法, 2000), which bars anyone with neither a licence nor a filing from providing Internet information services, and the Ministry of Information Industry / MIIT Decree No. 33 (非经营性互联网信息服务备案管理办法, in force 20 March 2005), under which access providers "shall not provide access services for un-filed websites." | 互联网信息服务管理办法 (State Council Order No. 292, 2000); 非经营性互联网信息服务备案管理办法 (MIIT Decree No. 33), State Council Gazette 2005 No. 32 — retrieved 2026-10-07 |
| Where your users' data is served from and stored is a separate, parallel gate. Aiming a site at people in mainland China brings it inside PIPL regardless of where it is hosted; serving China users from offshore makes their personal information a cross-border transfer requiring notice, separate consent and a transfer mechanism (Articles 38–43), and a critical-information-infrastructure operator or a handler above the volume the state sets must store that data inside the territory (PIPL Article 40; Cybersecurity Law Article 39 (formerly Article 37)). Treat it as risk to confirm with counsel, not a yes/no. | 中华人民共和国个人信息保护法 (PIPL), Articles 38–43 & 40; 中华人民共和国网络安全法 (Cybersecurity Law), Article 39 — Cyberspace Administration of China, retrieved 2026-10-07 |
Sources verified by the 21YunBox China engineering team on 2026-10-07.
The question people search for is whether a site is blocked in China. It is the wrong question, and this is the measurement that shows why.
We requested 280 enterprise software and infrastructure sites from a probe inside mainland China, three times each, with a 60-second ceiling on every attempt. 840 requests. A run counts as complete only if the page finished loading; a run still going at 60 seconds is recorded as a failure rather than dropped.
The result
| Outcome | Sites | Share |
|---|---|---|
| Finished every attempt | 162 | 58% |
| Finished none | 96 | 34% |
| Finished some attempts | 22 | 8% |
Across every site that answered at all, the median time to first byte was 742ms (90th percentile 1,093ms). Among the sites that did finish, the median largest-contentful-paint was 2.1 seconds (90th percentile 4.7s).
Then the number that matters more than any of those:
Of the 96 sites that never finished, 66 answered. A first byte arrived, in most cases a paint was recorded, and the page still never completed. Only 30 produced no response at all.
Two different failures wearing the same result
Both groups look identical to a user — the page does not work — and they are entirely different problems.
The 30 that produced nothing are the ones people mean by “blocked”. The list is dominated by two companies: ten Google properties (Maps, Docs, reCAPTCHA, Tag Manager, Analytics, Cloud Functions, Hosted Libraries, the Fonts browsing site, YouTube, and support pages) and four from Meta and X (Facebook, Instagram, Twitter, X). Snapchat is there too. This is the well-understood part of operating in China, and it is not a delivery problem — a request to a destination that does not answer is not made to answer by moving where it comes from.
A useful contrast sits in the same dataset: bing.com/maps returned the fastest first byte of all 280 sites, at 66ms. Maps as a category is not the issue. The specific host is.
The 66 that answered and never finished are the ones nobody plans for, and they are twice as numerous. A connectivity check passes. A speed test reports a time. Monitoring that pings for a 200 stays green. And the page a visitor opens never becomes usable.
Some examples of how far that gap can stretch:
| Site | First byte | Paint | Completed |
|---|---|---|---|
| Authentisign | 108ms | 2.6s | 0 of 3 |
| Framer | 339ms | 2.6s | 0 of 3 |
| AWS Route 53 console | 375ms | 4.0s | 0 of 3 |
| Contentstack | 1,104ms | 28.0s | 0 of 3 |
| Freshdesk | 718ms | 14.2s | 0 of 3 |
Authentisign answered faster than any other site in the census and completed none of its runs. Contentstack painted after twenty-eight seconds — a number that exists only because a measurement tool kept waiting, not because anyone would.
Time to first byte does not tell you whether a page works. That is the single most useful thing in this dataset, and it is the reason a speed test taken from outside China, or a first-byte figure taken from anywhere, cannot answer the question a buyer is actually asking.
What we learned that no single site could show
Public asset CDNs: two of five worked
| Host | Result |
|---|---|
| cdnjs | 3 of 3 completed |
| Microsoft Ajax CDN | 3 of 3 completed |
| Google Hosted Libraries | no response at all |
| BootstrapCDN | 0 of 3 completed |
| Font Awesome | 0 of 3 completed |
All five are normally referenced from the document head, where the browser will not paint until they resolve. That position is what makes them disproportionately damaging — a page that references a failing script CDN does not load slowly, it stops.
The rule people reach for — “public CDNs don’t work in China” — is not supported. Three of five failed and two were fine. The workable advice is narrower and more useful: measure the host you actually depend on, or bundle the library into your own build and remove the question. Bundling is usually a smaller change than any delivery work.
A shared failure signature across one vendor — but not all of it
Four Adobe properties failed with ERR_HTTP2_PROTOCOL_ERROR rather than a timeout: Adobe Commerce, Magento, Marketo and Adobe Dynamic Tag Management. A protocol-level failure is a different diagnosis from congestion — it indicates the connection being interrupted in transit, and it is not improved by adding bandwidth or points of presence.
Adobe Fonts, measured in the same run, completed every attempt. Vendor-level generalisations do not survive measurement, which is why this census tests hosts rather than brands.
The same product category, opposite outcomes
Of nine podcast hosts, five produced no usable load and four completed every attempt. Of two loyalty apps for the same storefront platform, one completed every run and the other completed none. Learning platforms split the same way: one finished all three attempts at a 1.6-second paint, another finished none.
There is no category-level answer available here. That is not a rhetorical point — it means advice of the form “use a headless CMS” or “avoid embedded video” is not actionable, and the only thing that resolves it is measuring the specific host.
Even one vendor’s own hosts can disagree
Google Fonts is the cleanest example. fonts.googleapis.com, the stylesheet endpoint a page calls, answered 73 out of 73 times in a separate 12-hour sampling run at a median 111ms. fonts.google.com, the site a designer browses to choose a typeface, completed none of three attempts. Visitors receive the fonts; the designers cannot go shopping for new ones.
What we excluded, and why
Five hosts are not in the 280.
Three of them — fauna.com, stepzen.com and thin.dev — do not resolve from outside China either. Those services no longer exist. The fourth was a page in our own knowledge base carrying a wrong vendor URL; the domain it pointed at is not registered anywhere.
The fifth is the one worth dwelling on, because it nearly got published. edg.io failed from inside China with ERR_CERT_COMMON_NAME_INVALID — the only certificate failure in the run, and a genuinely diagnostic-looking signature. We had already written it up as a distinct finding when a check from outside China returned the same error. Edgio, which had acquired Edgecast, filed for Chapter 11 in September 2024 and its content delivery network went offline on 15 January 2025; Akamai bought the customer contracts but not the network. The certificate on that host is unmaintained because nobody is maintaining it, anywhere.
A dead product is not a China finding. Any failure with an unusually clean signature — a name that will not resolve, a connection closed immediately, a certificate that does not match — is worth verifying from outside the country before it is written down. We caught five this way, including one that would have had us publish that Google Fonts does not work in China while our own sampling data said the opposite.
Limits
- One probe, one city. A commercial cloud line in
cn-zhangjiakou. International transit from a datacentre is materially better than from a corporate broadband connection, so every figure here is a floor rather than a worst case. A real office would see worse. - Three attempts per site. Enough to separate “arrives” from “does not” reliably; not enough to be a precise latency figure. Where we sampled across a full day — twelve hours of third-party requests — one host’s time to first byte swung from a median of 493ms in its quietest hour to 1,086ms at the evening peak, a spread a three-run median cannot see.
- Vendor sites, not customer deployments. How a vendor’s own site behaves is not how a site built on it behaves. It is a signal about the host, not a verdict on the product.
- A 60-second ceiling is a choice. Some of these pages might complete at ninety seconds. No visitor waits that long, so we did not either.
Why the answer is not only about delivery
It would be convenient to end here, because everything above is a reachability problem and reachability is the part we can fix by changing where bytes are served from. But moving delivery inside mainland China is not only an engineering decision. Serving from inside the mainland is precisely what triggers the ICP filing requirement — the filing is issued to a mainland legal entity, it binds to your hosting and access arrangement, and access providers are prohibited from carrying an unfiled site.
So the two questions arrive together, and they are decided once, at architecture time: can the page arrive, and are you permitted to serve it from where it would arrive from. We measured what each of the available arrangements actually buys on the first question in four ways to deliver a website into China — including the arrangement that is inside China, correctly filed, and still failed to finish loading.
What we are measuring next
The same census from a Chinese office broadband connection rather than a datacentre line, which we expect to make every number here worse and the comparison less flattering to publish. We will publish it anyway. The method, including the eight ways we got it wrong first, is written up separately.
Measurements were run by the 21YunBox China engineering team on 28–29 August 2026 from a probe inside mainland China. Every site’s result — completion rate, median time to first byte, median paint and failure type — is recorded per host.
Frequently Asked Questions
If a site isn't blocked, why doesn't it load in mainland China?
Because reachability fails in two ways that look identical to a visitor. Far more sites answer and then never finish loading than are blocked outright — in our census, 66 of the 96 failures answered first. That stalled-mid-load group is a delivery problem, the kind a change in how the site is served can address; an outright-filtered host behind the Great Firewall is not improved by changing where the request comes from. Telling them apart needs a measurement taken from inside China that waits for the page to complete, not just for a first byte.
Does serving from inside mainland China make a foreign site work?
It can fix the stalled-mid-load failures, but it opens a second gate at the same moment. Serving a public site from inside the mainland is exactly what triggers the ICP filing requirement — the filing is tied to a mainland legal entity, and access providers may not carry an unfiled site — and it changes where your users' personal information sits, which PIPL governs. That is why reachability and permission are settled together, once, when the delivery is designed, rather than as two separate projects. Which obligations apply to you is a question for counsel.
Can 21YunBox help get our site working in mainland China?
Yes. Our China team can measure your site and its third-party dependencies from inside the mainland to separate the genuinely blocked hosts from the ones failing on delivery, then stand up compliant, ICP-filed, in-country delivery for the parts that need it — while mapping your ICP, PIPL cross-border and data-residency exposure for your entity, data and users. Get in touch to work through your specific case.