Is Cloudflare Really a 'Slowflare CDN'? 3 Steps to Optimize IP Selection and Boost Speed by 5x

Introduction

Ever experienced this? You test your website from overseas and it loads instantly - smooth as butter. Then friends from China tell you it takes several seconds to load, sometimes even timing out. To be honest, I was completely confused the first time this happened. My server configuration was fine, CDN was enabled - why was it so slow?

Later, I discovered the culprit was Cloudflare. Despite being the world’s largest CDN provider, Cloudflare has earned the nickname “Slowflare CDN” in China. This isn’t your server’s fault, nor is it your website’s code - it’s because Cloudflare assigns poor quality IP nodes to Chinese visitors with high latency, packet loss, and slow speeds.

The good news? This is totally fixable. Using CloudflareSpeedTest, an open-source tool, we can identify which Cloudflare node IPs perform best in China and manually configure these “optimized IPs.” The whole process takes about 10 minutes, and can improve your website’s access speed by 3-5x - in some cases reducing latency from 280ms down to 45ms.

In this article, I’ll share the complete optimized IP configuration workflow, including:

• Tool download and usage (Windows/Linux/Mac compatible)
• How to read test results and select the best IPs
• 3 configuration methods (from simple to advanced)
• Troubleshooting guide and common pitfalls

Let’s dive in.

Why Is Cloudflare So Slow in China? Understanding the Fundamentals

Before we optimize, let’s understand why it’s slow - this way you’ll know exactly what you’re doing when configuring.

Cloudflare uses Anycast technology. Simply put, they deploy nodes worldwide and assign the same IP address to all nodes. When you access that IP, the network automatically routes your request to the “nearest” node. Sounds great, right? The problem lies in that “nearest” part.

“Nearest” here doesn’t mean geographically nearest, but rather network routing nearest - measured by hop counts and network topology. In reality, the node the algorithm considers “nearest” might actually be very slow when accessed from China. Your request might detour through Hong Kong, hop to Japan, and finally reach the target node, naturally increasing latency.

There’s another critical issue: Cloudflare’s China nodes are not available to free users. Yes, Cloudflare does have data centers in China, but only enterprise paying customers can use them. We free users get assigned to nearby nodes in Hong Kong, Japan, Korea, or even the US West Coast. Combined with inconsistent international bandwidth quality and peak-hour congestion, slow speeds become the norm.

I’ve tested this before - default assigned IPs often have 200-300ms latency, sometimes with packet loss. But among Cloudflare IPs, some nodes have only 30-80ms latency - several times faster. That’s why we need to manually “optimize” - finding those node IPs with good China access quality and forcing our website to use them.

CloudflareSpeedTest Tool: Find the Fastest IP in 10 Minutes

Theory covered, let’s get practical. The tool we’ll use is CloudflareSpeedTest, an open-source GitHub project (XIU2/CloudflareSpeedTest) with 20k+ stars - pretty reliable.

Download and Installation

This tool doesn’t need installation - just download and run. Choose the version for your system:

Windows Users:

1. Go to the GitHub Releases page (https://github.com/XIU2/CloudflareSpeedTest/releases)
2. Download CloudflareST_windows_amd64.zip
3. Extract to any folder
4. You should see CloudflareST.exe

Linux Users:

mkdir cfst
cd cfst
wget https://github.com/XIU2/CloudflareSpeedTest/releases/download/v2.3.4/CloudflareST_linux_amd64.tar.gz
tar -zxf CloudflareST_linux_amd64.tar.gz
chmod +x CloudflareST

Mac Users: Download CloudflareST_darwin_amd64.tar.gz (Intel chips) or CloudflareST_darwin_arm64.tar.gz (M-series chips), extract and run in Terminal.

Start Testing

Simplest usage:

Windows: Double-click CloudflareST.exe, a command window pops up, and just wait.

Linux/Mac: Run ./CloudflareST in Terminal

You’ll see output like this:

开始延迟测速（模式：TCP, 端口：443, 范围：1-200）
进度: [==================================================] 100%
开始下载测速（下载速度下限：0.00 MB/s, 数量：10）
下载测速进度: [==================================================] 100%

The whole process takes about 5-15 minutes, depending on your network and parameter settings. I usually grab a coffee while it runs automatically.

Understanding Test Results

After testing completes, a result.csv file is generated that you can open with Excel or Notepad. Focus on these columns:

1. IP Address: These are the available Cloudflare node IPs you’ll configure
2. Average Latency: The most critical metric! Lower is better, aim for <100ms
3. Download Speed: Affects large file loading, aim for >5MB/s
4. Packet Loss Rate: Must be 0%, skip any IPs with packet loss

Generally, the top few IPs are good choices. For example, my latest test had a Japanese node IP in first place with 45ms latency, 18MB/s download speed, and 0% packet loss - perfect.

One pitfall to watch out for: If you see extremely low average latency like 0.3ms or 0.5ms, you probably have a proxy running. Turn off the proxy and retest, otherwise results will be inaccurate. I made this mistake the first time, selected a “super fast” IP and configured it, only to realize something was completely wrong.

Advanced Techniques: Parameter Tuning for More Accurate Results

The basic usage is sufficient, but if you want more precise results, you can adjust some parameters.

Avoid Peak Hours

This is super important! 8 PM to midnight is peak internet usage time, and test results will differ significantly from other times. I suggest choosing:

• Daytime (10 AM - 4 PM)
• Early morning (1 AM - 5 AM)

Weekends also tend to have more stable results than weekdays.

Common Parameter Configurations

CloudflareSpeedTest supports many parameters, here are some useful ones:

# Windows example
CloudflareST.exe -n 500 -t 10 -dn 20 -dt 15

# Linux/Mac example
./CloudflareST -n 500 -t 10 -dn 20 -dt 15

Parameter explanations:

• -n 500: Test thread count, default 200, increase to 500 to scan more IPs
• -t 10: Test each IP 10 times for latency (default 4), more stable results
• -dn 20: Download test quantity of 20 (default 10), compare more IPs
• -dt 15: Download test duration 15 seconds (default 10), more accurate

To be honest, increasing parameters makes testing take longer, possibly 20-30 minutes. But if you want particularly accurate results, it’s worth the time.

Specify Region Testing

If you want to test only specific region nodes, use the -cfcolo parameter:

# Test only Hong Kong, Tokyo, San Jose nodes
CloudflareST.exe -cfcolo HKG,NRT,SJC

Common region codes:

• HKG: Hong Kong
• NRT: Tokyo
• SJC: San Jose, USA
• LAX: Los Angeles, USA
• SIN: Singapore

This feature is quite useful - for example, if your users are mainly in Asia, you can test only Asian nodes to save time.

Use Cloudflare Official Test URL

By default, the tool uses third-party test files. For more accuracy, use Cloudflare’s official test URL:

CloudflareST.exe -url https://speed.cloudflare.com/__down?bytes=500000000

This URL downloads 500MB of data for testing, with results closer to actual usage. Of course, testing time will be longer.

Configure Optimized IP to Website: 3 Methods to Choose From

After testing and selecting IPs, next is configuring them to your website. I’ll introduce 3 methods from simple to advanced - choose based on your situation.

Method 1: Direct DNS Record Modification (Simplest, 5 Minutes)

This is the most direct method, suitable for personal websites and small traffic sites.

Steps:

1. Log into your DNS provider (Alibaba Cloud/Tencent Cloud/Cloudflare all work)
2. Find your domain’s DNS record management
3. Change the A record IP to the optimized IP from testing
4. Save and wait for DNS propagation (usually 5-10 minutes)

For example, if your best IP is 104.16.123.45, change:

A Record: blog.example.com → Original IP

to:

A Record: blog.example.com → 104.16.123.45

Pros: Super simple configuration, done in minutes.

Cons: Cloudflare dashboard will show an “IP exposed” yellow warning. Don’t worry, this doesn’t affect CDN functionality - it just reminds you that your origin IP is exposed. Also, if this optimized IP becomes slow someday, you’ll need to manually change it again.

Method 2: Use Optimized Domain CNAME (Recommended, Fault Tolerant)

This method works by CNAMEing your domain to a Cloudflare domain that already resolves to optimized IPs. Many large company Cloudflare domains come with built-in optimization.

Common Optimized Domains:

• time.cloudflare.com
• www.visa.com
• www.csgo.com
• shopify.com
• icook.hk

Steps:

1. Delete the original A record at your DNS provider
2. Add CNAME record pointing to optimized domain
3. Save and propagate

For example:

CNAME: blog.example.com → www.visa.com

You might ask, why do these domains come with optimization? Because they’re large company domains, Cloudflare assigns them better quality IP nodes, especially optimized for mainland China access.

Pros: Also simple to configure, with some fault tolerance. If one optimized domain fails, just switch to another.

Cons: These optimized domains might fail (though unlikely), requiring periodic speed checks.

Method 3: ISP-Specific Resolution (Advanced Solution, Maximum Optimization)

If you run a high-traffic website or demand extremely high speeds, use this method. The principle is resolving different optimized IPs for China Telecom, China Unicom, and China Mobile users separately.

Why Separate by ISP?

Because the three major ISPs have different network routes. IPs fast for Telecom users might not be fast for Mobile users. Separate configuration ensures optimal experience for each ISP’s users.

Steps:

1. Test Separately: Test once on each of Telecom, Unicom, Mobile networks, getting 3 optimal IPs

   • Telecom optimal IP: let’s say 104.16.111.11
   • Unicom optimal IP: let’s say 104.16.222.22
   • Mobile optimal IP: let’s say 104.16.333.33

2. Configure Smart Resolution:

   In DNSPod or Alibaba Cloud DNS (must support split routing):

   • Add A record, line type “Telecom”, IP 104.16.111.11
   • Add A record, line type “Unicom”, IP 104.16.222.22
   • Add A record, line type “Mobile”, IP 104.16.333.33
   • Add A record, line type “Default”, IP for the overall best one

3. Save and Propagate

Pros: Maximum optimization, best experience for each ISP’s users.

Cons: Slightly more complex configuration, requires testing 3 times, and needs regular maintenance (monthly retesting recommended). Also, must use a DNS provider supporting smart resolution - free Cloudflare DNS doesn’t support this feature.

My Recommendation

• Personal blogs/small sites: Use Method 1 or 2, simple and sufficient
• Traffic in thousands to tens of thousands: Use Method 2, best cost-effectiveness
• High-traffic sites/speed-sensitive: Use Method 3, worth the effort for results

To be honest, I use Method 2 for my own blog. Configure once and basically forget about it - quite satisfied with the speed.

Effect Verification and Troubleshooting

After configuration, how do you know if it worked? And what if you run into problems? Let’s talk about it.

Verify Optimization Results

Method 1: Ping Test

Simplest direct way, open command line:

Windows:

ping blog.example.com

Mac/Linux:

ping -c 10 blog.example.com

Check latency data:

• Before optimization: Usually 200-300ms, even higher
• After optimization: Ideally 30-80ms

I tested my own blog before - 280ms latency before optimization, became 45ms after, over 6x difference.

Method 2: Browser Developer Tools

1. Press F12 in browser to open developer tools
2. Switch to “Network” tab
3. Refresh page
4. Check resource loading times

Focus on:

• First screen load time: 5+ seconds before, should drop to 1-2 seconds after
• Static resource loading: CSS, JS, image loading times will significantly shorten

Method 3: Third-Party Testing Tools

Use webmaster tools’ multi-location ping tests:

• Webmaster Home: http://ping.chinaz.com
• 17CE: https://www.17ce.com

Shows access speeds nationwide across different ISPs for more comprehensive data.

My Real Test Data

Let me show you my comparison:

Before Optimization:

• Ping latency: 280ms
• First screen load: 5.2 seconds
• Static resource average load: 800ms

After Optimization:

• Ping latency: 45ms
• First screen load: 1.1 seconds
• Static resource average load: 150ms

Speed Improvement: 4.7x faster.

Common Problem Troubleshooting

You might encounter some issues during configuration, here are common ones:

Problem 1: Website Won’t Load or Shows “Too Many Redirects”

This problem is most likely an SSL/TLS setting issue.

Solution:

1. Log into Cloudflare dashboard
2. Select your domain
3. Click “SSL/TLS” in left menu
4. On “Overview” page, change encryption mode to “Full” or “Full (strict)”

Explanation: If set to “Flexible” mode, Cloudflare to origin uses HTTP, but browser to Cloudflare uses HTTPS, causing infinite redirects. Changing to “Full” mode uses HTTPS throughout and resolves the issue.

Problem 2: No Significant Speed Improvement After Configuration

Possible reasons:

Reason 1: Tested While Using Proxy Check if you had proxy software running during testing. If so, turn off proxy and retest. I stepped into this pitfall myself - the IPs were completely wrong.

Reason 2: Origin Server Itself Is Slow Optimized IPs only improve the CDN portion. If your origin server response is slow, optimization effect is limited. Test origin speed with curl:

curl -o /dev/null -s -w 'Total: %{time_total}s\n' https://your-origin-server.com

Reason 3: Wrong IP Selection The #1 IP in result.csv isn’t necessarily right for you. Try other IPs in the top 5 to see which works best.

Problem 3: Optimized IP Slows Down Again After a While

This is normal. Cloudflare IP node quality changes, possibly due to:

• A node’s traffic increased
• Network routes adjusted
• ISP policies changed

Solution:

• Retest monthly and update optimized IPs
• Or use automation tools like GetCFipToDns that periodically test and update DNS resolution automatically

Problem 4: China Access Works, But Overseas Becomes Slower

If your website mainly targets Chinese users, ignore this problem. But if you have overseas users, consider:

• Use Method 3’s ISP-specific resolution, add an “Overseas” route pointing to default Cloudflare nodes
• Or use GeoDNS service - Chinese users use optimized IPs, overseas users use normal routing

Automation Operations Suggestions

If you don’t want to manually retest monthly, consider these approaches:

1. Scheduled Tasks: Write a script to periodically run CloudflareSpeedTest, updating result.csv
2. Monitoring Alerts: Use monitoring tools (like Uptime Robot) to monitor website speed, get notified when it slows
3. Auto-Update DNS: Use GetCFipToDns tool that can automatically test and update DNS resolution, saves a lot of trouble

I use Method 2 myself, combined with manual monthly retesting - running pretty stable so far.

Conclusion

After all that, let’s summarize.

Slow Cloudflare access in China isn’t your problem - it’s a node assignment issue. Through CloudflareSpeedTest testing + optimized IP configuration, you can improve website access speed by 3-5x in 10-30 minutes. The core is three steps:

1. Test: Download CloudflareSpeedTest, run a speed test (avoid peak hours, remember to turn off proxy)
2. Select IP: Pick IPs from result.csv with low latency, high speed, zero packet loss
3. Configure: Choose appropriate configuration method based on your situation (direct DNS change, CNAME, or ISP-specific resolution)

Remember to verify results after configuration, refer to the troubleshooting section if you encounter problems. Also don’t forget - optimized IPs aren’t set-and-forget, monthly retesting recommended to maintain optimal state.

If you’re currently using Cloudflare, give this method a try. From my own experience, after configuring once, website access experience really improves a lot, and users stop complaining about slow loading.

Questions welcome in comments, and feel free to share your before/after data comparisons to see how many times faster you got.

Published on: Dec 1, 2025 · Modified on: Dec 4, 2025

Easton

Technology