将业务域名接入Cloudflare之后，所有公开访问流量理论上都应先经过Cloudflare边缘节点，再由节点回源到我们的Nginx服务器。但在实际环境中，只要源站服务器的公网IP和端口对外可达，攻击者就能通过扫描或历史解析记录找到真实地址，直接对Nginx发起HTTP请求，这就是所谓的“恶意直连”。这类请求不仅绕过了CDN的缓存、WAF和限速能力，还会暴露源站IP，带来被DDoS或拖库的风险。因此，在Nginx上配置回源IP白名单，只允许Cloudflare公布的网络段访问，是运维中非常关键的一道防线。
为什么必须限制回源IP
很多站长认为只要开了Cloudflare的代理模式（橙色云图标），源站就安全了，其实这是一个常见误解。Cloudflare只是把域名对外解析到自己的IP，并不会主动封闭你源站本身的入站连接。如果服务器安全组或Nginx没有做限制，任何知道IP的人都能直接请求。此时Cloudflare的防护完全失效，攻击者甚至可以伪造任意请求头。
从运维角度看，限制回源IP还能显著降低源站负载。CDN本来就该承担静态资源分发和恶意流量清洗，若大量异常请求直达源站，数据库和后端服务很容易被打满。通过白名单机制，我们可以在传输层或应用层提前丢弃非法数据包，把计算资源留给真实用户。
获取Cloudflare官方IP段
Cloudflare会维护一份公开的IPv4和IPv6地址列表，用于标识其边缘节点。官方文档中给出了两个固定地址：IPv4列表为 www.cloudflare.com/ips-v4，IPv6列表为 www.cloudflare.com/ips-v6。这两个文本文件每行一个CIDR段，格式清晰，适合脚本定期拉取。
由于Cloudflare可能根据业务扩张新增或调整网段，建议写一个简单的定时任务，例如每周用curl拉取一次并重新生成Nginx配置片段。这样能避免因为地址段过期导致正常回源被误拦。下面是一段常见的Shell思路：先下载文件，再用awk转成allow指令，最后覆盖到conf.d目录下的cloudflare_ips.conf。
配置片段示例结构
我们可以将下载到的IP段转换为如下形式的Nginx指令集合，方便在主配置中引用：
- allow 173.245.48.0/20;
- allow 103.21.244.0/22;
- allow 2400:cb00::/32;
- deny all;
注意，deny all应当放在所有allow之后，表示除白名单外全部拒绝。若放在前面，后面的allow将不会生效。这也是新手最容易配置出错的地方。
Nginx中的具体配置方式
在Nginx里限制回源IP，通常有两种做法。一种是在server块中直接使用allow和deny指令，另一种是通过geo模块配合变量做更灵活的控制。对于大多数中小型站点，直接在监听80和443的server内写入include cloudflare_ips.conf即可。
示例配置如下：在server上下文中先include白名单文件，再对location /做限制。如果某些管理后台需要临时从办公网络访问，可以在对应location中单独allow特定IP，再deny all。但要小心作用域覆盖问题，Nginx的allow和deny是按出现顺序匹配的。
| 配置位置 | 适用场景 | 维护难度 |
|---|---|---|
| server块内include | 整站仅允许CDN回源 | 低 |
| location级allow | 部分路径开放直连 | 中 |
| geo+map变量 | 多条件动态判定 | 高 |
真实访客IP的传递
限制回源后，Nginx看到的连接都来自Cloudflare节点，若不做处理，access日志里全是CDN的IP，不利于分析和限流。Cloudflare会在回源请求头中携带CF-Connecting-IP，我们可以在Nginx用real_ip模块将其还原为访客真实地址。
具体做法是在http或server块设置：set_real_ip_from指定CDN段，real_ip_header设为CF-Connecting-IP。这样后端应用拿到的REMOTE_ADDR就是用户真实IP，既不影响白名单判断，也方便后续做防盗刷策略。
防火墙与安全组配合
Nginx层的deny属于应用层拦截，数据包已经到达服务器。更彻底的方案是在云厂商安全组或iptables中只放行Cloudflare段，彻底屏蔽其他入站。这样即使Nginx配置失误，源站也不会被直连。
例如在iptables中，可先接受来自Cloudflare IPv4段的NEW连接，再在INPUT链默认DROP。不过这种方式对IPv6和频繁变更的列表管理要求较高，一般建议安全组做粗粒度限制，Nginx做细粒度校验，两者互补。
常见故障与排查
配置完后若全站无法访问，大概率是白名单把Cloudflare自身也挡掉了。此时应检查include路径是否正确、CIDR是否完整，以及deny all是否误写到allow之前。可通过在源站执行tcpdump看请求来自哪个IP来定位。
另一个常见问题是本地curl源站测试时返回403，这其实是预期行为，因为你的测试机不在白名单内。如需本地调试，可临时在server中加一句allow你的出口IP并reload，调试完记得删掉，避免留下直连口子。
回源白名单不是一次性工作，而应随Cloudflare地址段更新和服务器迁移持续维护。把它纳入自动化脚本，才能长期保持源站隐蔽性。
总结实践步骤
归纳起来，完整流程是：从官网获取IP段，生成Nginx白名单配置，主配置中include并deny all，开启real_ip还原访客IP，配合安全组收缩端口，最后用Cloudflare代理访问验证、用非白名单IP直连验证被拒。照此执行，就能用很低成本堵住恶意直连隐患。
NginxCloudflare回源IP白名单修改时间：2026-08-11 13:09:39