placeholderBlog & OSS CDN Traffic Splitting Between Mainland China and Overseas

Blog & OSS CDN Traffic Splitting Between Mainland China and Overseas

ICP filing approved. A quick record of setting up split CDN routing for domestic and international visitors.

Tools Used

ToolCore RoleAlternativesCost
DNSPodSmart DNS resolution by domestic/overseas routesAlibaba Cloud DNSFree
BitifulCDN acceleration in mainland China
(ICP filing required)
Alibaba Cloud CDN, Tencent Cloud CDN, Qiniu CDNPaid
EdgeOneCDN acceleration outside mainland ChinaCloudflare CDN, Vercel CDNFree
Cloudflare PagesStatic origin hosting
Origin for overseas CDN nodes
Vercel, EdgeOne, GitHub Pages, personal serverFree
EdgeOne PagesStatic origin hosting
Origin for mainland CDN nodes
Server in mainland ChinaFree

How It Works

The idea is simple: split traffic with DNS CNAME records. Domestic users go through the domestic CDN, overseas users go through the overseas CDN.

CDN traffic splitting
CDN traffic splitting

The rough flow:

  1. User request: The user types vluv.space into the browser, and the OS sends a resolution request to the Local DNS Server (browsers and the OS also cache DNS results, skipped here)
  2. Recursive query: If the Local DNS Server has no cache, it starts from the Root DNS Server, works its way down to the TLD (Top-Level-Domain) DNS Server for .space, and finally reaches the Authoritative DNS Server responsible for vluv.space
  3. Different CNAME records by route: The Authoritative DNS Server, the endpoint of the whole query chain, holds all DNS records for vluv.space (e.g. A, CNAME, TXT records…); here that is Tencent Cloud’s DNSPod server.
    Tencent Cloud’s smart resolution detects where the user comes from and returns an IP accordingly, see DNS smart resolution route documentation - DNSPod
    • Domestic route: if the user is judged to be in mainland China, the authoritative DNS server returns a CNAME record pointing to the domestic CDN, e.g. vluv.space.s4cdn.dogecast.com.
    • Overseas visitors: otherwise, it returns a CNAME record pointing to the overseas CDN, e.g. vluv.space.eo.dnse4.com.

DNS
DNS

Final CDN resolution: After the Local DNS Server gets the CNAME record, it starts another full round of DNS resolution for the new domain in that record. In the end the CDN provider’s Authoritative DNS Server system takes over, and based on the user’s location, node load, and so on, returns the IP of the most suitable edge node. The user’s browser gets this IP, connects to the CDN edge node, and fetches the site content at full speed.

Probe locationResponse IPIP locationResponse time
Telecom, Dongguan121.14.153.91China/Guangdong/Dongguan/Telecom<1ms
Telecom, Taiyuan1.71.145.167China/Shanxi/Taiyuan/Telecom1ms
Telecom, Longyan106.126.9.144China/Fujian/Quanzhou/Telecom5ms
Telecom, Chongqing124.115.13.87China/Shaanxi/Xi’an/Telecom18ms
Telecom, Suzhou58.216.60.143China/Jiangsu/Changzhou/Telecom4ms
Seoul, South Korea43.159.99.18Anycast/Tencent Cloud32ms
London, UK43.159.99.18Anycast/Tencent Cloud18ms
Anycast, TTL

  • Notice that all overseas responses share the IP 43.159.99.18. This is actually multiple servers in different locations sharing one IP address, see What is Anycast? | How Anycast works | Cloudflare
  • The first visit to an obscure site usually goes through the whole lengthy DNS query above. Doing that full round trip every time would add a lot of latency. DNS caching solves this: the TTL (Time To Live) field configured on the Authoritative DNS Server is the cache expiry time

To verify the split routing works, run curl -I <your-domain> and inspect the response headers. Taking EdgeOne as an example, if the response contains an eo-cache-status header, the request went through an EdgeOne CDN node. See the EdgeOne default HTTP response headers documentation

Steps

Domestic and Overseas CDN Setup

Onboard each CDN following the provider’s instructions. For EdgeOne, see EdgeOne walkthrough: quick onboarding for security and acceleration - Tencent EdgeOne and just follow the steps. Roughly:

  1. Add the site
  2. Choose the service region and plan
  3. Choose the acceleration region and access mode (usually CNAME access)

cdn
cdn

cdn
cdn
About origin configuration

EdgeOne: it is recommended to place your origin in the same region as the acceleration region. For example, if the acceleration region is the Chinese mainland availability zone, configure a domestic origin. If the origin is in the global availability zone (excluding the Chinese mainland), origin pulls cross the border and performance cannot be guaranteed.

  • For the domestic CDN, use an origin inside mainland China; EdgeOne’s China version (Chinese mainland availability zone) works
  • For the overseas CDN there are more origin options: Cloudflare Pages, EdgeOne Pages, Vercel, GitHub Pages, etc.

DNSPod CNAME Split Routing

DNSPod can return different CNAMEs depending on the user’s route, so domestic users go to Bitiful and overseas users go to EdgeOne.

Configuration steps:

  1. Log in to the DNSPod console, select the domain, and open the “Record Management” page
  2. Add two CNAME records, one for the domestic route and one for the overseas route, as in the table below
HostTypeRouteValueTTLNote
@CNAMEDomesticvluv.space.s4cdn.dogecast.com.600Domestic CDN
@CNAMEOverseasvluv.space.eo.dnse4.com.600Global CDN

Do the same for the image hosting domain:

HostTypeRouteValueTTLNote
assetsCNAMEDomesticassets.vluv.space.s4cdn.dogecast.com.600Domestic CDN
assetsCNAMEOverseasassets.vluv.space.eo.dnse4.com.600Global CDN

Results

Test site: ITDOG

Domestic speed test results

Region/ISPFastestSlowestAverage
All nodesShanghai Telecom <1msTaiyuan Mobile 191ms12ms
China TelecomShanghai Telecom <1msYuxi Telecom 144ms12ms
China UnicomXining Unicom <1msYuxi Unicom 47ms10ms
China MobileChangsha Mobile <1msTaiyuan Mobile 191ms13ms
East ChinaShanghai Telecom <1msZhoushan Unicom 21ms7ms
South ChinaDongguan Telecom <1msShenzhen Mobile 27ms11ms
Central ChinaChangsha Mobile <1msYueyang Unicom 18ms7ms
North ChinaTianjin Mobile 2msTaiyuan Mobile 191ms27ms
SouthwestKunming Telecom <1msYuxi Telecom 144ms24ms
NorthwestXining Unicom <1msYinchuan Mobile 71ms8ms
NortheastDalian Unicom <1msSongyuan Unicom 15ms5ms
HK/MO/TWHong Kong 2msTaiwan 27ms14ms
International speed test results

RegionFastestSlowestAverage
All nodesLos Angeles <1msSouth Africa 178ms35ms
AsiaSingapore 1msTurkey 35ms17ms
EuropeFrankfurt <1msLondon 16ms8ms
North AmericaLos Angeles <1msSeattle 27ms9ms
South AmericaArgentina 21msSão Paulo 50ms35ms
AfricaCairo <1msSouth Africa 178ms89ms
OceaniaNew Zealand 142msNew Zealand 142ms142ms