Overseas CDN Acceleration for Chinese Websites: Optimizing Global User Access

Overseas CDN Acceleration for Chinese Websites: Optimizing Global User Access

An export SaaS team often hits this scenario: the site runs on a cloud provider's Shanghai node and loads fast domestically, but U.S. customers complain the page "takes seconds to open, and images keep failing." The root cause is usually not the server — it's the cross-border path, the most common pain point for Chinese websites serving global users.

1. Why Overseas Access Is Slow

Traffic from servers inside mainland China crosses international gateways, and three layers of overhead stack up:

• Limited international exit bandwidth: backbone capacity to the outside world is finite and congestion spikes in the evening
• Routing detours: IP paths frequently detour through the U.S. or Europe, multiplying physical distance
• High latency: round-trip latency to the U.S. is typically 200-300ms — more than 10x a local European user's latency
• High packet loss: 5-10% during peak hours, which triggers TCP retransmissions and makes pages stall far more than the raw numbers suggest

Before optimizing, trace every hop with mtr to pinpoint where the bottleneck actually sits:

# Trace for 20 seconds, printing loss and avg per hop
mtr -rwzc 20 your-domain.com

# Or quickly check average latency and loss with ping
ping -c 10 your-domain.com

If packet loss clusters in the domestic segment or at the international gateway, the problem is the cross-border link, not origin performance. For regional comparisons, use monitoring services like Checkly (10+ global nodes) or Dotcom-Tools (30+ global nodes), or test from domestic nodes toward overseas targets.

2. Three Main Solutions Compared

Solution 1: Domestic CDN + Overseas CDN Dual Stack

Geo-DNS splits traffic by region — the safest approach for ICP-licensed sites, with minimal change and low risk:

Users → Geo-DNS
       ├── Domestic users → Alibaba Cloud/Tencent Cloud CDN (CNAME)
       └── Overseas users → Cloudflare/CloudFront CDN (CNAME)

You only need two DNS records, one CNAME to the domestic CDN and one to the overseas CDN. Alibaba Cloud DNS and DNSPod both support geographic resolution; Cloudflare DNS offers more balanced overseas coverage if you prefer to host resolution outside China.

Solution 2: Cloudflare China Network

Cloudflare operates in-country nodes with JD Cloud, but enabling China routing requires an ICP filing and an Enterprise plan, which is not cheap. It suits teams with real budgets that want "one config for the whole world"; most individual sites do not need to go this far.

Solution 3: Overseas Reverse Proxy + Domestic Origin

Rent an overseas server and run Nginx or Envoy as a reverse proxy: static assets are cached at the overseas node, and dynamic requests go back to the domestic origin. It is cheap and fully controllable, but you handle node maintenance, certificate renewal, and cache invalidation yourself:

Overseas users → Overseas proxy (Nginx/Envoy)
                 ├── Static assets → served from local cache
                 └── Dynamic/API → back to domestic origin

3. Provider Performance and Cost Comparison

For a light site pushing 200GB/month: Cloudflare's free tier is usually enough; CloudFront runs roughly $10-30/month depending on peaks; Alibaba Cloud's global traffic packs are billed per GB, with the best value on Southeast Asia routes. When choosing, don't just count PoPs — inspect origin-return path quality. Nodes mean little if the origin return still detours.

4. A Real-World Migration Case

A cross-border SaaS tool previously routed all users straight to its Shanghai origin. European and U.S. users saw a ~4.8s first paint and bounced hard. The fix had three steps:

1. Move static assets (images, CSS, JS) to Cloudflare's free tier; keep only the API on the origin
2. Enable geo-DNS so domestic users keep using the domestic CDN, without cross-effects
3. Accelerate API calls with an overseas edge path (Argo Smart Routing or an overseas proxy) to cut origin-return latency

After the change, first paint for European/U.S. users dropped to ~1.2s, images stopped timing out, and overseas retention recovered noticeably. The migration took half a day, with risk concentrated in the few minutes of DNS cutover.

5. Best Practices and Common Misconceptions

• Separate static and API traffic: cache static assets on the CDN and accelerate APIs separately; don't mix them on one domain
• Control origin-return frequency: if the cache hit ratio won't climb, extra nodes won't help; tune Cache-Control and TTL first
• Test globally before launch: check HTTP status codes, time-to-first-byte, and packet loss from worldwide nodes, not just domestic speed
• Misconception: "just add a CDN and you're done": when the origin-return path itself is congested, cache misses are still slow; you must optimize both the return route and the cache policy

For teams still undecided, first read the domestic CDN selection guide, then combine it with the overseas approach here so each side does its own job.

Reference: Cloudflare China Network overview https://www.cloudflare.com/china-network/ ; AWS CloudFront global edge locations https://aws.amazon.com/cloudfront/features/