如何配置Cloudflare代理并正确设置源服务器防火墙规则

在网站接入Cloudflare并开启DNS代理功能后，访客查询域名时会获取到Cloudflare的IP地址，而非源服务器的真实IP，这样既能隐藏源站信息，也能让Cloudflare对请求做缓存、优化和安全防护。Cloudflare的所有代理主机名共享多个IP地址范围，这些地址构成其任播网络，全球数据中心会宣告相同IP，让访客请求自动路由到最近节点。

Cloudflare代理的流量特征

开启代理后，所有到达源服务器的流量都来自Cloudflare的共享IP，而非单个访客的真实IP。对于源服务器防火墙来说，这会出现少量来源发送大量流量的特征，如果没有提前配置允许规则，很容易触发自动拦截或速率限制，一旦误拦截Cloudflare的IP，所有访客流量都无法到达应用。

需要注意的是，Cloudflare部分产品会使用其他独立IP范围，这些地址不会和源服务器建立连接，配置防火墙时只需要关注代理服务对应的共享IP范围即可。另外Magic Transit产品和普通HTTP代理的工作逻辑不同，它是在网络层通过BGP宣告用户的IP前缀，对到达整个IP网络的流量做检查和DDoS过滤，而非代理单个域名的网络请求。

源服务器基础配置

允许Cloudflare IP地址

为了避免误拦截Cloudflare的合法流量，首先需要在源服务器的防火墙中添加Cloudflare IP允许规则。可以通过.htaccess文件或者iptables工具配置，以下是使用iptables添加规则的示例，需要将$ip替换为Cloudflare官方公布的IP范围列表中的每一个地址段，每个地址段都需要单独执行一次命令：

# 允许IPv4地址段的HTTP和HTTPS流量
iptables -I INPUT -p tcp -m multiport --dports http,https -s $ip -j ACCEPT

# 允许IPv6地址段的HTTP和HTTPS流量
ip6tables -I INPUT -p tcp -m multiport --dports http,https -s $ip -j ACCEPT

如果不确定具体配置方式，可以联系托管服务商或者网站管理员获取针对性指导。

阻止非合法流量（推荐）

如果源服务器的真实IP被泄露，比如通过历史DNS记录、邮件服务器配置暴露，攻击者可能会绕过Cloudflare直接请求源站，让Cloudflare的安全防护失效。因此建议在允许Cloudflare IP的基础上，阻止其他所有到HTTP和HTTPS端口的流量，只放行信任的合作伙伴、供应商或者应用的IP。

以下是使用iptables添加拦截规则的示例：

# 拦截所有IPv4地址的HTTP和HTTPS流量（需放在允许规则之后执行）
iptables -A INPUT -p tcp -m multiport --dports http,https -j DROP

# 拦截所有IPv6地址的HTTP和HTTPS流量（需放在允许规则之后执行）
ip6tables -A INPUT -p tcp -m multiport --dports http,https -j DROP

额外检查与防护建议

完成防火墙配置后，还需要检查外部工具避免误拦截：

• 如果网站使用了安全插件，比如WordPress的相关安全插件，需要确认插件规则中已经允许Cloudflare的所有IP范围。
• 确保ModSecurity插件处于最新版本，避免旧版本规则误判Cloudflare流量。

如果需要更全面的源站防护方案，可以参考Cloudflare官方的源服务器保护指南，做进一步的安全配置。

企业用户自定义IP选项

企业版用户如果不想使用Cloudflare的共享代理IP，有两个可选方案：

• 自备IP（BYOIP）：将自己租赁或拥有的IP地址范围提交给Cloudflare，Cloudflare会在所有节点宣告这些IP，供你的域名使用。
• 静态IP地址：由Cloudflare为你的域名分配专属的静态IP地址，具体可以联系账户团队咨询详情。

商业和企业版用户还可以上传自定义SSL证书，减少自己的域名和其他Cloudflare客户共享的IP数量，进一步降低IP关联风险。

IP范围更新说明

Cloudflare的IP范围变更频率很低，当有调整时，会先更新到官方IP范围列表，再正式投入生产环境。如果需要自动同步最新的IP范围，可以调用Cloudflare API编程更新防火墙配置，避免手动维护的遗漏。

AWS VPC环境路由冲突处理

Cloudflare使用172.64.0.0/13（172.64.0.0–172.71.255.255）作为公共出口IP空间，这个范围不属于RFC 1918定义的私有地址空间，RFC 1918的172.16.0.0/12范围是172.16.0.0–172.31.255.255，二者没有重叠。

部分AWS VPC的路由表可能配置了覆盖172.16.0.0/12甚至更宽泛的172.16.0.0/8的路由，指向Transit Gateway、VPN连接等内部目标而非互联网网关，这种情况下Cloudflare 172.64.x.x的流量会被提前捕获，无法到达互联网网关，导致出现521、522等连接错误。

解决该问题的方法有三种：

• 检查AWS VPC路由表，确认是否有覆盖172.x.x.x范围且指向内部目标的路由。
• 添加一条更具体的172.64.0.0/13路由，目标指向互联网网关，更具体的路由在AWS路由规则中优先级更高。
• 将原有的宽泛路由精确调整为172.16.0.0/12（RFC 1918范围），排除172.64.0.0/13的范围。

注意这个问题不会在安全组审计中体现，因为安全组是在实例级别生效，而路由冲突是出现在路由层的问题。

Cloudflare代理源服务器防火墙iptables规则IP地址允许列表AWS_VPC路由修改时间：2026-06-06 05:15:21