Vercel and China — what works, where the risks are
A measured look at Vercel reachability from Mainland China, based on a feature-rich demo deployment, Stack Break Lab probes from a Beijing node, and a practical China delivery model aligned with static mirror patterns.
Vercel is a strong platform for shipping modern web applications. For China, the useful question is not whether Vercel is categorically “blocked” or “available”. The better question is whether a specific Vercel-hosted application can be reached, loaded, and operated safely enough for Mainland China users — and whether storage or region tuning delivers domestic CDN performance.
Based on our current tests, the practical answer is:
Vercel is reachable from Mainland China with strong connectivity and moderate latency. Static hosting, Edge Middleware, Serverless Functions, Blob, and KV paths all completed successfully in our probe set. The more material gaps are cross-border Time to First Byte (TTFB), dynamic API latency, DNS variability, third-party dependencies, and compliance for China-facing business use.
Three scope notes before the evidence. First, every result below was measured from a single Alibaba Cloud runner in Beijing. Carrier, province, and time-of-day variation are not covered. Second, the demo configured Vercel Blob in Hong Kong and Redis (Upstash) in Singapore, but the measured edge POP for browser traffic was sin1 (Singapore) — storage region does not relocate the CDN edge. Third, the test target was a shared *.vercel.app subdomain; a production custom domain can behave differently for DNS and domain-level risk and must be tested separately.
This guide summarizes the evidence from a real demo deployment, shows how to reproduce the probes yourself, interprets what “all tests passed” means in Stack Break Lab terms, and outlines practical China delivery options — including a static mirror path aligned with Vercel’s own guidance.
1. Vercel is reachable from Mainland China
Test target
The test target was a Vercel demo application:
https://project-silk-eta-17.vercel.app/
This was not only a static page. The demo was designed to exercise a broad set of Vercel capabilities:
- Static hosting and CDN-delivered assets.
- Edge Middleware.
- Serverless Functions (
/api/hello). - Function + KV read/write (
/api/kv-ping). - Function + Blob write/read (
/api/stamp-report). - Large static assets (1 MB, 3 MB, and 6 MB PNGs).
- A diagnostic endpoint at
/__wherereporting the Vercel edge region. - Platform reachability:
vercel.com, Analytics, andapi.vercel.comfrom a Mainland China server path.
Storage for this demo: Blob in Hong Kong, Redis (Upstash) in Singapore.
The public Stack Break Lab result page is available here:
https://stackbreak.launchready.cn/public/results/vercel.html#vercel-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, Middleware, Functions, 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 (in this lab, typically slower than 5 seconds) |
| 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 feeling slow to users. A 3.6-second Blob write is Reachable in lab terms — not “excellent performance”. Reachable is a low-bar availability test, not a Core Web Vitals pass or a domestic 200 ms first-screen standard.
Stack Break Lab capability probe
A Mainland China cloud runner executed a deep-dive capability probe against the Vercel demo. The result was:
| Probe group | Result |
|---|---|
| Total deep-dive capability probes | 21 |
| Reachable capability probes | 21 |
| Failed capability probes | 0 |
| Blocked probes | 0 |
| Degraded probes | 0 |
Representative results:
| Path | Product / probe | HTTP | TTFB | Total time | Verdict |
|---|---|---|---|---|---|
| Frontend | Static HTML / CDN | 200 | 0.5–0.7 s | 0.7–1.1 s | Reachable |
| Frontend | Edge Middleware | 200 | 0.5–0.7 s | 0.7–1.1 s | Reachable |
| Frontend | Function hello | 200 | — | 0.74 s | Reachable |
| Frontend | Function + KV (/api/kv-ping) | 200 | 1.2 s | 2.1 s | Reachable |
| Frontend | Function + Blob (/api/stamp-report) | 200 | — | 3.6 s | Reachable |
| Frontend | Large static asset (~6 MB PNG) | 200 | 1.4 s | 3.4 s | Reachable |
| Transport | vercel.com / Analytics | 200 | — | — | Reachable |
| Transport | api.vercel.com | 200 | — | 0.3–1.0 s | Reachable |
| Transport | DNS vercel.app | DNS | — | ~0.009 s | Reachable |
The important observation for operations: api.vercel.com was reachable from Mainland China. Deploy and CI paths that call the Vercel API from a domestic server are not automatically blocked in this environment.
Stack Break Lab latency / resource probe
A second snapshot measured page-resource latency and edge region.
| Metric | Result |
|---|---|
| Total latency probes | 9 |
| Reachable latency probes | 9 |
| Failed latency probes | 0 |
Vercel edge region (serverRegion) | sin1 (Singapore) |
| Detected probe geography | Beijing, Mainland China |
All nine latency probes returned Reachable. Throughput on the 6 MB asset reached roughly 14 Mbps after connection — bandwidth was not the bottleneck; first-byte wait was.
Edge landing point vs storage region
This demo separates two concepts that are easy to conflate when tuning for China:
| Dimension | Configured / measured value |
|---|---|
| Edge POP (browser traffic) | sin1 — Singapore |
| Blob storage | Hong Kong |
| Redis / KV (Upstash) | Singapore |
Static pages, Middleware, and Function requests from Beijing hit the Singapore edge first, not Hong Kong. Placing Blob in Hong Kong mainly optimizes the backend path when a Function writes or reads Blob — it does not move the CDN edge to Hong Kong.
A more accurate framing:
- Storage region tuning → addresses cross-Pacific latency on the data layer (Blob stamp at ~3.6 s still succeeds).
- Vercel CDN routing → delivers an Asia-Pacific path that is reachable from Beijing, with typical TTFB around 0.5–1.2 s — not the same as a Mainland China cache hit.
Vercel documents hkg1 (Hong Kong) as a compute region, and Edge Functions can list preferred regions. Anycast routing still decides which POP serves a given user. This run landed on sin1. Region configuration cannot replace a domestic CDN for Mainland China users.
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 API 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://project-silk-eta-17.vercel.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://project-silk-eta-17.vercel.app/__where"Serverless Function:
curl -sS \
-w "\nfunction code=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 30 \
"https://project-silk-eta-17.vercel.app/api/hello"Function + KV:
curl -sS \
-w "\nkv code=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 30 \
"https://project-silk-eta-17.vercel.app/api/kv-ping"Function + Blob stamp:
curl -sS \
-w "\nstamp code=%{http_code} total=%{time_total}s\n" \
--connect-timeout 10 --max-time 30 \
"https://project-silk-eta-17.vercel.app/api/stamp-report"Large static asset (~6 MB):
curl -sS -o /dev/null \
-w "asset code=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n" \
--connect-timeout 10 --max-time 60 \
"https://project-silk-eta-17.vercel.app/assets/weight-6mb.png"DNS resolution (run separately from HTTP, and from more than one city/carrier):
dig +noall +stats +answer project-silk-eta-17.vercel.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 vercel.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.
| Vercel capability | Tested verdict (this run) | Main China risk |
|---|---|---|
| Static hosting (CDN) | Reachable | Cross-border TTFB (~0.5–1 s) |
| Edge Middleware | Reachable | sin1 routing — not in-country |
| Serverless Functions | Reachable | Cold start + cross-border latency |
| Blob (Hong Kong) | Reachable | Write path slow (~3.6 s) but usable |
| KV / Redis (Singapore) | Reachable | ~2 s when wrapped in a Function |
| Platform API / deploy | Reachable | — |
DNS (vercel.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:
Vercel was reachable from Mainland China in this test set. Static hosting worked. Middleware worked. Serverless Functions worked. Blob and KV paths returned successfully. Platform surfaces including api.vercel.com were reachable from a Mainland China server path.
The result does not mean Vercel has Mainland China local edge coverage. It means that, for this demo with Asia-Pacific storage tuning, the overseas Vercel path was connectivity-strong and latency-moderate — usable, but not equivalent to a domestic CDN.
2. What the measurements mean
Section 1 reports numbers. This section interprets them — especially the gap between “all tests passed” and “feels fast in China”.
Connectivity vs perceived speed
Every deep-dive and latency probe in this run was Reachable. None were Blocked or Degraded under the lab threshold (total time under 5 seconds). That is a strong connectivity conclusion: from this Beijing node, the Vercel stack was not walled off and did not time out.
Perceived speed is a different axis:
| Layer | Typical range (this run) | User experience |
|---|---|---|
| DNS | ~9 ms | No issue |
| Static / Edge TTFB | 0.5–1.2 s | Noticeable wait before first byte |
| Lightweight Function | ~0.7 s | Acceptable for APIs |
| Function + KV | ~2.1 s | Clearly cross-border |
| Function + Blob write | ~3.6 s | Slow but completes |
| Large file after connect | ~14 Mbps | Bandwidth adequate once connected |
A 3.6-second Blob stamp is Reachable, not “performance excellent”. If your product SLA expects TTFB under 300 ms or API responses under 1 second, several paths in this run would miss that bar even though they pass the lab.
Same-lab comparison with other platforms
Measured from the same Stack Break Lab methodology and comparable Mainland China runners:
| Platform | Blocked probes | Slowest item | Edge / backend region |
|---|---|---|---|
| Vercel (this run) | 0 | 3.6 s (Blob stamp) | sin1 |
| Netlify | 0 | ~2.2 s Edge / ~3.5 s large file | aws-ap-southeast-1 |
| Firebase | 18 | 30 s timeout | Google backends largely unreachable |
Objectively, Vercel and Netlify sit in the same class for Mainland China reachability: Southeast Asia edge, cross-border latency, generally usable. Relative to Firebase and Google-backed paths, Vercel’s advantage is not marginal speed — it is fundamental connectivity. Storage region tuning additionally showed that Vercel Blob and KV dynamic layers can complete from Mainland China when regions are chosen deliberately.
Capability assessment (subjective summary)
| Path | Assessment | Notes |
|---|---|---|
| Transport (platform reachability) | Strong | DNS, vercel.com, api.vercel.com all reachable; deploy from Mainland China feasible |
| Frontend CDN | Moderate | Not blocked; TTFB 0.5–1.1 s — not “fast” by domestic standards |
| Functions / Edge | Good | Stable 200 responses; latency predictable within cross-border bounds |
| Blob (Hong Kong) | Moderate | Read/write works; stamp write ~3.6 s |
| Redis / KV (Singapore) | Good | REST path fast; Function-wrapped path ~2 s |
| Mainland China user experience (inferred) | Moderate | Pages open and APIs complete; not domestic CDN class |
Plain-language takeaway: From Beijing, Vercel is deployable, reachable, and full-stack usable with Blob in Hong Kong and Redis in Singapore. Optimizing storage regions is necessary and correct for the data layer. It does not make the CDN edge behave like a Mainland China POP.
For external messaging, prefer:
“From a Beijing node, Vercel was fully Reachable in Stack Break Lab; static and API latency ranged roughly 0.5–4 s, with large-file throughput up to ~14 Mbps; Asia-Pacific storage tuning kept dynamic read/write paths stable.”
Avoid:
“After tuning cache and storage, CDN performance matches domestic China.”
3. Where the unavailable boundary cases are
Vercel reachability is not the only risk that matters for a China-facing application.
Third-party dependencies are often the larger risk
A Vercel page may load while its dependency graph fails.
Common risk categories include:
- International font providers.
- Analytics and tag managers (including Vercel Analytics and Speed Insights when loaded from blocked or slow hosts).
- 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 show that Vercel platform paths — including dynamic ones — were reachable in the tested environment. 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.
Vercel’s own guidance notes that *.vercel.app subdomains may face higher scrutiny than custom domains. DNS should be tested separately from HTTP — and on both vercel.app and your production custom domain.
For production readiness, 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. Vercel does not offer in-country hosting or regulatory support.
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 Vercel site is technically reachable. See ICP and PSB filing explained for when filing is required and how it differs from reachability testing.
Demo limitations specific to this run
- Single node — Alibaba Cloud Beijing only; telecom, unicom, mobile, tier-2 cities, and peak-hour matrices are not covered.
- Minimal application — no SSR waterfall, WebSocket stress, heavy concurrency, or a large third-party script graph.
- Cold start + round trips — KV REST from a server path can be fast (~0.39 s in backend probes), while Function + KV from the browser path was ~2.1 s, indicating latency beyond the datastore itself.
4. 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. This mirrors the Netlify delivery model and aligns with Vercel’s own guidance on static mirrors and dual deployments — Vercel does not recommend a generic reverse proxy in front of a deployment, but acknowledges that customers have improved access with static mirrors or dedicated in-country versions (which require ICP filing).
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.
- Vercel dynamic feature usage (Functions, Edge Middleware, Edge Functions, Cron).
- Next.js ISR,
revalidate, and Middleware dependency chains. - Edge Config and environment-specific routing.
- Blob and KV usage — browser-direct vs server-only paths.
- Vercel Analytics / Speed Insights and other telemetry hosts.
- Authentication and cookie behavior (domain, SameSite).
- CORS and CSP requirements.
- API routing.
- Data residency and compliance considerations.
- Whether a filed China domain is required for the business model.
Option A — keep Vercel as-is
If the application is light, has few third-party dependencies, and is not a formal China-facing commercial product, the overseas Vercel path may be acceptable on its own. The evidence above shows it is reachable with moderate latency. The trade-offs are cross-border TTFB, DNS variability, dynamic API slowness, and no filing.
Asia-Pacific Blob and KV regions are still worth configuring when you use those products — they improve backend paths even when the edge stays on sin1 or another overseas POP.
Option B — add a China static-delivery layer
The most common production pattern keeps the global Vercel build and deployment workflow and adds a China-optimized layer for the static frontend — the same structural flow as Netlify Option B:
- On each successful Vercel production deployment, 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. Use the deployment output directory,
.vercel/output, or CI-fetched deployment artifacts depending on your framework. - 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. It does not, by itself, solve Middleware, Edge Functions, or serverless API behavior.
Remember: Hong Kong Blob does not make HTML exit from Hong Kong. Option B addresses the static surface; storage region tuning and Option C address the dynamic layer.
Option C — handle dynamic paths case by case
Dynamic behavior should not be generalized too early. Some dynamic paths may keep calling the original Vercel deployment and work acceptably; the demo results suggest Function and KV paths can complete in 2–4 seconds. But each path is application-specific:
- Relative paths such as
/api/foomay break under a China domain unless routed explicitly. - Absolute API URLs may keep working if CORS allows the China domain.
- Edge Middleware and Edge Functions cannot run on a domestic static CDN — they stay on Vercel’s edge unless you redesign the route.
- Cookie-based auth may need domain and SameSite changes.
- OAuth providers may need new redirect URIs.
- CSP rules may need updates.
- Blob browser-direct reads may need CORS, proxying, or server-only access patterns.
preferredRegion/regionsconfig may shift compute but does not guarantee Hong Kong edge for Beijing users.
The practical model: serve static assets from the China CDN, leave dynamic paths on Vercel 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.
Teams that need in-country edge compute and filing-backed delivery at scale may evaluate Cloudflare China Network — a different contract and compliance path, not a drop-in substitute for Vercel.
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 Vercel, but to add a China readiness and delivery layer around a Vercel-based application. For suitable projects this can start as a proof of concept before a broader rollout.
5. Vercel’s reality in China
The evidence does not support a simple statement that Vercel is unavailable in China. It also does not support a claim that Vercel is equivalent to a Mainland China-hosted platform — or that storage region tuning alone delivers domestic CDN performance.
A more accurate view is:
- Vercel is reachable from Mainland China in this probe set — 21/21 capability and 9/9 latency probes Reachable, zero Blocked.
- Static hosting and CDN paths work with cross-border TTFB around 0.5–1.2 seconds.
- Serverless Functions, Middleware, Blob, and KV can complete; dynamic APIs often run 2–4 seconds.
- Edge traffic from Beijing landed on
sin1, not Hong Kong — storage region ≠ CDN edge. - Blob in Hong Kong and Redis in Singapore are correct optimizations for the data layer.
- Platform API reachability from Mainland China supports deploy and operations workflows.
- DNS, third-party dependencies, and carrier variability remain major risks.
- Legal business use may require filed-domain compliance and a domestic delivery layer.
- Heavy pages and dynamic routes still need route-by-route China analysis.
For many teams, the practical architecture is not to abandon Vercel. It is to keep Vercel as the global build and deployment workflow, then add a China-specific frontend delivery layer for the China-facing surface — the same static-mirror pattern Vercel documents and the same Option B flow used for Netlify.
That delivery layer can make the static frontend faster and more compliant, while preserving the existing global platform. Dynamic paths can remain on Vercel 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 Vercel, but as a China readiness and delivery layer around a Vercel-based application.
References
- Vercel demo deployment — the test target exercised throughout this guide.
- Stack Break Lab — Vercel result page — public capability and resource probe output behind the tables above.
- Vercel — Accessing Vercel-hosted sites from Mainland China — official guidance on latency, custom domains, static mirrors, and dual deployments (last updated 2025-11-10).
- Vercel regions — documented POP and compute regions including
hkg1andsin1. - Netlify and China — what works, where the risks are — parallel reachability evidence and Option B/C delivery model.
- Firebase alternatives for China, by function — the same probe-first method applied to a Google-backed backend stack.
- Cloudflare China Network — Enterprise, ICP filing, and JD Cloud — when Enterprise China Network is the right upgrade path.
- ICP and PSB filing explained — when a filed China domain is required, and why filing is separate from technical reachability.
