How to Serve Users in China Without an ICP Filing

Quick answer
Host outside mainland China — Hong Kong, Singapore, Japan — and no filing is required for that hosting.
Put a CDN in front so Chinese users terminate at the nearest overseas edge instead of the origin region.
Keep everything that must not be served from inside China on the overseas side; do not enable mainland nodes.
Measure from real mainland locations, not from your own machine, because cross-border routing varies by province and carrier.
Accept the trade: a small latency penalty for southern China and a larger one further north, in exchange for no entity requirement.

Can you serve Chinese users without an ICP filing?

Yes, provided nothing is served from a node physically inside mainland China. The filing requirement attaches to mainland hosting, not to the users’ location, so a site hosted in Hong Kong with a global CDN can be visited from Beijing without any registration. What you are choosing is latency and routing quality, not legality: serving users in China from outside is a normal, common architecture.

The constraint to respect is that no part of the delivery path may land on a mainland server. That includes origin, cache, object storage, and any serverless function used to render pages. If a component runs in a mainland region, that component needs a filing, and a mixed architecture is the way people accidentally create the obligation they were avoiding.

Step 1 — choose an origin region outside the mainland

Pick a region with strong cross-border connectivity to China and good peering to the rest of your audience. Hong Kong is the usual first choice for a China-facing service; Singapore serves Southeast Asia and southern China well and is a strong hub for the wider region; Tokyo and Seoul are useful for northern China and Korea and Japan. Avoid regions that are geographically close but poorly peered, where traffic takes a long detour.

Keep the origin small and the cache generous. Latency is dominated by the round trip between the edge and the origin, so the less the edge has to ask the origin, the better the experience. A region with good links is wasted if every request is a cache miss.

Step 2 — put a CDN in front and disable mainland nodes

Terminate users at the nearest overseas edge: Hong Kong for southern China, and Singapore or Tokyo as secondary. Global CDNs publish their network maps, and the presence of a Hong Kong point of presence is the single most useful signal for mainland performance. Make sure China acceleration or any mainland partner product is explicitly off, so no node inside the mainland serves your domain.

Then tune for the cross-border path. Enable HTTP/2 or HTTP/3, keep the TLS handshake short with modern ciphers, compress text, and cache aggressively. Cross-border connections are more sensitive to handshake cost than domestic ones, so every avoided round trip is worth more here than in a domestic deployment.

# Check which edge a Chinese city is served from, and the added latency.
# Run from a mainland vantage point (or a measurement service), not from your laptop.
curl -s -o /dev/null -w 'dns %{time_namelookup}s  connect %{time_connect}s  tls %{time_appconnect}s  total %{time_total}s\n' \
  https://example.com/

# Cache behaviour: confirm the edge answers, not the origin.
curl -sI https://example.com/ | grep -i -E 'cf-cache-status|age|x-cache'

Step 3 — measure from where users actually are

Cross-border routing is not uniform. A test from Shenzhen and a test from Chengdu can differ by more than a hundred milliseconds, and the same city can vary between carriers. Use a measurement service with agents in mainland China, or ask real users for timings, rather than extrapolating from a Hong Kong test box. Track p50 and p95 separately; the tail is where the unpleasant surprises live.

Compare the result against the alternative. If the measured penalty is modest and your traffic mix is not dominated by China, the outside-the-mainland architecture is settled permanently. If the penalty is large and China is a major segment, that is the evidence for revisiting the entity route, with a number attached instead of an intuition.

Where this bites vibecoders
The failure mode is architectural drift: a generated plan starts with an overseas region and then, in a later iteration, suggests putting a render function or a database in a mainland region for latency or cost, without noting that this creates a filing requirement for the whole service. The obligation is per serving location, so a single mainland component changes the compliance picture. Keep the deployment path free of mainland regions, or decide deliberately to file.

Where AI coding assistants get this wrong

Recommending a mainland region ‘just for the database’ without flagging the filing requirement it creates.
Enabling China acceleration by default and hitting a configuration block.
Reporting latency from a local machine as representative of users in China.
Ignoring cache hit ratio, which matters more on cross-border paths than on domestic ones.
Treating Hong Kong and a mainland gateway region as interchangeable.
Failing to measure before deciding that the overseas route is good enough.

Checklist

Confirm no origin, cache, or function runs in a mainland region.
Choose an origin region by peering to China, not by map distance.
Front it with a CDN that has a Hong Kong point of presence.
Ensure mainland acceleration products are disabled.
Tune cache hit ratio, HTTP version, and TLS handshake cost.
Measure p50 and p95 from several mainland cities and carriers.

FAQ

Is it legal to serve Chinese users from a server outside China?

Yes. The ICP filing requirement attaches to hosting inside mainland China, not to the nationality of the users. Serving those users from Hong Kong, Singapore, or a global edge network does not require a filing. Other obligations, such as data protection rules for personal information you collect, are separate questions.

How do I stop my CDN from routing to mainland nodes?

China acceleration is normally a separate product that has to be enabled per domain and requires a filing, so leaving it off keeps traffic on overseas edges. Confirm in the provider’s configuration that no mainland acceleration or partner network is active for the domain, and verify by checking which edge answers a request from China.

Which overseas region is fastest for China?

Hong Kong is generally the best connected to the mainland, followed by Tokyo and Singapore for different parts of China and for the rest of Asia. The ranking depends on the province and carrier involved, so the only reliable answer comes from measuring with agents in the locations your users are in.

Will Chinese users have a bad experience on an overseas host?

Southern China is usually comfortable, with added latency in the low tens of milliseconds. Users further north or inland see more, and the tail can be worse during congested periods. For a global product this is often an acceptable trade for avoiding a mainland entity entirely; for a China-first product it is the signal to reconsider.