Is Netlify blocked in China? 137-node probe results

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 /__where reporting 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.app

A 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.

Sign-up and contact forms are a concrete example of this class: the Netlify form endpoint itself was reachable in these probes, but a captcha or form host loaded from an overseas provider is a separate hostname with its own verdict — see Captcha and forms in China for how to choose that path, and Landscape’s Google reCAPTCHA map for a research shortlist.

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:

1. 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.
2. Validate the synced release on a staging domain and probe it from Mainland China.
3. For commercial use, move the China-facing surface to a filed .cn domain (ICP filing) that points at the domestic CDN.
4. 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. If you are still shortlisting the domestic static host for step 1, Landscape’s GitHub Pages map covers the same object-store-plus-CDN category as a research starting point rather than an endorsement.

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/foo may 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.

Where those dynamic paths call a hosted backend platform rather than your own functions, the same route-by-route reading applies to that platform — Firebase alternatives for China, by function works through auth, database, storage, and functions one at a time using the same probe-first method.

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.