Dual CDN Split-Traffic Failure Postmortem: Aliyun DNS and Cloudflare Free Limits
Summary
The goal was to route a single static asset subdomain through Aliyun CDN for domestic users and Cloudflare CDN for overseas users, while keeping authoritative DNS hosted on Aliyun. After testing, I confirmed: this architecture is not viable on Cloudflare Free.
The root cause was not in SSL/TLS mode, page rules, or redirect rules. It was in Cloudflare's onboarding model restrictions. Cloudflare Free/Pro defaults to Full setup, which requires moving the domain's authoritative Nameservers to Cloudflare. The Partial/CNAME setup -- using external DNS to CNAME into Cloudflare proxy nodes without switching NS -- is only available on Business/Enterprise plans.
Background and Goals
The initial goal can be abstracted as this path:
Domestic users
-> Aliyun DNS split-resolution by region
-> Aliyun CDN
-> OSS or object storage origin
Overseas users
-> Aliyun DNS split-resolution by region
-> Cloudflare CDN
-> OSS or object storage origin
The constraints behind this goal:
- Domain registration and authoritative DNS stay on Aliyun.
- Domestic access continues through Aliyun CDN for filing, scheduling, and access quality requirements.
- Overseas access should use Cloudflare's edge network to improve quality.
- The origin already has HTTPS with a browser-trusted certificate.
- No desire to upgrade to a paid plan.
From the DNS layer, this seems straightforward: Aliyun DNS supports split-resolution, so it looks like you just configure two CNAME records for the same hostname.
img.example.com China mainland route CNAME aliyun-cdn.example-cname.com
img.example.com Overseas route CNAME cloudflare-target.example
But CDN reverse proxying is not ordinary DNS resolution. For the overseas route to actually enter Cloudflare's proxy layer, Cloudflare needs to recognize the hostname, issue an edge certificate for it, and allow external authoritative DNS to route traffic into Cloudflare via CNAME. The problem is right here.
What Actually Went Wrong
1. Cannot directly add a subdomain
I first tried adding img.example.com directly in Cloudflare. Cloudflare prompted that I should add the root domain, not a subdomain.
This is consistent with Cloudflare's standard onboarding model. Normal Zone onboarding is typically at the root domain level -- add example.com, then manage img.example.com, www.example.com and other subdomains within the Zone.
2. Zone stuck in Pending after adding the root domain
I then added the root domain example.com, but did not change the Nameservers on Aliyun to the ones Cloudflare provided. The result: the Zone in the Cloudflare console stayed inactive or showed invalid Nameservers.
The mistaken assumption at the time: just create a CNAME record for img in the Cloudflare console, enable the orange cloud proxy, then go back to Aliyun DNS and CNAME the overseas route to Cloudflare, and you can bypass NS takeover.
Testing proved this assumption wrong. Being able to create DNS records in the Cloudflare console does not mean the Free Zone has external CNAME onboarding capability.
3. Universal SSL did not issue a certificate for the subdomain
After setting the Cloudflare SSL/TLS mode to Full or Full (strict), I expected Cloudflare to auto-issue an edge certificate for img.example.com. But because the Zone was inactive, Universal SSL did not complete certificate deployment as expected.
It is easy to confuse two things here:
- Origin certificate: the certificate Cloudflare validates when connecting to the OSS or object storage origin.
- Edge certificate: the certificate the browser sees when connecting to Cloudflare's edge nodes.
Having a trusted certificate on the origin only solves the Cloudflare-to-origin leg. The browser-to-Cloudflare leg still needs a Cloudflare edge certificate. If Cloudflare has not deployed an edge certificate for this hostname, HTTPS access will still fail.
4. Custom certificate upload button is grayed out
I tried uploading my own certificate to the Cloudflare edge instead, but the upload button in the console was disabled.
This is not a certificate format issue; it is a plan capability issue. Cloudflare's custom edge certificate feature is not available on Free/Pro plans. On Free, you cannot bypass an unsigned Universal SSL by uploading your own certificate.
5. Page rules and redirect rules cannot fix the root cause
I also tried using page rules or redirect rules to configure Always Use HTTPS and HTTP-to-HTTPS redirects. The Cloudflare console warned that rules might not apply to the current traffic, or URL validation failed.
Even if the rules could be saved, they would not fix the root cause. HTTPS redirect rules run inside Cloudflare's proxy request handling pipeline. The current problem is that this hostname has not completed a valid onboarding under Cloudflare Free at all: the edge certificate is not ready, and external CNAME onboarding is not a mode supported by the Free plan.
In other words, rules are the processing logic after traffic enters Cloudflare. This failure occurred before traffic could be formally admitted by Cloudflare and TLS could be terminated.
Root Cause Analysis
This failure comes down to one core misunderstanding:
Treating "can create DNS records and enable orange cloud in the Cloudflare console" as "can CNAME from Aliyun DNS into the Cloudflare Free proxy layer without switching NS".
The official docs make the onboarding model clearer:
- Cloudflare DNS setup is divided into Full setup, Partial/CNAME setup, and other modes.
- Full setup requires moving the domain's Nameservers to Cloudflare.
- Partial/CNAME setup is the mode for "not switching authoritative DNS, only onboarding specified hostnames to Cloudflare via CNAME".
- Partial/CNAME setup requires Business/Enterprise, not Free/Pro.
Therefore, this path is not a supported production architecture on Cloudflare Free:
Aliyun authoritative DNS
-> Overseas route CNAME
-> Cloudflare Free proxy hostname
-> Origin
Cloudflare Free works well for this Full setup pattern:
User
-> Cloudflare authoritative DNS
-> Cloudflare proxy
-> Origin
But it cannot act as a reverse-proxy CDN that receives arbitrary CNAME traffic from third-party authoritative DNS without taking over Nameservers.
Final Conclusion
Under the free tier, these three goals cannot be satisfied simultaneously:
- Authoritative DNS stays on Aliyun.
- Domestic traffic goes through Aliyun CDN; overseas traffic goes through Cloudflare CDN.
- Cloudflare uses the Free plan and acts as the reverse-proxy CDN for overseas CNAME onboarding.
If you insist on Cloudflare Free, the more realistic choice is to move the root domain's (or related domain's) Nameservers to Cloudflare, accepting that all routes are resolved and proxied by Cloudflare.
If you insist on Aliyun DNS as authoritative DNS and only CNAME overseas traffic to Cloudflare, you need Cloudflare Business/Enterprise Partial/CNAME setup, or switch to another CDN that supports CNAME onboarding.
Alternative Approaches
Option 1: Upgrade Cloudflare and use Partial/CNAME setup
This is closest to the original goal.
Domestic: Aliyun DNS -> Aliyun CDN -> Origin
Overseas: Aliyun DNS -> Cloudflare CNAME setup -> Origin
Pros: clean architecture, DNS authority stays on Aliyun, domestic and overseas CDNs can be scheduled independently. Cons: requires Cloudflare Business/Enterprise, not free.
Option 2: Move Nameservers to Cloudflare
If you accept Cloudflare as authoritative DNS, use Cloudflare Free's standard Full setup.
Pros: Cloudflare onboarding, Universal SSL, and proxy rules all follow the standard path. Cons: domestic access quality, filing-related scheduling, and combining with Aliyun CDN all need to be redesigned. You can no longer rely on Aliyun DNS split-resolution.
Option 3: Use Aliyun CDN global or overseas acceleration
If the main goal is making the site accessible to overseas users rather than specifically using Cloudflare, evaluate Aliyun CDN's global acceleration or overseas acceleration capabilities directly.
Pros: unified control plane; certificates, origin fetch, caching, and logs are all within the Aliyun ecosystem. Cons: overseas quality, pricing, and node coverage need separate evaluation.
Option 4: Domestic CDN with overseas direct-to-origin
On a tight budget, keep domestic routes on Aliyun CDN and have overseas routes resolve directly to the origin.
Domestic: Aliyun DNS -> Aliyun CDN -> Origin
Overseas: Aliyun DNS -> Origin
This is technically simple, but overseas users get no CDN acceleration or edge protection. The origin must also be directly exposed to overseas traffic, handling security groups, firewalls, certificates, bandwidth, and attack risk.
Option 5: Switch to an overseas CDN that supports CNAME onboarding
If the core requirement is not switching NS and only CNAME-ing overseas routes to a CDN, choose an overseas CDN that supports this model at an acceptable price point.
When evaluating, confirm in advance:
- Whether it supports CNAME onboarding with third-party authoritative DNS.
- Whether it auto-issues edge certificates.
- Whether it allows uploading custom edge certificates.
- Whether it supports onboarding only a single subdomain.
- Whether it has additional restrictions on mainland China access, filing, traffic, or bandwidth.
Troubleshooting Lessons
The main takeaway from this incident: when troubleshooting CDN and HTTPS issues, do not start with buttons and rules. First confirm whether the onboarding model itself is viable.
Recommended evaluation order:
- Confirm who holds authoritative DNS.
- Confirm whether the CDN supports the current onboarding model.
- Confirm who issues the edge certificate and whether it is deployed.
- Confirm the SSL/TLS mode between CDN and origin.
- Only then handle page rules, redirects, caching, and access control.
For Cloudflare, specifically distinguish:
- Full setup: Cloudflare takes over Nameservers.
- Partial/CNAME setup: no NS switch; onboarding to Cloudflare via CNAME.
- Orange cloud proxy: only meaningful when Cloudflare supports and has completed onboarding.
- Universal SSL: solves the browser-to-Cloudflare edge certificate problem.
- Origin certificate: solves the Cloudflare-to-origin HTTPS problem.