The two gates, in the words of the platforms and providers themselves
| Fact | Primary source |
|---|---|
| Gate 1 is structural, not a tuning problem. Major global platforms state plainly that they have no infrastructure in the mainland — for example: "Vercel does not have servers or CDN nodes in mainland China" — and that China's network controls may block or throttle foreign domains. | Vercel — Accessing Vercel-hosted sites from mainland China |
| The requirement follows delivery, not only server location — keeping the origin abroad and pointing a China CDN at it does not avoid it: it applies "whether the site is hosted on a server in Mainland China or delivered to visitors in China through a CDN", and without a licence "your site can be shut down." | Cloudflare — China Network: Internet Content Provider (ICP) |
| Gate 2 is triggered by server location, not by company nationality: "ICP filing applies only to servers located in the Chinese mainland", and services "with domain names resolving to servers in the Chinese mainland must obtain an ICP filing." | Alibaba Cloud — ICP filing prerequisites |
| The filing binds to the access provider, not only the domain: "If you already have an ICP filing from another provider and want to resolve your domain name to an Alibaba Cloud server in the Chinese mainland, you must add Alibaba Cloud as a service provider." | Alibaba Cloud — ICP filing prerequisites |
| A filing left without a current access provider is cancelled, not merely stale: after removing a provider you must "add a new service provider promptly. Otherwise, your website or app may be classified as an empty shell." | Alibaba Cloud — ICP filing prerequisites |
| Even vendors that recommend against third-party layers acknowledge that the in-country route carries the regulatory gate — describing customers who "maintain a dedicated version of their site on local infrastructure within mainland China, which requires an ICP license and compliance with local regulations." | Vercel — Accessing Vercel-hosted sites from mainland China |
Sources verified by the 21YunBox China engineering team on 2026-09-01.
There are two gates, and they are independent
Almost every plan for serving mainland China treats this as one problem — make the site faster — and it is two. They are separate gates, they are failed separately, and passing one tells you nothing about the other.
Gate 1 — performance. Your origin sits outside mainland China, so every request crosses a border that is congested and filtered. The symptom users report is not “slow” but inconsistent: the same page is tolerable in the morning and unusable in the evening.
Gate 2 — the filing. Anything actually served from inside mainland China requires a valid ICP filing, and that filing requires a mainland China legal entity.
The trap is in how they interact. The fast path and the filed path are the same path. Delivery from inside China is what removes the border crossing — and it is also precisely what triggers the filing requirement. So the arrangements that avoid the filing are, without exception, the ones that keep the border crossing.
That is why a setup can be genuinely fast and still be the wrong answer for an enterprise: speed achieved outside the filing regime is speed you do not have permission to keep.
Gate 1: why the border crossing is the whole problem
A CDN’s job is to put a copy of your content physically closer to the user. That works everywhere in the world, and it works in China only if the points of presence are actually in China.
This is where most plans quietly fail. Hong Kong and Singapore feel close on a map and sit on the far side of the Great Firewall. Serving mainland users from there does not shorten the crossing; it just moves where the crossing ends.
Three things then break, separately:
- The crossing itself — high and, more importantly, variable latency.
- The domain can be filtered — platform-provided subdomains are more exposed than a custom domain on the same infrastructure.
- Everything the page pulls in fails on its own schedule — fonts, consent banners, analytics, embedded video, form endpoints. The page can “mostly load” and still convert nothing, because on a lead-capture site the form is the conversion event.
Point 3 is the one that surprises teams. A CDN accelerates what you own. It does nothing for the dozen third-party services your page calls, and those have no mainland presence either.
Gate 2: what the filing actually binds to
Three properties of the ICP filing decide most project schedules, and all three are commonly discovered late.
It is triggered by where the server is, not by who you are. A site hosted entirely abroad needs no filing — which is also exactly why it is slow.
It requires a mainland China legal entity. A foreign company cannot file in its own name. This is the single most common hard blocker, and it is a company-structure problem rather than a technical one.
It is bound to your hosting/access provider, not only to your domain. Moving delivery to a new provider means updating the filing to name that provider. A filing left without a current provider is not merely stale — it can be reclassified as an “empty shell” and cancelled.
That last property is why “we already have an ICP” is not the reassurance it sounds like. The filing has to match the infrastructure that is actually serving the traffic today.
The four paths, compared on both gates
| Passes Gate 1 (performance) | Passes Gate 2 (filing) | Effect on your global stack | |
|---|---|---|---|
| Do nothing, tune what you can | No — border crossing remains | Not applicable — nothing served in China | None |
| Near-shore CDN (Hong Kong / Singapore) | Partly — static assets only; APIs and forms still cross | Not applicable — and that is the point people miss | None |
| Rebuild a separate site inside China | Yes | Yes — you hold the filing | A second codebase and content workflow, permanently |
| China delivery layer over the existing build | Yes | Yes — filing attaches to the delivery layer | None — your existing platform stays the origin |
Near-shore is the option most teams try first and the one that disappoints most reliably. It is attractive precisely because it needs no filing, and it needs no filing precisely because it never enters China.
The rebuild genuinely works and is genuinely expensive — not in infrastructure but in operations. A second codebase, a second content workflow, and a marketing team that publishes twice and has to remember which market gets what.
So do we need a CDN, or something else?
If your site is static, your audience is tolerant, and nothing on the page calls a third party, a China-capable CDN plus your own filing is a complete answer. That is a real scenario and it is worth saying so.
It stops being a complete answer when any of these are true, which for an enterprise site is usually all of them:
- The page calls services that are blocked or slow in China — analytics, fonts, consent, video, marketing-automation forms.
- Content is dynamic or personalised, so caching a copy is not enough.
- You have no mainland entity, so the filing has no one to attach to.
- Delivery is changing, so an existing filing has to be updated in step with it.
Where 21YunBox sits
We are the layer that passes both gates without changing your global platform. Your existing CMS, build pipeline and publishing workflow stay exactly as they are and remain the source of truth. We put compliant delivery inside mainland China in front of them, rewrite the blocked third-party calls individually so the conversion path completes, and our compliance team holds or updates the ICP filing so that the technical and regulatory halves match.
That last clause is the part worth checking in any proposal you receive, from us or anyone else: a filing made against the wrong infrastructure has to be redone, and it sits on the critical path.
Link: China ICP License for Websites
