Cloudflare回源IP白名单配置:3种方法彻底封锁非CF流量保护源站

上个月我朋友的网站遇到了件挺头疼的事。他的个人博客套了Cloudflare CDN,本想着能抵御些攻击,结果没几天服务器还是被打垮了。你猜怎么着?攻击者直接绕过Cloudflare,找到了他的源站IP,然后对着源站一顿猛锤。这事其实挺常见的。很多人以为套上CF就万事大吉了,其实不然。源站IP泄露的途径多着呢——SSL证书查询网站能看到、历史DNS记录被缓存、子域名没走CDN…只要攻击者拿到你的源站IP,Cloudflare再强大的防护也没用,人家直接打你源站。说白了,想真正保护好源站,光靠Cloudflare代理是不够的。你得在服务器端配置防火墙,只允许Cloudflare的回源IP访问,把其他所有流量都拦在门外。听起来挺麻烦?其实配置起来没那么复杂,今天就跟你聊聊三种方法:宝塔面板最简单、纯Nginx更灵活、再加上源证书验证那就是最安全的了。不管你用的是宝塔还是纯命令行,这篇文章都能帮到你。我会把完整的IP列表、配置步骤、测试方法、常见问题全给你讲清楚,就差手把手教你配置了。

为什么要限制非CF流量?源站IP泄露的真实风险

先说说源站IP是怎么泄露的吧。我之前也天真地以为,域名解析到Cloudflare就够了,谁知道攻击者的手段多着呢。

常见的IP泄露途径

最典型的就是SSL证书查询。你去myssl.com这类网站检测证书,很可能就会暴露真实IP。为啥?网站套了Cloudflare的CDN后,如果开启了SSL证书,检测SSL证书的时候会显示你的源站IP地址。我第一次知道这事的时候挺震惊的,这不是明摆着告诉别人”来攻击我”吗? 还有历史DNS解析记录。互联网上很多DNS查询服务会缓存解析结果,有些服务商号称数据永久存储。你现在把域名换到Cloudflare了,但人家查查历史记录,还是能找到你之前的源站IP。 子域名或邮件系统也是个大坑。很多人主站走了CDN,但忘了子域名或邮件系统。攻击者ping一下你的mail.example.com,或者查看一封邮件的原始头部,源站IP就这么暴露了。我有个做运维的朋友就栽在这上面,主站防护得滴水不漏,结果邮件服务器的IP被找到,直接被打崩。

泄露后的危害有多大

源站IP一旦泄露,攻击者就能绕过Cloudflare直接攻击你的服务器。DDoS流量直达源站,瞬间把你的小水管打爆。更麻烦的是,他们还能扫描你的源站端口、探测漏洞,针对性地发起攻击。这时候Cloudflare的防护就形同虚设了。你在CF后台看到的是一片祥和,实际上你的源站早就被打得七荤八素。V2EX论坛上就有人吐槽过:“服务器被攻击,上了CDN但源站IP还是会被很快知道,求问可能是哪个环节出了问题?”——这就是没配置好白名单的后果。

Cloudflare回源IP列表在哪找?如何获取最新IP段

说到配置白名单,第一步就是得知道Cloudflare的回源IP列表在哪。这个其实不难找,CF官方有专门的页面。

官方IP列表地址

Cloudflare官方维护了三个地址:

完整列表:https://www.cloudflare.com/ips/
IPv4列表:https://www.cloudflare.com/ips-v4
IPv6列表:https://www.cloudflare.com/ips-v6 建议直接收藏这几个页面,以后更新维护的时候会用到。

当前最新的Cloudflare IPv4 IP段

截至目前,Cloudflare的IPv4回源IP段包括这15个CIDR(IP段用CIDR格式表示,就是一种简洁的方式表示一段连续的IP地址):

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

这15个IP段总共覆盖了大约178万个IP地址。

IPv6地址段

如果你的服务器开启了IPv6,也得把这些IPv6段加进去:

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

重要提示:Cloudflare的IP列表会不定期更新。建议每隔一两个月访问一次官方页面,确保你的白名单是最新的。不然新增的CF IP可能被你的防火墙误拦,导致回源失败。

方法一 - 宝塔面板配置Cloudflare IP白名单(最简单)

如果你用的是宝塔面板,那真是太方便了。宝塔自带的Nginx防火墙插件,点点鼠标就能配置好白名单,完全不用手写配置文件。

第一步:安装Nginx免费防火墙插件

打开宝塔面板,点击左侧菜单的软件商店,然后点第三方应用分类,找到Nginx免费防火墙。如果没安装,点安装按钮装一下,几秒钟就好。

第二步:配置IP白名单

安装好后,点击Nginx防火墙的设置按钮,进入防火墙管理界面。

点击左侧的全局配置
找到IP白名单部分,点击设置按钮
在弹出的管理IP白名单窗口,依次添加Cloudflare的IPv4地址段这里有个小技巧:宝塔要求你输入起始IP和结束IP。但我们拿到的是CIDR格式(比如173.245.48.0/20),怎么转换呢? 你可以用在线工具(搜索”CIDR转IP范围”)把CIDR转成起始和结束IP。比如173.245.48.0/20对应的范围是173.245.48.0到173.245.63.255。不过说实话,这样手工转换15个IP段挺累的。我一般是直接在网上找现成的宝塔白名单导入列表,有些博客会把转换好的IP范围列出来,复制粘贴就行。
所有IP段添加完后,点导入按钮
重启Nginx服务注意:宝塔面板目前只支持IPv4,IPv6的白名单没法通过界面配置。如果你的服务器开了IPv6,还得手工改Nginx配置文件,或者直接用方法二。

第三步:验证配置是否生效

配置完后别急着走,测试一下:

用手机4G网络(非CF流量)直接访问你的源站IP,应该看到403 Forbidden错误
通过域名访问(走CF代理),应该正常显示如果出现502错误,说明白名单配置有问题,可能是IP段不完整,或者防火墙规则没保存。检查一下宝塔防火墙是否已启用,再确认所有CF IP段都添加了。

方法二 - 纯Nginx配置白名单(更灵活)

如果你不用宝塔,或者想要更灵活的配置方式,直接改Nginx配置文件也很简单。而且这个方法支持IPv6,比宝塔更全面。

第一步:创建Cloudflare IP配置文件

SSH登录你的服务器,创建一个专门的配置文件来管理Cloudflare白名单:

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

在文件里输入以下内容:

# Cloudflare IPv4 IP段
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段
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;
# 拒绝其他所有IP
deny all;

保存文件(Ctrl+O,然后Ctrl+X退出)。 关键点:最后的deny all;非常重要,它表示除了上面allow的IP,其他所有IP都拒绝访问。这一行不能漏。

第二步:在Nginx站点配置中引入白名单

编辑你的站点配置文件。配置文件一般在/etc/nginx/sites-available/(Debian/Ubuntu)或/etc/nginx/conf.d/(CentOS)目录下。

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

在server块里添加一行:

server {
    listen 80;
    server_name example.com;
    # 引入Cloudflare白名单
    include /etc/nginx/cloudflare-whitelist.conf;
    # 下面是你的其他配置...
    root /var/www/html;
    index index.html;
}

如果你的站点同时监听443端口(HTTPS),记得在443的server块里也加上这行。

第三步:测试并重载Nginx

先测试一下配置文件语法是否正确:

sudo nginx -t

如果提示syntax is ok和test is successful,说明配置没问题。然后重载Nginx:

sudo systemctl reload nginx

搞定!这样就配置好了。 这个方法的优势是:配置文件单独管理,以后更新IP列表直接改cloudflare-whitelist.conf就行,多个站点可以共用这个文件。比宝塔更灵活,也支持IPv6。

方法三 - Cloudflare源服务器证书配置(最安全)

前面两种方法已经很安全了,但如果你对安全要求特别高,还可以加一层源服务器证书验证。这样即使源站IP泄露,攻击者直接访问也会遇到证书错误,无法连接。

什么是Cloudflare源服务器证书

简单说,CF源证书是由Cloudflare签名的TLS证书,只用于Cloudflare与你源站之间的加密。浏览器不会信任这个证书(只有CF信任),攻击者直接访问你的源站IP时,会看到证书错误警告,连接失败。结合IP白名单使用,这就是双重保护:白名单拦截非CF流量,证书验证确保只有CF能建立加密连接。

第一步:生成源服务器证书

登录Cloudflare后台,选择你的域名,进入SSL/TLS → 源服务器页面。

点击创建证书按钮
选择要保护的域名(可以用通配符,比如*.example.com)
有效期选择最长15年(反正是CF自己用的证书,选长点省事)
点击创建 CF会生成两个东西:

源证书(Origin Certificate):一串PEM格式的证书
私钥(Private Key):对应的私钥把这两个内容分别保存到服务器上,比如:

sudo nano /etc/nginx/certs/cloudflare.crt
# 粘贴源证书内容
sudo nano /etc/nginx/certs/cloudflare.key
# 粘贴私钥内容

记得设置权限,保护私钥安全:

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

第二步:Nginx配置源证书

编辑你的站点配置文件,在HTTPS的server块里配置证书:

server {
    listen 443 ssl http2;
    server_name example.com;
    # 使用Cloudflare源证书
    ssl_certificate /etc/nginx/certs/cloudflare.crt;
    ssl_certificate_key /etc/nginx/certs/cloudflare.key;
    # 引入IP白名单
    include /etc/nginx/cloudflare-whitelist.conf;
    # 其他配置...
}

如果你想要更严格的验证,还可以加上客户端证书验证(需要下载CF的客户端证书):

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

测试并重载Nginx:

sudo nginx -t && sudo systemctl reload nginx

提示:这个方法适合对安全要求极高的场景。普通站长用前面的IP白名单就够了,不用搞这么复杂。

测试配置是否生效 + 常见问题排查

配置完了别急着庆祝,测试一下才能放心。

如何测试配置

方法1:用非CF流量直接访问源站IP 用手机4G网络(或者其他非Cloudflare的网络),在浏览器里输入你的源站IP地址,比如http://123.45.67.89。如果配置正确,应该看到403 Forbidden页面。 方法2:用curl命令测试 在本地电脑(非服务器)上运行:

curl -I http://你的源站IP

返回结果应该是403 Forbidden。 方法3:通过域名访问(走CF代理) 在浏览器输入你的域名,比如https://example.com,应该能正常访问。如果这步也403了,说明配置有问题。

常见问题及解决方案

问题1:配置后网站显示502错误 可能原因:

白名单IP段不完整,漏了某些CF IP
Nginx配置文件语法错误解决方法:

运行sudo nginx -t检查语法
检查Nginx错误日志:sudo tail -f /var/log/nginx/error.log
确认所有15个IPv4段和7个IPv6段都添加了 问题2:通过CF访问也显示403 可能原因:

deny all;规则放在了allow规则之前
CF回源IP不在你的白名单中(可能CF更新了IP) 解决方法:

检查配置文件,确保allow规则在deny all;之前
访问https://www.cloudflare.com/ips/ 确认IP列表是最新的 问题3:宝塔面板导入IP段后没生效 可能原因:

防火墙插件未启用
规则未保存或Nginx未重启解决方法:

确认Nginx防火墙插件已启用(绿色图标)
在宝塔面板重启Nginx服务
检查宝塔防火墙日志,看是否有报错 问题4:IPv6访问仍然可以绕过白名单 可能原因:

只配置了IPv4白名单,忘了IPv6 解决方法:

添加CF的IPv6地址段到白名单
或者直接在防火墙禁用IPv6(如果不需要IPv6访问)

其他安全建议

配置好白名单只是第一步,还有些安全措施值得做:

修改SSH端口:默认22端口容易被扫描,改成其他高位端口
定期更新系统:及时打补丁,修复安全漏洞
隐藏Nginx版本号:在nginx.conf里加上server_tokens off;
使用CF的Under Attack模式:遇到高强度攻击时,开启五秒盾

Cloudflare IP列表更新维护

前面说过,Cloudflare的IP列表会变化,新增或调整IP段。如果不及时更新,可能导致新的CF IP被拦截,网站访问出问题。

为什么需要定期更新

Cloudflare在全球有几百个数据中心,IP段会随着基础设施扩展而调整。虽然不是天天变,但每隔几个月可能就会有更新。如果你的白名单用的是旧IP列表,CF新增的回源IP可能被你的防火墙拦在门外,导致部分地区的用户访问失败,或者回源请求被拒绝。

手动更新方法

最简单的方法是定期(比如每2-3个月)访问一次https://www.cloudflare.com/ips/,对比一下是否有新增的IP段。如果有更新:

编辑你的白名单配置文件
添加新的IP段
测试Nginx配置:sudo nginx -t
重载Nginx:sudo systemctl reload nginx

自动化更新脚本(可选)

如果你想省事,可以用个简单的bash脚本自动获取最新IP列表并更新配置。下面是一个示例脚本:

#!/bin/bash
# Cloudflare IP白名单自动更新脚本
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"
# 备份现有配置
cp $NGINX_CONF $BACKUP_CONF
# 生成新配置
echo "# Cloudflare IP Whitelist - Auto-generated on $(date)" > $NGINX_CONF
echo "" >> $NGINX_CONF
# IPv4段
echo "# IPv4 ranges" >> $NGINX_CONF
curl -s $CF_IPV4_URL | sed 's/^/allow /' | sed 's/$/;/' >> $NGINX_CONF
echo "" >> $NGINX_CONF
# IPv6段
echo "# IPv6 ranges" >> $NGINX_CONF
curl -s $CF_IPV6_URL | sed 's/^/allow /' | sed 's/$/;/' >> $NGINX_CONF
echo "" >> $NGINX_CONF
# 拒绝其他IP
echo "# Deny all other IPs" >> $NGINX_CONF
echo "deny all;" >> $NGINX_CONF
# 测试配置
if nginx -t; then
    echo "配置文件语法正确,重载Nginx..."
    systemctl reload nginx
    echo "✓ Cloudflare白名单更新成功!"
else
    echo "✗ 配置文件有错误,恢复备份..."
    cp $BACKUP_CONF $NGINX_CONF
    echo "已恢复原配置,请检查错误"
fi

保存为/root/update-cf-whitelist.sh,添加执行权限:

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

然后设置cron定时任务,每月自动执行一次:

crontab -e

添加一行:

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

这样每月1号凌晨3点会自动更新IP列表,并把日志记录到/var/log/cf-whitelist-update.log。提示:第一次用脚本前,先手工运行一次测试,确保没问题再设置定时任务。万一脚本有bug,定时执行可能把配置搞坏。

结论

说了这么多,核心就一句话:想保护好源站,配置Cloudflare白名单是必须的。 咱们回顾一下三种方法:

宝塔面板白名单:最简单,点鼠标就能搞定,适合新手。缺点是只支持IPv4。
纯Nginx配置:更灵活,支持IPv6,配置文件方便管理和更新,适合有点Linux基础的。
源服务器证书验证:最安全,双重保护,适合对安全要求极高的场景。不管选哪种,配置完后记得测试一下。手机4G直接访问源站IP,看到403就说明成功了。然后通过域名访问,确保正常。最后提醒一句:Cloudflare的IP列表会更新,记得定期检查,或者用自动化脚本省事。不要配置完就扔那不管,几个月后CF新增了IP段,你的白名单还是老的,到时候访问出问题就麻烦了。如果这篇文章帮到你了,不妨分享给其他也在用Cloudflare的站长朋友。大家都把源站保护好,攻击者就没那么容易得逞了。对了,你可以立即检查一下自己的源站IP是否已经泄露——去myssl.com之类的SSL检测网站查一下证书,看看有没有暴露源站IP。如果已经泄露了,按本文的方法赶紧配置白名单,亡羊补牢还不晚。

发布于: 2025年11月21日 · 修改于: 2025年12月4日

Easton

技术开发

Cloudflare回源IP白名单配置:3种方法彻底封锁非CF流量保护源站

为什么要限制非CF流量?源站IP泄露的真实风险

常见的IP泄露途径

泄露后的危害有多大

Cloudflare回源IP列表在哪找?如何获取最新IP段

官方IP列表地址

当前最新的Cloudflare IPv4 IP段

IPv6地址段

方法一 - 宝塔面板配置Cloudflare IP白名单(最简单)

第一步:安装Nginx免费防火墙插件

第二步:配置IP白名单

第三步:验证配置是否生效

方法二 - 纯Nginx配置白名单(更灵活)

第一步:创建Cloudflare IP配置文件

第二步:在Nginx站点配置中引入白名单

第三步:测试并重载Nginx

方法三 - Cloudflare源服务器证书配置(最安全)

什么是Cloudflare源服务器证书

第一步:生成源服务器证书

第二步:Nginx配置源证书

测试配置是否生效 + 常见问题排查

如何测试配置

常见问题及解决方案

其他安全建议

Cloudflare IP列表更新维护

为什么需要定期更新

手动更新方法

自动化更新脚本(可选)

结论

Astro Cloudflare部署完全指南：SSR配置+国内访问3倍提速

从零搭建Astro博客：1小时完成首页到部署的完整指南

Astro是什么？3分钟看懂零JS、孤岛架构和内容优先的真正含义

为什么要限制非CF流量?源站IP泄露的真实风险

常见的IP泄露途径

泄露后的危害有多大

Cloudflare回源IP列表在哪找?如何获取最新IP段

官方IP列表地址

当前最新的Cloudflare IPv4 IP段

IPv6地址段

方法一 - 宝塔面板配置Cloudflare IP白名单(最简单)

第一步:安装Nginx免费防火墙插件

第二步:配置IP白名单

第三步:验证配置是否生效

方法二 - 纯Nginx配置白名单(更灵活)

第一步:创建Cloudflare IP配置文件

第二步:在Nginx站点配置中引入白名单

第三步:测试并重载Nginx

方法三 - Cloudflare源服务器证书配置(最安全)

什么是Cloudflare源服务器证书

第一步:生成源服务器证书

第二步:Nginx配置源证书

测试配置是否生效 + 常见问题排查

如何测试配置

常见问题及解决方案

其他安全建议

Cloudflare IP列表更新维护

为什么需要定期更新

手动更新方法

自动化更新脚本(可选)

结论

相关文章

Astro Cloudflare部署完全指南：SSR配置+国内访问3倍提速

从零搭建Astro博客：1小时完成首页到部署的完整指南

Astro是什么？3分钟看懂零JS、孤岛架构和内容优先的真正含义