Serving a Site in China: What the Great Firewall Actually Blocks

A site hosted outside China is usually not blocked in China by name. It is unreachable because the edge network serving it is filtered, because DNS resolution for the domain is poisoned, or because the TLS handshake to an overseas endpoint is slow enough to time out. The distinction matters, because the three causes have completely different fixes, and only one of them is solved by changing hosting provider.

The reports look identical from outside: the site loads for everyone else and not for users in mainland China, and there is no error anyone can screenshot usefully. Diagnosing which of the three mechanisms is responsible is most of the work, and it is doable without being in the country.

Table of contents

• The site is probably not the thing that is blocked
• Telling slow from blocked, from outside the country
• The third-party assets nobody remembers
• The ICP licence, and what it actually gates
• Options that do not require a Chinese entity
• Deciding whether it is worth it
• How this fits the rest of the stack
• FAQ

The site is probably not the thing that is blocked

Filtering operates at several layers, and almost none of them target individual small sites.

• DNS. Queries for certain domains return incorrect answers, so the browser connects to nothing useful. This is domain-level and is the most common cause of a hard, immediate failure.
• IP. Entire address ranges can be unroutable. Because edge networks use anycast ranges shared by enormous numbers of sites, a range-level block affects every site on it regardless of content.
• SNI inspection. The hostname in the TLS handshake is visible in plaintext, and connections can be reset based on it. Symptom: a connection that opens and then dies mid-handshake.
• Bandwidth and latency. Nothing is blocked at all, but international transit is congested enough that a page with many round trips takes long enough to be treated as broken by users.

The fourth is the one that surprises people, and for most sites hosted on an overseas edge it is the actual explanation. Nothing is blocked. Everything is just slow enough that it does not matter.

Telling slow from blocked, from outside the country

You do not need to be in China to get a reasonable diagnosis, and a colleague on a VPN is not a valid test because the VPN is the thing being routed around.

1. Use a third-party firewall test service that runs the request from several nodes inside mainland China. Run it against the apex domain, the www subdomain and one asset URL, because the answers can differ.
2. Compare a DNS-only result against a full page load. If DNS resolves to a plausible address but the page never loads, the block is not at the DNS layer.
3. Test an asset on a different hostname. If the HTML loads and the fonts or scripts do not, the site is fine and a third-party dependency is the problem.
4. Check timing rather than just success. A page that loads in eighteen seconds is technically reachable and practically broken.

That third step catches the single most common self-inflicted version of this problem, which has nothing to do with the host at all.

The third-party assets nobody remembers

A large share of sites that appear blocked in China are perfectly reachable, and are hanging on a request to an overseas font, analytics, tag manager or map service that is itself filtered.

The failure is worse than a missing asset because of how browsers handle blocking resources. A stylesheet or a synchronous script that never resolves does not fail fast; it waits for a timeout, and the page stays blank for the duration.

The fix is entirely within your control and worth doing regardless of the China question:

• Self-host fonts instead of loading them from a third-party font service. This is faster everywhere and removes a render-blocking external dependency.
• Load analytics and tag managers asynchronously, and make sure the page renders without them.
• Bundle scripts rather than pulling them from public CDNs at runtime.
• Give every external embed a fallback and a timeout, particularly maps and video players.

A site with no render-blocking third-party requests frequently goes from unusable to merely slow in China, without changing hosting at all.

The ICP licence, and what it actually gates

An ICP filing is a registration with the Chinese authorities that permits a site to be served from infrastructure inside mainland China. It is the gate on domestic hosting, not a permission slip for overseas hosting.

What is worth knowing before assuming it is the answer:

• It generally requires a registered Chinese business entity. A foreign company usually cannot file directly.
• It applies to the domain, and the filing is tied to the hosting provider inside China. Changing provider means updating the filing.
• The process takes weeks, not days, and involves document verification.
• Commercial sites need a different and more involved classification than purely informational ones.

So the honest framing is this: serving from inside China requires a licence, and the licence requires a legal presence. If you have neither, domestic hosting is not on the table, and the real question becomes how good the overseas experience can be made.

Options that do not require a Chinese entity

In rough order of effort:

1. Remove every render-blocking third-party request. Free, fast, and helps everywhere.
2. Reduce round trips. Inline critical CSS, cut the number of separate origins the page touches, and make the initial HTML useful on its own. Latency is the constraint, so fewer sequential requests is worth more than smaller ones.
3. Serve from a nearby region. Hong Kong, Singapore, Tokyo and Seoul all reach mainland users considerably better than a North American or European origin, and none of them require a filing.
4. Use a CDN with peering into mainland networks. Several international providers offer this, with varying results and without needing an ICP licence for the overseas endpoint.
5. Build a separate mainland deployment. A distinct domain, a Chinese entity, an ICP filing and a domestic host, kept in sync from the same repository.

Steps one and two are worth doing before any of the others, because they are the only ones that cost nothing and they frequently produce the largest single improvement.

Deciding whether it is worth it

The last option, a genuinely separate mainland deployment, is a business decision rather than a technical one. It means a legal entity, an ongoing filing obligation, a second content pipeline and a second set of operational surface, all for one market.

That is straightforwardly correct for a company selling into China and straightforwardly disproportionate for a company that has noticed some traffic from there. The middle ground, a regional origin plus a page that does not depend on filtered third parties, covers most of the realistic cases.

Whatever you choose, measure it. Run the firewall test before and after each change and keep the numbers, because otherwise the only feedback loop is people reporting anecdotally that the site feels better, which is not a measurement and is not a basis for spending money.

How this fits the rest of the stack

Most of the improvements described here are properties of the deployment rather than of the host: fewer origins, self-hosted assets, a region close to the audience and a build that produces a page which renders on its own. Costing that shape is worth doing up front, and the RunxBuild hosting calculator lays out the pieces separately so a regional deployment can be compared with the current one honestly. Static sites on RunxBuild build from a repository with custom domains, headers, redirects and rewrites configured per site, and 120GB of bandwidth included, which covers the self-hosted-assets approach without a separate CDN contract.

Useful related references:

• Django on Netlify: Why It Does Not Work, and What To Do Instead
• Branch Deploy on Netlify: How It Works and When to Use One
• Netlify Templates: What Starter Templates Give You and What They Do Not
• Services on RunxBuild

FAQ

Why is my site blocked in China when it has no political content?

It is usually not blocked for its content. The most common causes are the shared edge network address range being filtered, a render-blocking third-party asset that is itself unreachable, or international transit latency making the page time out. Content-based blocking of a small site is comparatively rare.

Do I need an ICP licence to be accessible in China?

Not to be accessible. You need one to host inside mainland China. A site hosted overseas can be reachable without any filing, though usually slower. The licence requires a registered Chinese business entity, which is the real barrier for most foreign companies.

How can I test whether my site works in China?

Use a firewall test service that runs requests from nodes inside mainland China, and test the apex domain, the www subdomain and individual asset URLs separately. Do not test through a VPN, because the VPN routes around the exact mechanism you are trying to measure.

Will a CDN fix access from China?

It can help substantially if the CDN has peering into mainland networks, but a general international CDN may make no difference or may be the problem, because shared anycast ranges are filtered as a whole. Check whether the provider specifically advertises mainland performance.

What is the cheapest improvement I can make?

Removing render-blocking third-party requests. Self-host fonts, load analytics asynchronously, and make sure the page renders without any external script. This costs nothing, improves performance everywhere, and often turns a blank page into a working one for users in China.