Accelerating Cloudflare for Domestic Use Without Modifying NS: Complete Tutorial on CF for SaaS + DNS Geo-based Routing

Wapuu
, , ,
1

Background

Cloudflare’s Anycast network is not very friendly to users within mainland China—latency is high, speeds are slow, and sometimes connectivity fails entirely. A common solution is to use CloudflareSpeedTest (CFST) to identify the optimal Cloudflare edge IP address accessible from within China, then implement DNS-based geolocation routing so that domestic users resolve to the optimized IP while overseas users follow the default route.

However, many tutorials omit a critical prerequisite: your domain must be hosted on Cloudflare to use Cloudflare IPs. If your domain is not on Cloudflare and you directly point your DNS to a Cloudflare IP, Cloudflare will not recognize your domain; requests reaching the edge node will return an error.

Typically, onboarding with Cloudflare requires changing your domain’s nameservers (NS) to Cloudflare’s, but doing so forfeits the geolocation-routing capabilities of third-party DNS services. This article introduces an alternative approach that avoids changing NS records: Cloudflare for SaaS (Custom Hostnames) + Third-Party DNS Geolocation Routing.

Architecture Overview

Domestic Users (China Telecom / China Unicom / China Mobile)
    ↓ DNS geolocation routing
    ↓ A record → 104.29.124.212 (CFST-optimized Cloudflare IP)
    ↓
Cloudflare Edge Node
    ↓ Cloudflare for SaaS proxying
    ↓ Host: example.com → matches custom hostname
    ↓ fallback origin → origin.example.net
    ↓
Origin Server 47.x.x.x

Overseas Users
    ↓ Default DNS routing
    ↓ A record → 47.x.x.x (direct origin connection)
    ↓
Origin Server 47.x.x.x

Core Concept:

  1. Use a domain already on Cloudflare (e.g., example.net) as your SaaS Provider Zone.
  2. Within that zone, create a custom hostname pointing to your actual domain (e.g., example.com).
  3. Cloudflare issues an SSL certificate for example.com and proxies traffic to it.
  4. Configure geolocation-aware DNS resolution via your third-party DNS provider: domestic users resolve to the optimized Cloudflare IP; overseas users resolve directly to your origin.

Step-by-Step Implementation

Step 1: Prepare Your SaaS Provider Zone

You need a domain already on Cloudflare. If you don’t have one, first onboard any domain onto Cloudflare (this requires changing its nameservers to Cloudflare’s).

Step 2: Create a Fallback Origin

Within your SaaS Provider Zone, create a DNS record pointing to your origin server’s IP address. This record must be proxied (orange cloud enabled):

# Create origin DNS record (must set "proxied": true)
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/dns_records" \
  -H "X-Auth-Email: [email protected]" \
  -H "X-Auth-Key: your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"type":"A","name":"origin","content":"your-origin-IP","ttl":1,"proxied":true}'

Then configure it as the fallback origin:

curl -X PUT "https://api.cloudflare.com/client/v4/zones/{zone_id}/custom_hostnames/fallback_origin" \
  -H "X-Auth-Email: [email protected]" \
  -H "X-Auth-Key: your-api-key" \
  -H "Content-Type: application/json" \
  -d '{"origin":"origin.example.net"}'

Wait until its status becomes active.

Pitfall #1: The fallback origin DNS record must be proxied (orange cloud). If it’s DNS-only (gray cloud), you’ll get the error:
"DNS records are not setup correctly. Origin should be a proxied A/AAAA/CNAME dns record."

Step 3: Create a Custom Hostname

curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone_id}/custom_hostnames" \
  -H "X-Auth-Email: [email protected]" \
  -H "X-Auth-Key: your-api-key" \
  -H "Content-Type: application/json" \
  -d '{
    "hostname": "example.com",
    "ssl": {"method": "txt", "type": "dv"}
  }'

The response includes:

  • ownership_verification: TXT record name and value for ownership verification
  • ssl.validation_records: ACME challenge TXT record for SSL issuance

Pitfall #2: Do not set custom_origin_server, unless you’re certain the specified hostname exists as a DNS record within your Cloudflare zone. If you specify an external domain (e.g., files.example.com hosted on a third-party DNS), you’ll receive the error:
"The custom origin hostname you specified does not exist on Cloudflare as a DNS record in your zone."
Using the fallback origin is simpler and more reliable.

Step 4: DNS Verification

Add two TXT records in your DNS management panel:

  1. Ownership Verification: _cf-custom-hostname.example.com → UUID returned by Cloudflare
  2. SSL Verification: _acme-challenge.example.com → ACME challenge value returned by Cloudflare

The SSL certificate (issued by Let’s Encrypt or Google Trust Services) usually provisions within minutes. Ownership verification may take longer.

Pitfall #3: Ownership verification can be slow. Even after correctly setting the TXT records, Cloudflare may show pending status for 10+ minutes—or longer. During this time, you might see the message "custom hostname does not CNAME to this zone"—this is not necessarily an error, just Cloudflare still performing checks. Be patient. If verification hasn’t completed after 1 hour, verify the TXT records resolve correctly from 1.1.1.1.

Step 5: Verify Cloudflare Proxying

Once the custom hostname status changes to active, test whether Cloudflare proxying works:

# Force connection through Cloudflare IP using --connect-to
curl -s -o /dev/null -w "HTTP %{http_code}, %{size_download} bytes\n" \
  --connect-to example.com:443:CF-optimized-IP:443 \
  https://example.com/ --max-time 15

This should return HTTP 200.

Pitfall #4: Strict SNI validation at the origin. If your origin server (e.g., OpenResty/Nginx) enforces strict SNI validation—accepting TLS connections only for specific hostnames—Cloudflare’s origin request may fail with HTTP 525 due to SNI mismatch. Using the fallback origin (a proxied DNS record) avoids this issue because Cloudflare handles SNI internally. With custom_origin_server, Cloudflare uses that hostname as the SNI during origin connection—and your origin may reject it.

Step 6: Configure Geolocation-Based DNS Resolution

In your third-party DNS management panel (e.g., Rainbow Aggregated DNS), add geolocation-based A records:

@  A  telecom  104.29.124.212   # China Telecom users → Cloudflare
@  A  unicom   104.29.124.212   # China Unicom users → Cloudflare
@  A  mobile   104.29.124.212   # China Mobile users → Cloudflare
@  A  default  47.x.x.x         # All other users → direct origin

Pitfall #5: Supported geolocation line values vary across DNS providers. Rainbow Aggregated DNS supports telecom/unicom/mobile/edu/default, but does not support geographic labels like china or overseas. Always verify which line values your DNS provider supports before configuring.

Step 7: Obtain an Optimized Cloudflare IP

Run CFST on a server located within mainland China:

./CloudflareST -n 500 -t 5 -sl 5 -dn 2

Notes:

  • Must run inside mainland China for meaningful results.
  • Some Tencent Cloud data centers completely block Cloudflare IPs; Alibaba Cloud tends to offer better accessibility.
  • Avoid excessive concurrent tests (-dn), as they may trigger rate limiting and yield all-zero results.

Rainbow Aggregated DNS also has built-in Cloudflare IP optimization. You can configure automatic update tasks via its web dashboard—eliminating manual CFST execution.

Common Pitfalls Summary

Issue Symptom Solution
Fallback origin not activating "DNS records are not setup correctly" Ensure the origin DNS record has "proxied": true
custom_origin_server error "does not exist as a DNS record in your zone" Omit custom_origin_server; rely on fallback origin instead
HTTP 525 SSL Handshake Failed Cloudflare-origin SSL handshake failure Caused by strict SNI validation at origin; resolved by using fallback origin
Slow ownership verification Status remains pending indefinitely Confirm TXT records are correct and propagated; wait patiently (up to 1 hr); verify resolution from 1.1.1.1
HTTP 409 Conflict Access via Cloudflare IP returns 409 Custom hostname is still pending; wait for active status
Invalid geolocation line "Invalid line" error Check supported line values for your DNS provider (e.g., telecom, not china)
CFST returns all zeros Download speed shows 0.00 MB/s Reduce concurrency (-dn 2 recommended) to avoid rate limiting
custom_origin_sni unavailable Error code 1456 Enterprise-only feature; free tier users should use fallback origin

Applicable Scenarios

:white_check_mark: Suitable when:

  • You wish to avoid changing nameservers to Cloudflare (to retain third-party DNS geolocation features)
  • You already own at least one domain on Cloudflare, usable as a SaaS Provider Zone
  • You need CDN acceleration for domestic users but prefer not to use domestic CDNs (e.g., due to ICP filing requirements)

:cross_mark: Not suitable when:

  • You have no domains on Cloudflare (you must onboard at least one first)
  • Your origin server is already in mainland China and doesn’t require CDN acceleration (direct connection is faster)
  • Your application is extremely latency-sensitive (optimized Cloudflare IPs typically incur 100–200 ms latency)

References