I did not expect to end up writing a technical post like this, but after being pushed around by paid CDNs and WAF services long enough, I finally worked out a workaround that is both cheap and practical.
The goal was simple: keep fast domestic access through an existing CDN, while still allowing overseas connectivity for a feature that depends on foreign servers. In the end, I found a way to route international traffic through Cloudflare for free, without moving the main domain’s NS to Cloudflare.
Why I needed this
After switching the blog to a new caching and optimization plugin, I discovered that one of its image optimization features only works if the site can communicate with servers outside China.
Previously, the setup was very blunt: just block foreign IPs entirely. That had two obvious advantages. First, it felt safer. Second, it avoided wasting Tencent Cloud CDN traffic. Since that traffic is billed by usage, and stories about unexpectedly huge bills are not exactly rare, I had no desire to take chances.
The problem was that I did not want to give up the image optimization feature either. So the real challenge became this: how do you keep domestic access on the existing domestic CDN, while still letting overseas requests reach the site through a separate path?
The idea
While looking through DNSPod, I noticed that DNS resolution rules could be split between domestic and global routes. That immediately suggested a workable approach:
- domestic users resolve to Tencent Cloud CDN
- overseas users resolve to a separate CDN
That way, domestic speed stays intact, foreign traffic does not eat into the domestic CDN bill, and the site can still communicate with the external image optimization service.
So the next question was obvious: what free CDN can handle overseas traffic reliably?
I tried quite a few. Cloudflare was the first one that came to mind, but it seemed to require NS delegation, which would have broken the setup I wanted, so I gave up on it at first. Then came a round of experiments with Amazon CloudFront, UpYun, Yundun, Jiasule, and others. After wasting enough time, I ended up right back where I started: Cloudflare was still the most appealing choice because it was simple and came with far fewer annoying restrictions.
The only issue was how to use it without handing over the main domain’s NS.
That is where Cloudflare for SaaS and custom hostnames come in.
The basic setup
You need two domains:
a.com: a spare domain you do not actively use1.com: your real site domain, the one visitors actually access
Do not mix them up. The spare domain is only there to anchor Cloudflare’s SaaS setup. The live domain remains on its existing DNS provider.
The first step is to connect a.com to Cloudflare using NS delegation.
Once a.com is active in Cloudflare, go into that domain’s dashboard, open SSL/TLS, and then find Custom Hostnames.
Enable Cloudflare for SaaS
Turn on Cloudflare for SaaS.
For up to 100 websites, this feature is free, so for a small setup it is usable without extra cost. However, Cloudflare still requires you to bind a Visa card or PayPal account before enabling it. I used PayPal.
Set up the fallback origin
Go back to the DNS records for a.com and add any subdomain you like, for example:
1.a.com
Point that record to the real server IP of your website 1.com.
This 1.a.com record will be used as the fallback origin.
After that, return to Custom Hostnames, enter 1.a.com as the fallback origin, and save it.
Then wait for it to become active.
Add your real domain as the custom hostname
When the fallback origin shows as valid, add a new custom hostname.
That custom hostname should be your real domain, which in this example is:
1.com
For the minimum TLS version, 1.1 is a reasonable choice.
After that, click Add Custom Hostname.
Verify the hostname with TXT records
At this point, Cloudflare will require ownership verification for 1.com.
Important detail: a.com is hosted on Cloudflare NS, but 1.com is still using DNSPod NS and remains managed there. So the verification records must be added in DNSPod, not in Cloudflare.
Cloudflare will provide two TXT records for verification.
One is for 1.com, and the other is for a subdomain in the form:
_cf-xxxxxxxxx.1.com
Each comes with its own TXT value.
In DNSPod:
- for the first TXT record, use
@as the host record, then fill in the TXT value beginning with something likeca3-xxxxxxxxx - for the second TXT record, use only
_cf-xxxxxxxxxxxas the host record; do not include the trailing.1.com, then enter the other TXT value such asb8b7841c-xxxxxxxx
Once both records are added, wait for propagation. Usually it only takes a few minutes.
What has been completed so far
By this stage, the Cloudflare side is essentially done:
- Two domains were prepared:
a.comas the spare domain delegated to Cloudflare, and1.comas the actual production domain. - Cloudflare for SaaS was enabled, which required binding an international card or PayPal.
- A fallback origin was created:
1.a.com, pointing to the real server IP. - A custom hostname was added:
1.com, which is the actual domain visitors use. - The two TXT verification records for
1.comwere added in DNSPod and allowed to propagate.
The final CNAME routing
Now comes the last part: making the real domain 1.com use Cloudflare through CNAME.
After the Cloudflare platform setup is complete, you will be given an authoritative DNS CNAME record.
In DNSPod, first create that CNAME record using:
- host record:
_acme-challenge - record value:
<hostname>.xxxxxx.cloudflare.com
The <hostname> part is your domain. In this example, that means 1.com.
After that, create one more CNAME record:
- host record:
@ - line: overseas
- record value:
1.a.com
This makes direct access to 1.com from foreign IPs resolve through the overseas line to 1.a.com, which is the fallback origin configured inside Cloudflare.
And that is also why the fallback origin must point to the real origin server IP.
How the traffic flows
Once everything is in place, the behavior becomes very straightforward.
Domestic visitors
Domestic IP requests are identified by DNSPod and resolved through the domestic route.
The path is:
- DNSPod decides the request is domestic
- the domestic CNAME record is used
- traffic goes through Tencent Cloud CDN
- request reaches the origin server
Overseas visitors
Foreign IP requests are resolved through the overseas route.
The path is:
- DNSPod decides the request is overseas
- the overseas CNAME record is used
- traffic goes through Cloudflare CDN
- request reaches the origin server
Why this setup is worth using
The nice part is that each side does what it is best at.
Domestic traffic stays on Tencent Cloud, so speed for local users remains strong. Overseas traffic goes through Cloudflare, which improves external access and maintains connectivity with services that need foreign network reachability.
At the same time, the free Cloudflare layer avoids sending international traffic through the paid domestic CDN. That keeps the bill under control, reduces wasted bandwidth, and avoids sacrificing features just to stay safe.
In short: domestic users get the domestic CDN, overseas users get Cloudflare, and both paths stay usable and fast.