Netlify and China — what works, where the risks are
A measured look at Netlify reachability from Mainland China, based on a feature-rich demo deployment, synthetic probes, browser tests, and a practical China delivery model.
Netlify is a mature platform for shipping modern frontend applications. For China, the useful question is not whether Netlify is categorically “blocked” or “available”. The better question is whether a specific Netlify application can be reached, loaded, and operated safely enough for Mainland China users.
Based on our current tests, the practical answer is:
Netlify is usually reachable from Mainland China. Static hosting, assets, and several dynamic Netlify features can work. The more material risks are DNS variability, third-party dependencies, cross-border latency, and compliance for China-facing business use.
Two scope notes before the evidence. First, every result below was measured against a shared *.netlify.app subdomain. A production custom domain can behave differently for DNS and domain-level risk and must be tested separately. Second, the demo page payload is intentionally heavy (~12–14 MB) to stress-test resource delivery, so the cross-border load times reflect that weight, not a Netlify defect.
This guide summarizes the evidence from a real demo deployment, shows how to reproduce the probes yourself, and outlines the practical China delivery options.
1. Netlify is usually reachable
Test target
The test target was a Netlify demo application:
https://steady-marshmallow-cb991f.netlify.app/
This was not only a static page. The demo was designed to exercise a broad set of Netlify capabilities:
- Static hosting and CDN-delivered assets.
- Image CDN transforms.
- Redirects and rewrites.
- Netlify Functions.
- Netlify Edge Functions.
- Background and scheduled function paths.
- Form submission.
- Identity-related endpoints.
- Netlify API access from a server-side path.
- A diagnostic endpoint at
/__wherereporting the Netlify runtime region and request metadata.
The public Stack Break Lab result page is available here:
https://stackbreak.launchready.cn/public/results/netlify.html#netlify-latency
How we judged availability
We treated a path as reachable when it returned the expected HTTP class or expected protocol result within the probe threshold. For product capability probes, this included frontend paths, backend API paths, and raw transport checks. For resource probes, this included page HTML, transformed images, JavaScript, and raw assets of different sizes.
We use the same verdict vocabulary as the rest of this series:
| Verdict | Meaning |
|---|---|
| Reachable | Probe completes within the threshold and returns the expected HTTP class or protocol result |
| Degraded | Connects, but slow or intermittent across samples |
| Blocked | Connection timeout, TLS failure, or hard reset within the probe window |
This vocabulary matters because a site can be “reachable” at the HTML level while still failing on runtime dependencies. The demo therefore included both page resources and Netlify dynamic features.
Stack Break Lab capability probe
A Mainland China cloud runner executed a capability probe against the Netlify demo. The result was:
| Probe group | Result |
|---|---|
| Total product capability probes | 23 |
| Reachable product capability probes | 23 |
| Failed product capability probes | 0 |
| Frontend probes | 11 / 11 reachable |
| Backend probes | 5 / 5 reachable |
| Transport probes | 7 / 7 reachable |
| Generated at | 2026-06-25 09:34:39 UTC |
Representative results:
| Path | Product / probe | HTTP | Total time | Verdict |
|---|---|---|---|---|
| Frontend | Static hosting (CDN) | 200 | 0.906 s | Reachable |
| Frontend | Image CDN transform | 200 | 0.729 s | Reachable |
| Frontend | Rewrite to function | 200 | 1.143 s | Reachable |
| Frontend | Function helloProbe | 200 | 0.535 s | Reachable |
| Frontend | Function + Blobs stamp | 200 | 1.232 s | Reachable |
| Frontend | Edge Function banner | 200 | 2.226 s | Reachable |
| Frontend | Background Function | 202 | 0.548 s | Reachable |
| Frontend | Scheduled Function | 200 | 1.113 s | Reachable |
| Frontend | Form submission | 200 | 0.632 s | Reachable |
| Frontend | Identity settings | 200 | 0.490 s | Reachable |
| Backend | Netlify API current user | 200 | 1.352 s | Reachable |
| Backend | Netlify API site lookup | 200 | 2.168 s | Reachable |
| Backend | API deploys list | 200 | 1.067 s | Reachable |
| Transport | Netlify dashboard | 200 | 0.421 s | Reachable |
| Transport | REST API unauthenticated check | 401 | 1.137 s | Reachable |
| Transport | DNS netlify.app | DNS | 0.059 s | Reachable |
| Transport | Deployed site edge | 200 | 0.249 s | Reachable |
The backend REST API probe returning 401 is not a failure in this context. It proves that the host was reachable and returned an expected unauthenticated response.
Stack Break Lab page-resource probe
A second snapshot measured the demo site’s page resources and edge region.
| Metric | Result |
|---|---|
| Total measured resources | 13 |
| Reachable resources | 13 |
| Failed resources | 0 |
| Total measured payload | 14.1 MB |
| Netlify runtime region | aws-ap-southeast-1 |
| Detected probe geography | Beijing, China |
| Generated at | 2026-06-25 10:40:23 UTC |
Representative resource results:
| Resource | Type | HTTP | Size | TTFB | Total time | Throughput |
|---|---|---|---|---|---|---|
| HTML document | Endpoint | 200 | 15.8 KB | 0.845 s | 0.927 s | 0.14 Mbps |
Edge region /__where | Endpoint | 200 | 384 B | 0.276 s | 0.276 s | 0.01 Mbps |
| Function hello | Endpoint | 200 | 97 B | 1.128 s | 1.144 s | 0.00 Mbps |
| Edge Function banner | Endpoint | 200 | 129 B | 0.277 s | 0.277 s | 0.00 Mbps |
| Identity widget JS | Endpoint | 200 | 240 KB | 0.309 s | 0.645 s | 2.98 Mbps |
| Image CDN w=400 | Image CDN | 200 | 274 KB | 0.737 s | 1.154 s | 1.90 Mbps |
| Image CDN w=800 | Image CDN | 200 | 750 KB | 0.638 s | 1.140 s | 5.26 Mbps |
| Raw asset ~1 MB | Static asset | 200 | 999 KB | 0.639 s | 1.189 s | 6.72 Mbps |
| Raw asset ~3 MB | Static asset | 200 | 3.1 MB | 0.630 s | 2.619 s | 9.39 Mbps |
| Raw asset ~6 MB | Static asset | 200 | 6.0 MB | 0.757 s | 3.533 s | 13.59 Mbps |
The important observation is that the runtime region was overseas, specifically aws-ap-southeast-1. This means the test did not prove the existence of a Mainland China Netlify edge. It showed that an overseas Netlify edge path was reachable from Mainland China.
Nationwide HTTP probe
We also reviewed a one-off nationwide HTTP probe across 137 Mainland China monitoring nodes. This probe tested the same Netlify demo URL as an HTTP target.
| Metric | Result |
|---|---|
| Probe nodes | 137 |
| HTTP 200 responses | 131 |
| Non-200 / probe exceptions | 6 |
| HTTP success rate | 95.6% |
| Resolved edge IPs | 13.215.239.219, 52.74.6.109 |
| Total time P50 | 443 ms |
| Total time P75 | 803 ms |
| Total time P90 | 1,273 ms |
| Total time P95 | 2,260 ms |
| TTFB P50 | 88 ms |
| TTFB P75 | 301 ms |
| TTFB P90 | 594 ms |
| TTFB P95 | 739 ms |
Among successful HTTP 200 probes:
| Metric | HTTP 200 only |
|---|---|
| Count | 131 |
| Total time P50 | 443 ms |
| Total time P90 | 1,218 ms |
| Total time P95 | 1,843 ms |
| Total time > 1s | 20 nodes |
| Total time > 2s | 6 nodes |
| TTFB P50 | 90 ms |
| TTFB P90 | 625 ms |
| TTFB P95 | 742 ms |
The exceptions were concentrated in a small number of carrier/location combinations. They included timeout-like or platform-specific probe error codes rather than application-level HTTP 4xx or 5xx responses. This points to regional or carrier variability, not a uniform Mainland China block.
Browser test evidence
HTTP probes are useful, but they do not fully represent the browser experience. We also reviewed browser-based tests for the same demo. The worst observed runs still returned HTTP 200 and reported zero failed page elements, but full page completion was slower because the browser loaded a larger page payload.
The two worst browser test screenshots showed:
| Location / carrier class | HTTP | Document time | TTFB | FCP | DOMContentLoaded | Load complete | Payload | Failed elements |
|---|---|---|---|---|---|---|---|---|
| Beijing / fixed-line node | 200 | 714.8 ms | 712.4 ms | 757.1 ms | 1,232.2 ms | 4,139.2 ms | 12.3 MB | 0 |
| Shanghai / fixed-line node | 200 | 1,022.8 ms | 817.3 ms | 1,101.8 ms | 1,530.7 ms | 5,282.7 ms | 12.3 MB | 0 |
The browser test flagged assertion failures because the test threshold required several browser milestones to complete under one second. That is a strict threshold for a cross-border page with a 12.3 MB payload. The failures should be interpreted as performance threshold misses, not as evidence that the Netlify site was unavailable.
Reproduce these probes
The results above are not meant to be taken on trust. Run the same checks from a Mainland China host — a cloud node in a cn- region, or a real device on a domestic carrier — and replace the demo URL and the function/image paths with your own. Carrier, province, and time of day will move the numbers.
Static hosting (page HTML):
curl -sS -o /dev/null \
-w "static code=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n" \
--connect-timeout 10 --max-time 30 \
"https://steady-marshmallow-cb991f.netlify.app/"Runtime region (/__where diagnostic endpoint):
curl -sS \
-w "\nwhere code=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 30 \
"https://steady-marshmallow-cb991f.netlify.app/__where"Netlify Function (replace the function name with yours):
curl -sS \
-w "\nfunction code=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 30 \
"https://steady-marshmallow-cb991f.netlify.app/.netlify/functions/hello"Image CDN transform (replace the source path and width):
curl -sS -o /dev/null \
-w "imgcdn code=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 30 \
"https://steady-marshmallow-cb991f.netlify.app/.netlify/images?url=/sample.jpg&w=800"DNS resolution (run separately from HTTP, and from more than one city/carrier):
dig +noall +stats +answer steady-marshmallow-cb991f.netlify.appA reachable result returns the expected HTTP class within the threshold; a blocked result times out at code=000. Test your own custom domain the same way — a shared netlify.app result does not guarantee custom-domain behavior.
At a glance
Use this as a planning summary; the measured tables above are the evidence. Carrier, province, and time of day move these outcomes.
| Netlify capability | Tested verdict (this run) | Main China risk |
|---|---|---|
| Static hosting (CDN) | Reachable | Cross-border latency on heavy pages |
| CDN-delivered assets | Reachable | Throughput scales with payload weight |
| Image CDN transforms | Reachable | Cross-border latency |
| Redirects / rewrites | Reachable | — |
| Netlify Functions | Reachable | Latency; relative-path routing under a China domain |
| Edge Functions | Reachable | Cross-border latency |
| Background / scheduled functions | Reachable | — |
| Form submission | Reachable | — |
| Identity endpoints | Reachable | Cookie domain / SameSite under a China domain |
| Netlify API (server-side) | Reachable | — |
DNS (netlify.app) | Reachable | Variability by carrier; custom domains differ |
| Third-party dependencies | Not tested per app | Often the largest risk |
| Compliance / filing | Out of scope of probes | Required for formal China business |
Interim conclusion
The evidence supports a measured conclusion:
Netlify was reachable from Mainland China in this test set. Static hosting worked. Page resources worked. Image CDN transforms worked. Netlify Functions and Edge Functions worked. Forms, Identity-related endpoints, scheduled/background paths, and Netlify API paths also returned successfully in the tested environment.
The result does not mean Netlify has Mainland China local coverage. It means that, for this demo, the overseas Netlify path was generally usable from Mainland China.
2. Where the unavailable boundary cases are
Netlify availability is not the only risk that matters for a China-facing application.
Third-party dependencies are often the larger risk
A Netlify page may load while its dependency graph fails.
Common risk categories include:
- International font providers.
- Analytics and tag managers.
- Authentication widgets.
- Embedded maps.
- Video providers.
- Customer support widgets.
- CMS delivery APIs.
- Payment or identity providers.
- Social embeds.
- Scripts hosted on international CDNs.
The demo results are useful because they show that Netlify itself was not the only tested component. Even dynamic paths were reachable. However, each real application will have its own dependency set. A production assessment should inventory every external hostname loaded by the page and test those hostnames from Mainland China.
DNS remains a significant risk
Any international domain used by the application may behave inconsistently across Mainland China networks.
Risks include:
- Slow DNS resolution.
- Failed DNS resolution.
- Different results by city or carrier.
- Cross-border route instability.
- Dynamic interference affecting international domains.
- CDN anycast behavior that changes over time.
The nationwide HTTP probe resolved the demo to overseas IPs and showed mostly successful results, but also a small number of exceptions. That is consistent with a cross-border delivery path: usually reachable, but not uniformly predictable.
For production readiness, DNS should be tested separately from HTTP. It is not enough to test one city, one carrier, or one cloud runner.
Compliance is separate from technical reachability
Technical reachability does not answer the compliance question.
If a company intends to operate a China-facing business, relying only on an unfiled overseas domain is a continuing risk. For many commercial scenarios, a China-facing domain should go through the appropriate ICP filing process and related operational requirements.
Without a filed domain and an appropriate China delivery setup, the business may face:
- Platform or CDN onboarding limitations.
- Domain-level enforcement risk.
- Takedown or blocking risk.
- Procurement and enterprise customer objections.
- Legal uncertainty for formal China operations.
This risk exists even when the overseas Netlify site is technically reachable.
3. Practical China delivery options
Reachability is not the same as a production-ready China setup. Once the assessment below is done, most teams choose between three patterns, in increasing order of cost and commitment.
Start with an assessment
Before changing anything, inventory what a China-facing version of the application actually requires:
- Page resource inventory and total payload weight.
- Third-party domain inventory — every external hostname the page loads.
- DNS behavior by city and carrier.
- Browser performance from Mainland China.
- Netlify dynamic feature usage (Functions, Edge Functions, Forms, Identity).
- Authentication and cookie behavior (domain, SameSite).
- CORS and CSP requirements.
- API routing.
- Data and compliance considerations.
- Whether a filed China domain is required for the business model.
Option A — keep Netlify as-is
If the application is light, has few third-party dependencies, and is not a formal China-facing commercial product, the overseas Netlify path may be acceptable on its own. The evidence above shows it is usually reachable. The trade-offs are cross-border latency, DNS variability, and no filing.
Option B — add a China static-delivery layer
The most common production pattern keeps the global Netlify build and deployment workflow and adds a China-optimized layer for the static frontend:
- On each successful Netlify production build, sync the published static output to a domestic object store plus CDN — for example Alibaba OSS, Tencent COS, or Amazon S3 in the AWS China regions, fronted by a domestic CDN.
- Validate the synced release on a staging domain and probe it from Mainland China.
- For commercial use, move the China-facing surface to a filed
.cndomain (ICP filing) that points at the domestic CDN. - Serve static assets — HTML, JS, CSS, images, fonts, hashed immutable build output — from the China path.
This pattern is strongest for static frontend delivery, the part of the application that is most predictable and most sensitive to download performance. It does not, by itself, solve dynamic behavior.
Option C — handle dynamic paths case by case
Dynamic behavior should not be generalized too early. Some dynamic paths may keep calling the original Netlify deployment and work acceptably; the demo results suggest this is possible. But each path is application-specific:
- Relative paths such as
/.netlify/functions/foomay break under a China domain unless routed explicitly. - Absolute API URLs may keep working if CORS allows the China domain.
- Cookie-based auth may need domain and SameSite changes.
- OAuth providers may need new redirect URIs.
- CSP rules may need updates.
- Netlify Forms, Identity, and other platform features may need route-level validation.
The practical model: serve static assets from the China CDN, leave dynamic paths on Netlify while they perform, and add route-level China proxying only when a specific path fails or is too slow. Treat each dynamic path as an integration decision, not a generic CDN problem.
Where Chinaready fits
Chinaready runs the assessment above and implements Option B as a managed build-sync delivery layer, handling Option C per path where measurement shows a concrete need. The aim is not to replace Netlify, but to add a China readiness and delivery layer around a Netlify-based application. For suitable projects this can start as a proof of concept before a broader rollout.
4. Netlify’s reality in China
The evidence does not support a simple statement that Netlify is unavailable in China. It also does not support a claim that Netlify is equivalent to a Mainland China-hosted platform.
A more accurate view is:
- Netlify is usually reachable from Mainland China.
- Static hosting can work.
- Dynamic Netlify features can work in some scenarios.
- Performance is cross-border and therefore less predictable than a domestic CDN.
- DNS and third-party dependencies are major sources of risk.
- Legal business use may require filed-domain compliance.
- Heavy pages still need China-specific frontend optimization.
- Dynamic behavior needs route-by-route analysis.
For many teams, the practical architecture is not to abandon Netlify. It is to keep Netlify as the global build and deployment workflow, then add a China-specific frontend delivery layer for the China-facing surface.
That delivery layer can make the static frontend faster and more compliant, while preserving the existing global platform. Dynamic paths can remain on Netlify until measurement shows a concrete need for proxying or China-side adaptation.
This is the role Chinaready can play: not as a generic replacement for Netlify, but as a China readiness and delivery layer around a Netlify-based application.
References
- Netlify demo deployment — the test target exercised throughout this guide.
- Stack Break Lab — Netlify result page — public capability and resource probe output behind the tables above.
- ICP and PSB filing explained — when a filed China domain is required, and why filing is separate from technical reachability.
- Firebase alternatives for China, by function — the same probe-first method applied to a backend platform.
