Cloudflare Origin IP Whitelisting: 3 Methods to Block Non-CF Traffic and Protect Your Origin Server

Last month, my friend’s website ran into a frustrating issue. He had set up Cloudflare CDN for his personal blog, thinking it would protect against attacks, but after just a few days, the server was brought down anyway. Guess what happened? Attackers bypassed Cloudflare, found his origin server IP, and hammered it directly.

This actually happens quite often. Many people think that once you’re behind CF, you’re all set, but that’s not true. There are plenty of ways for origin IPs to leak—SSL certificate查询 sites can reveal it, historical DNS records get cached, subdomains bypass the CDN… Once attackers get your origin IP, even Cloudflare’s powerful protection won’t help because they’ll just attack your origin directly.

The bottom line is, relying on Cloudflare proxying alone isn’t enough to truly protect your origin. You need to configure your server firewall to only allow Cloudflare’s origin IP addresses and block all other traffic. Sounds complicated? Actually, it’s not that hard. Today I’ll walk you through three methods: Baota Panel is the simplest, pure Nginx is more flexible, and adding origin certificate verification is the most secure.

Whether you use Baota or raw command line, this article has you covered. I’ll give you the complete IP list, configuration steps, testing methods, and common issues—it’s basically a hands-on tutorial.

Why Limit Non-CF Traffic? Real Risks of Origin IP Leakage

Let’s talk about how origin IPs get leaked. I used to naively think that pointing your domain to Cloudflare was enough, but attackers have many tricks up their sleeves.

Common IP Leakage Methods

The most典型 one is SSL certificate lookup. If you check your certificate on sites like myssl.com, it might expose your real IP. Why? When a website using Cloudflare CDN enables SSL certificates, certificate检测 can reveal the origin server IP address. When I first learned about this, I was shocked—isn’t that basically advertising “come attack me”?

Then there’s historical DNS resolution records. Many DNS query services cache resolution results, and some providers claim to store data permanently. Even if you’ve switched your domain to Cloudflare now, they can still find your previous origin IP by checking historical records.

Subdomains or email systems are another major pitfall. Many people route their main site through CDN but forget about subdomains or email systems. Attackers ping your mail.example.com or examine an email’s raw headers, and boom—origin IP exposed. A friend of mine who does ops work got hit by this. His main site was locked down tight, but the email server’s IP was discovered and directly crushed.

How Bad Is the Damage After Leakage?

Once your origin IP is leaked, attackers can bypass Cloudflare and attack your server directly. DDoS traffic hits your origin straight on, instantly overwhelming your bandwidth. Even worse, they can scan your origin ports and probe for vulnerabilities to launch targeted attacks.

At this point, Cloudflare’s protection becomes useless. You see everything looking fine in the CF dashboard, while in reality your origin server is getting pummeled. People on V2EX forum have complained: “Server under attack, added CDN but origin IP was quickly discovered, where did things go wrong?”—This is exactly what happens when whitelisting isn’t properly configured.

Where to Find the Cloudflare Origin IP List? How to Get the Latest IP Ranges

When it comes to configuring whitelists, the first step is knowing where to find Cloudflare’s origin IP list. Actually, it’s not hard to find—CF has dedicated pages for this.

Official IP List Addresses

Cloudflare officially maintains three addresses:

• Complete list: https://www.cloudflare.com/ips/
• IPv4 list: https://www.cloudflare.com/ips-v4
• IPv6 list: https://www.cloudflare.com/ips-v6

I recommend bookmarking these pages for future updates and maintenance.

Current Latest Cloudflare IPv4 IP Ranges

As of now, Cloudflare’s IPv4 origin IP ranges include these 15 CIDR blocks (CIDR format is a concise way to represent a continuous range of IP addresses):

173.245.48.0/20
103.21.244.0/22
103.22.200.0/22
103.31.4.0/22
141.101.64.0/18
108.162.192.0/18
190.93.240.0/20
188.114.96.0/20
197.234.240.0/22
198.41.128.0/17
162.158.0.0/15
104.16.0.0/13
104.24.0.0/14
172.64.0.0/13
131.0.72.0/22

These 15 IP ranges cover approximately 1.78 million IP addresses.

IPv6 Address Ranges

If your server has IPv6 enabled, you’ll need to add these IPv6 ranges too:

2400:cb00::/32
2606:4700::/32
2803:f800::/32
2405:b500::/32
2405:8100::/32
2a06:98c0::/29
2c0f:f248::/32

Important note: Cloudflare’s IP list is updated periodically. It’s recommended to check the official page every month or two to ensure your whitelist is current. Otherwise, newly added CF IPs might get blocked by your firewall, causing origin failures.

Method 1 - Configure Cloudflare IP Whitelist with Baota Panel (Easiest)

If you use Baota Panel, this is super convenient. Baota’s built-in Nginx firewall plugin lets you configure whitelists with just mouse clicks, no need to write config files.

Step 1: Install Nginx Free Firewall Plugin

Open Baota Panel, click App Store in the left menu, then click the Third-party Apps category, and find Nginx Free Firewall. If it’s not installed, click the install button—takes just a few seconds.

Step 2: Configure IP Whitelist

After installation, click the Nginx firewall’s settings button to enter the firewall management interface.

1. Click Global Configuration on the left
2. Find the IP Whitelist section and click the Settings button
3. In the popup IP whitelist management window, add Cloudflare’s IPv4 address ranges one by one

Here’s a tip: Baota requires you to enter Start IP and End IP. But we have CIDR format (like 173.245.48.0/20)—how to convert?

You can use online tools (search “CIDR to IP range”) to convert CIDR to start and end IPs. For example, 173.245.48.0/20 corresponds to the range 173.245.48.0 to 173.245.63.255.

But honestly, manually converting 15 IP ranges is tedious. I usually just search online for ready-made Baota whitelist import lists—some blogs provide pre-converted IP ranges you can just copy and paste.

4. After adding all IP ranges, click the Import button
5. Restart Nginx service

Note: Baota Panel currently only supports IPv4, IPv6 whitelisting can’t be configured through the interface. If your server has IPv6 enabled, you’ll need to manually edit Nginx config files, or just use Method 2.

Step 3: Verify Configuration Works

After configuration, don’t rush off—test it:

• Use mobile 4G network (non-CF traffic) to directly access your origin IP, you should see a 403 Forbidden error
• Access through your domain name (via CF proxy), should display normally

If you get a 502 error, it means the whitelist configuration has issues, possibly incomplete IP ranges or firewall rules not saved. Check if Baota firewall is enabled and confirm all CF IP ranges were added.

Method 2 - Pure Nginx Whitelist Configuration (More Flexible)

If you don’t use Baota, or want a more flexible configuration approach, directly editing Nginx config files is also straightforward. Plus, this method supports IPv6, making it more comprehensive than Baota.

Step 1: Create Cloudflare IP Config File

SSH into your server and create a dedicated config file to manage the Cloudflare whitelist:

sudo nano /etc/nginx/cloudflare-whitelist.conf

Enter the following content in the file:

# Cloudflare IPv4 IP ranges
allow 173.245.48.0/20;
allow 103.21.244.0/22;
allow 103.22.200.0/22;
allow 103.31.4.0/22;
allow 141.101.64.0/18;
allow 108.162.192.0/18;
allow 190.93.240.0/20;
allow 188.114.96.0/20;
allow 197.234.240.0/22;
allow 198.41.128.0/17;
allow 162.158.0.0/15;
allow 104.16.0.0/13;
allow 104.24.0.0/14;
allow 172.64.0.0/13;
allow 131.0.72.0/22;

# Cloudflare IPv6 IP ranges
allow 2400:cb00::/32;
allow 2606:4700::/32;
allow 2803:f800::/32;
allow 2405:b500::/32;
allow 2405:8100::/32;
allow 2a06:98c0::/29;
allow 2c0f:f248::/32;

# Deny all other IPs
deny all;

Save the file (Ctrl+O, then Ctrl+X to exit).

Key point: The final deny all; is critical—it means all IPs except those allowed above are denied access. Don’t miss this line.

Step 2: Include Whitelist in Nginx Site Config

Edit your site configuration file. Config files are usually in /etc/nginx/sites-available/ (Debian/Ubuntu) or /etc/nginx/conf.d/ (CentOS).

sudo nano /etc/nginx/sites-available/your-site.conf

Add a line in the server block:

server {
    listen 80;
    server_name example.com;

    # Include Cloudflare whitelist
    include /etc/nginx/cloudflare-whitelist.conf;

    # Your other configs below...
    root /var/www/html;
    index index.html;
}

If your site also listens on port 443 (HTTPS), remember to add this line in the 443 server block too.

Step 3: Test and Reload Nginx

First test if the config file syntax is correct:

sudo nginx -t

If it says syntax is ok and test is successful, the config is fine. Then reload Nginx:

sudo systemctl reload nginx

Done! That’s it.

The advantage of this method: Config file is managed separately, future IP list updates just edit cloudflare-whitelist.conf, multiple sites can share this file. More flexible than Baota and supports IPv6.

Method 3 - Cloudflare Origin Server Certificate Configuration (Most Secure)

The previous two methods are already quite secure, but if you have extremely high security requirements, you can add another layer of origin server certificate verification. This way, even if your origin IP leaks, attackers directly accessing it will encounter certificate errors and can’t connect.

What is a Cloudflare Origin Server Certificate

Simply put, CF origin certificates are TLS certificates signed by Cloudflare, used only for encryption between Cloudflare and your origin server. Browsers don’t trust this certificate (only CF does), so when attackers directly access your origin IP, they’ll see certificate error warnings and connection will fail.

Combined with IP whitelisting, this provides dual protection: whitelist blocks non-CF traffic, certificate verification ensures only CF can establish encrypted connections.

Step 1: Generate Origin Server Certificate

Log into Cloudflare dashboard, select your domain, go to SSL/TLS → Origin Server page.

1. Click Create Certificate button
2. Select domains to protect (can use wildcards like *.example.com)
3. Choose maximum validity period of 15 years (since it’s CF’s own certificate, might as well pick the longest)
4. Click create

CF will generate two things:

• Origin Certificate: A PEM-format certificate string
• Private Key: Corresponding private key

Save both pieces of content to your server, for example:

sudo nano /etc/nginx/certs/cloudflare.crt
# Paste origin certificate content

sudo nano /etc/nginx/certs/cloudflare.key
# Paste private key content

Remember to set permissions to protect the private key:

sudo chmod 600 /etc/nginx/certs/cloudflare.key

Step 2: Configure Origin Certificate in Nginx

Edit your site config file and configure the certificate in the HTTPS server block:

server {
    listen 443 ssl http2;
    server_name example.com;

    # Use Cloudflare origin certificate
    ssl_certificate /etc/nginx/certs/cloudflare.crt;
    ssl_certificate_key /etc/nginx/certs/cloudflare.key;

    # Include IP whitelist
    include /etc/nginx/cloudflare-whitelist.conf;

    # Other configs...
}

If you want stricter verification, you can also add client certificate verification (requires downloading CF’s client certificate):

ssl_client_certificate /etc/nginx/certs/cloudflare-client.crt;
ssl_verify_client on;

Test and reload Nginx:

sudo nginx -t && sudo systemctl reload nginx

Tip: This method is suitable for scenarios with extremely high security requirements. For most webmasters, the previous IP whitelisting methods are sufficient—no need to overcomplicate things.

Testing if Configuration Works + Common Issue Troubleshooting

After configuration, don’t celebrate yet—test to be sure.

How to Test Configuration

Method 1: Use Non-CF Traffic to Directly Access Origin IP

Use mobile 4G network (or any non-Cloudflare network), enter your origin server IP address in the browser, like http://123.45.67.89. If configured correctly, you should see a 403 Forbidden page.

Method 2: Test with curl Command

On your local computer (not the server), run:

curl -I http://your-origin-IP

The result should be 403 Forbidden.

Method 3: Access via Domain Name (Through CF Proxy)

Enter your domain in the browser, like https://example.com, should access normally. If this step also shows 403, something’s wrong with the configuration.

Common Issues and Solutions

Issue 1: Website shows 502 error after configuration

Possible causes:

• Incomplete whitelist IP ranges, missing some CF IPs
• Nginx config file syntax errors

Solutions:

1. Run sudo nginx -t to check syntax
2. Check Nginx error logs: sudo tail -f /var/log/nginx/error.log
3. Confirm all 15 IPv4 ranges and 7 IPv6 ranges are added

Issue 2: Accessing via CF also shows 403

Possible causes:

• deny all; rule placed before allow rules
• CF origin IP not in your whitelist (CF might have updated IPs)

Solutions:

1. Check config file, ensure allow rules come before deny all;
2. Visit https://www.cloudflare.com/ips/ to confirm IP list is current

Issue 3: Baota Panel imported IP ranges but didn’t take effect

Possible causes:

• Firewall plugin not enabled
• Rules not saved or Nginx not restarted

Solutions:

1. Confirm Nginx firewall plugin is enabled (green icon)
2. Restart Nginx service in Baota Panel
3. Check Baota firewall logs for errors

Issue 4: IPv6 access still bypasses whitelist

Possible cause:

• Only configured IPv4 whitelist, forgot IPv6

Solutions:

1. Add CF’s IPv6 address ranges to whitelist
2. Or disable IPv6 in firewall (if IPv6 access isn’t needed)

Other Security Recommendations

Configuring the whitelist is just the first step, there are other security measures worth doing:

• Change SSH port: Default port 22 is easily scanned, change to another high port
• Regularly update system: Apply patches promptly to fix security vulnerabilities
• Hide Nginx version number: Add server_tokens off; in nginx.conf
• Use CF’s Under Attack mode: When facing intense attacks, enable the five-second shield

Cloudflare IP List Update Maintenance

As mentioned earlier, Cloudflare’s IP list changes, with new or adjusted IP ranges. If not updated promptly, new CF IPs might get blocked, causing website access issues.

Why Regular Updates Are Needed

Cloudflare has hundreds of data centers globally, and IP ranges adjust as infrastructure expands. While not changing daily, updates might happen every few months.

If your whitelist uses an old IP list, newly added CF origin IPs might get blocked by your firewall, causing access failures for users in some regions or rejected origin requests.

Manual Update Method

The simplest method is to periodically (like every 2-3 months) visit https://www.cloudflare.com/ips/ and check if there are new IP ranges.

If there are updates:

1. Edit your whitelist config file
2. Add new IP ranges
3. Test Nginx config: sudo nginx -t
4. Reload Nginx: sudo systemctl reload nginx

Automated Update Script (Optional)

If you want to save effort, use a simple bash script to automatically fetch the latest IP list and update configuration. Here’s a sample script:

#!/bin/bash
# Cloudflare IP whitelist auto-update script

CF_IPV4_URL="https://www.cloudflare.com/ips-v4"
CF_IPV6_URL="https://www.cloudflare.com/ips-v6"
NGINX_CONF="/etc/nginx/cloudflare-whitelist.conf"
BACKUP_CONF="/etc/nginx/cloudflare-whitelist.conf.bak"

# Backup existing config
cp $NGINX_CONF $BACKUP_CONF

# Generate new config
echo "# Cloudflare IP Whitelist - Auto-generated on $(date)" > $NGINX_CONF
echo "" >> $NGINX_CONF

# IPv4 ranges
echo "# IPv4 ranges" >> $NGINX_CONF
curl -s $CF_IPV4_URL | sed 's/^/allow /' | sed 's/$/;/' >> $NGINX_CONF
echo "" >> $NGINX_CONF

# IPv6 ranges
echo "# IPv6 ranges" >> $NGINX_CONF
curl -s $CF_IPV6_URL | sed 's/^/allow /' | sed 's/$/;/' >> $NGINX_CONF
echo "" >> $NGINX_CONF

# Deny other IPs
echo "# Deny all other IPs" >> $NGINX_CONF
echo "deny all;" >> $NGINX_CONF

# Test config
if nginx -t; then
    echo "Config file syntax correct, reloading Nginx..."
    systemctl reload nginx
    echo "✓ Cloudflare whitelist updated successfully!"
else
    echo "✗ Config file has errors, restoring backup..."
    cp $BACKUP_CONF $NGINX_CONF
    echo "Original config restored, please check errors"
fi

Save as /root/update-cf-whitelist.sh and add execute permission:

chmod +x /root/update-cf-whitelist.sh

Then set up a cron job to run it automatically once a month:

crontab -e

Add a line:

0 3 1 * * /root/update-cf-whitelist.sh >> /var/log/cf-whitelist-update.log 2>&1

This will automatically update the IP list at 3 AM on the 1st of each month, logging to /var/log/cf-whitelist-update.log.

Tip: Before using the script, run it manually once to test and ensure it works before setting up the scheduled task. If the script has bugs, automated execution could break the configuration.

Conclusion

After all this, the core message is simple: To properly protect your origin, configuring Cloudflare whitelisting is essential.

Let’s recap the three methods:

• Baota Panel whitelist: Easiest, point-and-click setup, suitable for beginners. Downside is IPv4-only support.
• Pure Nginx configuration: More flexible, supports IPv6, config file easy to manage and update, suitable for those with some Linux knowledge.
• Origin server certificate verification: Most secure, dual protection, suitable for scenarios with extremely high security requirements.

Whichever you choose, remember to test after configuration. Access the origin IP directly via mobile 4G—seeing 403 means success. Then access via domain name to ensure normal operation.

One last reminder: Cloudflare’s IP list gets updated, so remember to check regularly or use an automated script to save effort. Don’t configure it once and forget about it—months later CF adds new IP ranges, your whitelist is still old, and then access problems will be a headache.

If this article helped you, share it with other webmaster friends using Cloudflare. If everyone protects their origins well, attackers won’t have such an easy time.

Oh, and you can immediately check if your origin IP has already leaked—visit SSL detection sites like myssl.com to check your certificate and see if the origin IP is exposed. If it’s already leaked, follow the methods in this article to quickly configure whitelisting—better late than never.

Published on: Nov 21, 2025 · Modified on: Dec 4, 2025

Easton

Technology