Community

Blog Events Webinars Tutorials Forum
  1. Blog
  2. Events
  3. Webinars
  4. Tutorials
  5. Forum
Create Account
×
Community Blog ESA Unlocked: Access Optimization for Chinese Mainland — Serve Chinese Visitor from an Overseas Origin

ESA Unlocked: Access Optimization for Chinese Mainland — Serve Chinese Visitor from an Overseas Origin

Fast mainland China access from an overseas origin: ESA Access Optimization routes users without ICP, no local build-out.

The Cross-Border Problem

A company with an overseas site - origin in the US, Europe, or Singapore - often sees a very different experience for users in the Chinese mainland than everywhere else. Global dashboards look healthy, but mainland requests are very very slow.

This is measurable, not anecdotal. Public network analyses of overseas-hosted sites serving mainland China report page loads of 5–10 seconds under normal conditions and 10–15 seconds during evening peak hours. DNS resolution alone can take 200–500 ms in China versus 20–50 ms in most other regions, and cross-border packet loss runs 3–5× higher than other regions, spiking to 10–15% at peak - versus roughly 1–2% when content is served from a nearby edge node. The root causes are structural: limited international bandwidth, traffic funneled through a few congested gateways, and routing inefficiencies that change without warning.

These are observed ranges, not guarantees. Real-world results swing a lot with ISP (China Telecom, China Unicom, and China Mobile can differ substantially), province, time of day, origin location, object size, and how the application uses TCP/TLS. Treat any number here as a baseline to reason about, not a target you will always hit.

The classic fix is to replicate the stack inside China: a local entity, an ICP license, a separate cloud account, local vendors, and a parallel operations team. That works, but time-to-market is measured in quarters and cost starts long before the first sale.

ESA gives you a lighter option for the right scenarios: Access Optimization (Chinese Mainland Network). It routes Chinese mainland requests through an optimized path to your existing overseas origin - no local deployment required.

esa_china_market

Why Milliseconds Matter

Latency on the cross-border path is not a vanity metric - it converts into revenue. In the Deloitte/Google study Milliseconds Make Millions (37 websites, over 30 million sessions, measured hourly across 30 days), improving mobile site speed by just 0.1 second (100 ms) lifted conversion rates by 8.4% in retail and 10.1% in travel, and retail customers spent 9.2% more. Luxury sites saw larger swings, including a 40.1% increase in add-to-cart and a 20.6% increase in "contact us" visits.

One caution: the study measures the impact of a small, isolated 0.1-second improvement. It does not imply a linear relationship, so you cannot multiply it out to claim that cutting seven seconds yields seven times the lift. What it does show is that even modest latency reductions produce measurable business impact - which is exactly the kind of win Access Optimization targets when your mainland users are waiting many seconds longer than users elsewhere. Access Optimization exists to close that gap without a full local build-out.

How It Works

When you enable Access Optimization (Chinese Mainland Network):

  1. Requests from users in the Chinese mainland are routed to the optimized ESA POP in Hong Kong (China).
  2. That POP connects into the ESA global acceleration network.
  3. Using the acceleration network plus protocol-stack optimization, users reach origin servers outside China quickly and reliably.

The key idea: your origin stays exactly where it is. ESA optimizes the path from the Chinese mainland into your overseas stack rather than moving your application into China.

It helps to think of ESA as a reverse proxy, not a tunnel. A client connection and the back-to-origin connection are two separate legs: the mainland user terminates at the Hong Kong (China) ESA edge, and ESA opens its own optimized connection from there through the acceleration network to your origin. Traffic is relayed between the two legs - it is not one end-to-end socket from user to origin. This is why edge features (TLS, caching, WAF, DDoS protection) can act on the request, and why the origin sees ESA as its peer.

Xnip2026_10_05_17_27_39

Scope note: This is an access-optimization feature, not a compliance tool. It accelerates delivery for content that is lawful to serve from outside the mainland. It does not replace an ICP license or a local deployment for services that must be hosted inside China.

Before You Begin: Eligibility

Access Optimization (Chinese Mainland Network) has two hard prerequisites. Check both before you look for the toggle.

Requirement What You Need Why
Plan Enterprise (paid add-on, pay-as-you-go) Not available on Entrance, Pro, or Premium.
Acceleration region Global (Excluding the Chinese Mainland) The feature only appears when the site's acceleration region is set this way.

Important: If your site's acceleration region does not meet the requirement, switch the acceleration region first - otherwise the toggle will not be available.

Enable Access Optimization

  1. In the ESA console, select Websites, and in the Website column, click the target site.
  2. In the left navigation pane, choose Speed and Network > Optimize.
  3. In the Network Optimization section, find Access Optimization (Chinese Mainland Network) and turn on the toggle.

cg_enable_toggle

Verify the Configuration

The goal here is a configuration check: confirm that Chinese mainland requests are scheduling to the Hong Kong (China) POP. It proves routing is behaving as expected - it is not proof that performance improved. Performance validation is a separate step (next section).

Run these tests from a Chinese mainland network. DNS scheduling is geography-aware. If you resolve the domain from Singapore or the US, GeoDNS/GSLB may route you to the nearest local POP, not Hong Kong (China), and you will draw the wrong conclusion. Use a mainland host, a mainland DNS resolver, or a mainland-based probe. A query from outside the mainland tells you nothing about the mainland path.

Step 1 - Get the resolved POP IP address. These commands surface which IP the domain resolves to. Any of nslookup, dig, or ping triggers a lookup and reveals the address; ping here is only a resolution helper, and ICMP reachability is not required for ESA acceleration (edge nodes often rate-limit or drop ICMP). Replace www.example.com with your domain.

nslookup (Windows Command Prompt or macOS/Linux Terminal):

nslookup -type=A www.example.com

cg_verify_nslookup

ping (reveals the resolved IP; a timeout here does not mean acceleration failed):

ping www.example.com

cg_verify_ping

dig (macOS/Linux Terminal):

dig www.example.com

cg_verify_dig

Step 2 - Check the IP location. Open the IP Address Tool in the CDN console, enter the IP address from Step 1, and click Check. If the result shows Hong Kong, the mainland scheduling is configured correctly. Re-run from at least one more mainland location if you can, to confirm consistency.

cg_verify_ipcheck

Validate the Performance (Before / After)

Configuration verification says the traffic is on the right path. Performance verification says the path is actually faster - and that is the part that matters to your users. Capture a baseline before you enable the feature, then measure again after, from the mainland.

Break the request into stages so you can see where time goes:

curl -o /dev/null -s \
  -w 'DNS: %{time_namelookup}s\nTCP connect: %{time_connect}s\nTLS handshake: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n' \
  https://www.example.com/

To make the result credible, test from multiple mainland vantage points rather than a single machine - at least a north / east / south spread (for example Beijing, Shanghai, Guangzhou or Shenzhen) and, where possible, across the three major carriers (China Telecom, China Unicom, China Mobile). Record the raw before/after numbers yourself. Don't quote a target improvement in a design doc until you have measured it on your own traffic, because the gain depends on the user's ISP, province, and origin, and will not look identical for every customer.

Limits and Gotchas

Behavior Detail What to Do
IPv6 ESA supports IPv6 generally, but Chinese-mainland IPv6 traffic does not use this specific Access Optimization path when IPv6 access is enabled. If mainland IPv6 clients matter, plan around this; the China optimization path is IPv4-oriented. This is a limitation of the feature, not of ESA.
Acceleration region Feature works only when region is Global (Excluding the Chinese Mainland). Switch region before enabling.
DDoS switchover During a DDoS attack on your domain or the optimization POP, ESA switches requests to a protection POP. Connections may interrupt during switchover, and the feature is unavailable until the attack ends. With Best-effort DDoS protection, mainland traffic moves to a Best-effort protection POP; without it, to a Basic DDoS protection POP.

Long-Lived Connections (WebSocket, gRPC, Streaming)

ESA network optimization supports WebSocket and gRPC, so SaaS dashboards and real-time APIs are fair game - but long-lived traffic behaves differently from ordinary request/response and needs its own checks.

Because the mainland user and the origin sit on two separate connections through the edge, anything that interrupts one leg drops that session. During a routing or DDoS protection POP switchover, an existing WebSocket/TCP session can break and the client will need to reconnect. For plain REST calls the cost is a single retried request; for WebSocket, chat, trading, AI streaming, or real-time control it can mean a full reconnect plus re-authentication and session recovery.

So for these workloads:

  1. Match the origin timeout to the setting in Origin Protocol and Port, so idle-but-open connections are not torn down prematurely.
  2. Implement a heartbeat / keepalive on the client side if you want a connection to persist while no data is flowing.
  3. Build reconnect with exponential backoff, plus idempotency and **session recovery on the application side, so a switchover or timeout degrades gracefully instead of losing state.

Production Hardening

Two items turn this from "it's accelerated" into "it's accelerated and safe."

Lock down the origin. Once mainland traffic flows through ESA, you want your overseas origin to accept only trusted ESA traffic. If the origin's real IP is discoverable, users or attackers can hit it directly and bypass the acceleration and the entire security layer (WAF, rate limiting, bot protection, DDoS). Combine Access Optimization with the whitelist approach covered in Part 4: Origin Protection so only ESA's converged back-to-origin addresses reach the origin.

Preserve the real client IP. Behind any reverse proxy the origin sees ESA as the TCP peer, not the end user - so logs, analytics, GeoIP, and fraud rules can silently fill up with ESA addresses. Make sure your origin/application reads the client-IP header that ESA supplies (for example X-Forwarded-For), rather than relying on the raw source IP. Trust that header only for traffic that arrives from ESA; never trust a client-supplied X-Forwarded-For unconditionally, or you reopen an IP-spoofing hole.

When to Use This (and When Not To)

Access Optimization is a bridge, not a destination. Use it well by matching it to the right scenario.

Scenario Fit Rationale
Marketing site, docs, support portal for China audience Good fit Non-regulated content, big latency win, zero local footprint.
Overseas e-commerce browsing/checkout from China Good fit Faster browsing without a local store; keep global payment back-end.
SaaS onboarding/dashboard APIs for China users Good fit Stabilizes cross-border API latency during peak hours; for WebSocket/streaming, see Long-Lived Connections above.
Services legally required to host in mainland China Not a fit Needs a real local deployment + ICP, not just an optimized path.
Mainland IPv6-only clients Limited Mainland IPv6 traffic does not use this optimization path.

Billing

Access Optimization (Chinese Mainland Network) is a paid add-on billed pay-as-you-go based on the upstream and downstream traffic of accelerated requests. Contact customer service for current pricing details.

Where This Fits in Your China Strategy

Treat Access Optimization as phase one: a fast, low-commitment way to serve Chinese users reliably from your existing global stack. Use the traffic and performance data you gather to decide whether and when to invest in a full local deployment for regulated or latency-critical workloads.

What's Next?

This is the final article in the ESA Unlocked series. Together, the series covers Wildcard Domain Auto-Discovery, Smart Routing, Tiered Cache, Origin Protection, and China mainland access optimization - the features most ESA users don't fully exploit.

Resources:

CDN ICP Edge Security Acceleration ESA
0 1 0
Share on

Read previous post:

ESA Unlocked: Origin Protection - Stop Attackers from Bypassing Your CDN

Bryan, Zhang

7 posts | 1 followers

You may also like

Comments

Bryan, Zhang

7 posts | 1 followers

Related Products

  • Edge Security Acceleration (Original DCDN)

    Edge Security Acceleration (ESA) provides capabilities for edge acceleration, edge security, and edge computing. ESA adopts an easy-to-use interactive design and accelerates and protects websites, applications, and APIs to improve the performance and experience of access to web applications.

    Learn More

  • Edge Node Service

    An all-in-one service that provides elastic, stable, and widely distributed computing, network, and storage resources to help you deploy businesses on the edge nodes of Internet Service Providers (ISPs).

    Learn More

  • Edge Network Acceleration

    Establish high-speed dedicated networks for enterprises quickly

    Learn More

  • Secure Access Service Edge

    An office security management platform that integrates zero trust network access, office data protection, and terminal management.

    Learn More

More Posts by Bryan, Zhang

See All