China CDN — onshore nodes change the ICP path
A China CDN is not a global anycast toggle. Onshore Mainland China nodes can force ICP with the access provider; overseas PoPs do not. Choose onshore CDN/edge versus overseas acceleration before you buy.
A China CDN is a termination decision — onshore Mainland China nodes versus overseas PoPs — not a global anycast toggle. Overseas edges do not become onshore by marketing copy. Public hostnames that land on Mainland China servers, or on licensed onshore CDN products, pull ICP filing onto the access-provider path. The YES fork is a vendor shortlist (Alibaba, Tencent, AWS China CloudFront, Azure China CDN, Cloudflare China Network, and peers) — not one brand’s SKU. Pick the path before you buy.
What a China CDN is for product teams
Hard names this stack decision will use:
- Overseas CDN PoPs ≠ onshore nodes — Global anycast that stops in Hong Kong, Japan, Singapore, or other edges outside Mainland China is not a China CDN with in-country termination. Latency and reliability still break at the network boundary when traffic never lands on Mainland China nodes.
- CDN edge China — Onshore PoPs that serve the public hostname from Mainland China. That is the CDN edge China teams mean when they ask for in-country TTFB — not “Asia” on a global map.
- China CDN ICP — Licensed onshore / Global acceleration regions typically require an ICP number before the product will accelerate the domain. Alibaba Cloud CDN — add a domain name states a Mainland China–only or Global acceleration region needs ICP; Global excluding Mainland China does not, and those requests from Mainland China are sent to Japan, Singapore, or Hong Kong. CDN limits add that this ICP requirement applies regardless of origin location, while changing CDN node IPs are not what you file as service IPs.
- Licensed onshore rails (shortlist, not a single brand) — Once you choose onshore termination, several products sit on the same ICP-bound path. Diff catalogs against the cloud family you already operate; do not treat any one vendor as the default China answer.
- Cache vs origin — Onshore cache helps cacheable static. Dynamic HTML, APIs, and origin fetch still pay the border if origin stays overseas. Latency design: SaaS performance in China.
- Hosting vs CDN — Full in-country origin is the Host in Mainland China Decision Map. This article is CDN/edge × ICP: when onshore nodes change the filing path versus hoping a global CDN reaches Mainland China.
- Common myth — “Turn on China on our global CDN.” Without onshore licensed nodes (and ICP where the SKU requires it), you still have an overseas edge — whether the brand is Cloudflare, AWS, Azure, or another global anycast.
Vocabulary first. Next: what must be true before any onshore SKU is useful.
What must be true before you buy onshore nodes
Missing any of these stops your product team before an onshore China CDN order is a real public path.
| Precondition | Why your process stalls |
|---|---|
| Termination verdict — onshore China CDN / edge vs overseas CDN / acceleration | Buying a “China” SKU that only uses overseas PoPs does not create in-country nodes |
| Public hostname named — which names claim Mainland China users | One global hostname cannot honestly tell both an unfiled overseas story and an onshore ICP story |
| Organizing entity or China landing partner path | ICP and most onshore CDN accounts expect a Mainland China filing subject |
| China CDN ICP plan aligned to the access provider | Onshore / Global acceleration regions and Mainland China origins generally will not publish without a valid ICP number |
| Origin locality named — onshore origin vs overseas origin behind onshore cache | Cache-only designs still fail chatty APIs; origin-in-China designs pull hosting + filing together |
| Licensed rail shortlisted — China-site CDN / China-partition edge, not a global anycast checkbox | Each rail has its own ICP, entity, and catalog gates; picking “the famous global brand” is not a China design |
| Content / dependency inventory | Onshore providers review content; blocked third-party hosts still break the shell |
Chinese-language filing consoles, provider questionnaires, and sales-led China packages are part of this floor. Product teams usually cannot finish onshore enablement from an overseas laptop alone.
How you obtain filing once DNS aims at Mainland China IPs: ICP filing — domain DNS path. Sequence with PSB: ICP and PSB filing. Commercial information-service patterns may later fork to ICP license (B25) — that is not a CDN SKU.
Onshore China CDN versus overseas CDN
Stages are product decisions — not console click-paths.
| Stage | Decision / outcome |
|---|---|
| 1. Name the job | Ordinary Mainland China users on a public hostname, or overseas-only reach with accepted latency |
| 2. Fork termination | Overseas CDN (global / HK / JP / SG PoPs) vs onshore China CDN / edge |
| 3. Check ICP trigger | Mainland China origin IPs, or onshore / Global CDN acceleration region → ICP with the access provider |
| 4. Place cache vs origin | Static onshore cache vs APIs/HTML that still need origin locality |
| 5. Shortlist a licensed rail | Alibaba / Tencent China-site CDN, AWS China CloudFront, Azure China CDN, Cloudflare China Network, or another licensed onshore SKU — match cloud family and ICP ops |
| 6. Cut DNS honestly | China-facing records must match the filed / onboarded endpoints — leftover overseas answers are a split brain |
| 7. Prove from Mainland China | TTFB, cache hit, API p95, third-party errors — not US synthetic only |
Licensed rails on the onshore path
These are options on the same YES fork, not a ranked bake-off. Depth for each cloud partition lives on the peer Guides — this table only names the CDN/edge SKU class.
| Licensed rail | What it is on this Decision Map | Peer / primary depth |
|---|---|---|
| Alibaba Cloud CDN | China-site acceleration regions; Mainland China–only or Global needs ICP; “Global excluding Mainland China” is not onshore | Add a domain · Alibaba Cloud China |
| Tencent Cloud CDN | China-site CDN catalog for onshore / China-facing acceleration — same ICP bind class as other Mainland China access providers | Tencent Cloud CDN · Tencent Cloud China |
| Amazon CloudFront (AWS China) | China-partition CloudFront (China service table lists Ningxia); not a region toggle on global CloudFront | CloudFront Developer Guide (China) · AWS China |
| Azure China CDN | China-specific CDN offering on the Azure China partition. Global Azure Front Door is not listed as the Mainland China edge rail — do not copy a Front Door design into China and expect parity | Azure China product list — CDN · Azure China |
| Cloudflare China Network | Partnered in-China path (JD Cloud data centers) with Enterprise + separate China package + ICP — one Cloudflare China CDN shortlist item, not the only YES answer. Depth: Cloudflare in Mainland China · China Network docs |
Honest patterns (not a brochure):
- Overseas CDN only — Keep termination outside Mainland China. No automatic ICP from “having users in China.” You accept cross-border latency and a weaker in-country story. Product-level “does this CDN work” maps belong on Landscape when you need brand-level research — this Decision Map stays on the ICP fork.
- Onshore cache, overseas origin — Improves static; dynamic still crosses the border. ICP may still apply because the acceleration region uses Mainland China nodes (Alibaba’s Global or Mainland China–only rule), even when origin is abroad.
- Onshore CDN + onshore origin — Strongest when China is a primary market. Hosting, CDN, and ICP bind on the same access-provider rail — see Host in Mainland China.
- China-partition or China-site edge beside a global CDN — Same product family name does not mean the same account, catalog, or ICP story. Treat AWS China CloudFront, Azure China CDN, and Cloudflare China Network as new rails, not dashboard checkboxes on the global footprint.
Why origin, cache, and ICP bind each other
Overseas PoPs treated as onshore → wrong SLO and wrong filing. Hong Kong or “Asia” edges are not Mainland China nodes. Architecture reviews that assume anycast already terminates in-country waste a quarter until someone measures from Mainland China ISPs.
Onshore China CDN without ICP → blocked or non-compliant publish. Alibaba Cloud’s ICP filing note for CDN (Use Alibaba Cloud CDN) is explicit: website domains that resolve to a server in Mainland China need ICP; Mainland China or Global CDN acceleration needs ICP on the accelerated domain. Partnered and China-partition edges (including Cloudflare ICP concepts for China Network) make ICP a hard gate too. Do not re-teach the full filing pack here — use the ICP domain-DNS Guide.
Cache success mistaken for origin locality → APIs still slow. A hot CSS file on an onshore PoP does not move login or checkout. SaaS performance in China is the journey map; this Guide only forces the CDN/ICP fork that those journeys sit on.
Global SKU mistaken for China-partition / China-site CDN → sales and filing never start. Pro/Business Cloudflare cannot reach China Network PoPs; global CloudFront is not AWS China CloudFront; global Azure Front Door is not Azure China CDN. Treat each as a new rail with entity and ICP work.
One hostname, two stories → DNS and footer lie. An ICP number in the footer with leftover overseas A/CNAME answers, or an onshore package enabled on a zone that still serves most users from overseas-only cache, is a split-brain. Pick overseas acceleration or onshore nodes with filing.
Unfiled Mainland China origin behind a pretty CDN → access provider still blocks. Filing duty follows the public service IPs and the CDN region you enabled — not the slide that says “edge.”
Where China CDN programs stall
- SKU naming — “China,” “Global,” and “Global excluding Mainland China” are different products. The last one blocks Mainland China nodes on Alibaba Cloud CDN by design.
- Single-vendor tunnel vision — Funding only Cloudflare China Network (or only one China cloud CDN) because the global account already exists skips Alibaba / Tencent / AWS China / Azure China options that may fit the hosting partition better.
- Entity gap — No PRC organizing subject means no ICP pack, which means no onshore / Global acceleration region and no China-partition edge onboarding.
- Content vetting — Onshore providers and partnered China networks review content. Empty sites, illicit categories, and unsigned attestations fail before the first cache HIT.
- Catalog gaps — China-partition and partnered catalogs rarely carry every global edge feature. Diff the bill of materials before promising Workers-class or Front Door-class logic at the China edge.
- Third-party hosts — Onshore HTML still fails if fonts, analytics, or video live on blocked overseas domains. An onshore CDN accelerates your onboarded zone; it does not rewrite the rest of the internet.
- Measurement theater — US/EU APM stays green while Mainland China users wait on origin fetch. Fund China vantage checks with the SKU.
China landing partner. Most product teams need a China landing partner to bind ICP, operate the chosen onshore CDN rail, and keep DNS honest — not another global CDN tutorial. Your team still owns the onshore-versus-overseas verdict and the vendor shortlist; the partner path makes filing and licensed-node rails executable when those ops are not already in-house.
What we can offer?
Onshore China CDN nodes change the ICP path; overseas PoPs do not. Chinaready maps that fork onto a hostname you can actually publish — without locking you to a single CDN brand:
- China Readiness Assessment — Lock onshore versus overseas termination, which hostnames claim Mainland China users, and which licensed rails (Alibaba, Tencent, AWS China CloudFront, Azure China CDN, Cloudflare China Network, or peers) are even in scope.
- China Access Acceleration — Design the CDN edge China path: onshore cache vs overseas origin, third-party cleanup, and measurement from Mainland China — without pretending global anycast is in-country.
- China Product Hosting — Place origins on filed Mainland China termination when cache-only is not enough, and keep CDN + host + ICP on one access-provider story.
- Mobile App Distribution — Keep app API hosts on the same China CDN / origin plan so a filed web edge does not leave mobile traffic on an unfiled overseas hostname.
Contact us when the next step is choosing onshore nodes versus overseas CDN — and shortlisting which licensed rail fits — before the invoice lands.
Frequently asked questions
Is an overseas CDN the same as a China CDN?
No. Overseas PoPs (including Hong Kong, Japan, or Singapore edges) are not Mainland China onshore nodes. A China CDN that terminates on onshore nodes is a different architecture — and often a different ICP path — from hoping a global CDN reaches Mainland China users.
When does China CDN ICP filing apply?
When public DNS for the hostname aims at Mainland China hosting, or when you enable an onshore / Global acceleration region on a licensed Mainland China CDN product. Alibaba Cloud CDN documents that Mainland China–only or Global regions require an ICP number regardless of where the origin sits; Global excluding Mainland China does not. Filing depth lives in the ICP domain-DNS Guide — this Decision Map is when the CDN SKU changes that path.
Which licensed rails sit on the onshore China CDN path?
Treat the YES fork as a shortlist, not a single vendor. Common options include Alibaba Cloud CDN and Tencent Cloud CDN on China-site catalogs, Amazon CloudFront in AWS China (Ningxia in the China service table), Azure China CDN (global Azure Front Door is not the Mainland China rail), and Cloudflare China Network as a partnered in-China path. Each still needs ICP and entity rails with its access provider — pick by cloud family, catalog fit, and ops capacity, not by marketing “China” labels.
Does onshore cache replace an origin in Mainland China?
No. Edge cache can improve static TTFB for cacheable objects. Dynamic HTML, APIs, websockets, and origin fetch still cross the border if the origin stays overseas. Decide cache vs origin locality as two gates, then measure from Mainland China — see SaaS performance in China.
Can our product team finish onshore China CDN without a China landing partner?
Usually no. ICP bind, Chinese-language provider consoles, content review, and onshore account rails are Mainland China ops most teams lack in-house. Keep the architecture decision in-house; execute filing and enablement with local ops or a China landing partner.
