当您将域名添加到 Cloudflare 并代理其 DNS 记录时，查询您域名的访问者会收到 Cloudflare IP 地址，而不是源站服务器的真实 IP 地址。这可以隐藏源站 IP 地址，并允许 Cloudflare 在转发请求之前优化、缓存并保护所有请求。
Cloudflare 拥有多个 IP 地址范围 ↗，所有已代理主机名共享这些范围。这些 IP 地址共同构成 Cloudflare 的 anycast 网络骨干——一种路由方法，同一 IP 地址从全球数据中心宣告，因此每个访问者的请求都会路由到附近的数据中心。
所有发往 已代理 DNS 记录 的流量在到达源站服务器之前都会经过 Cloudflare。这意味着源站服务器将不再接收来自各个访问者 IP 地址的流量，而是接收来自 Cloudflare IP 地址 ↗ 的流量，这些地址由所有已代理主机名共享。
对源站服务器防火墙而言，这可能看起来像是少数来源发送大量流量——可能触发自动阻止或 rate limiting。由于所有访问者流量似乎来自 Cloudflare IP 地址，阻止这些 IP（即使是意外阻止）也会阻止访问者流量到达您的应用。
上述指导适用于使用 Cloudflare HTTP 代理的域名。Magic Transit 的工作方式不同——它不是代理 Web 请求，而是在网络层保护整个 IP 网络。Cloudflare 通过 BGP 宣告您的 IP 地址范围（前缀），因此发往您网络的所有流量在转发到基础设施之前都会经过 Cloudflare 进行检查和 DDoS 过滤。
为避免意外阻止 Cloudflare IP 地址，您还应在源站 Web 服务器上允许 Cloudflare IP 地址。
您可以使用 .htaccess 文件 ↗ 或 iptables ↗ 显式允许这些 IP 地址。
以下示例演示如何使用 iptables 规则允许 Cloudflare IP 地址范围。将下面的 $ip 替换为 Cloudflare IP 地址范围 ↗ 之一。您需要对该页面上列出的每个 IP 范围运行一次此命令。
# For IPv4 addresses
iptables -I INPUT -p tcp -m multiport --dports http,https -s $ip -j ACCEPT
# For IPv6 addresses
ip6tables -I INPUT -p tcp -m multiport --dports http,https -s $ip -j ACCEPT如需更具体的指导，请联系您的托管提供商或网站管理员。
如果有人发现您的源站 IP 地址（例如通过历史 DNS 记录或邮件服务器配置），他们可以直接向您的服务器发送流量，完全绕过 Cloudflare 的安全保护。为防止这种情况，请阻止所有不来自 Cloudflare IP 地址或您信任的合作伙伴、供应商或应用 IP 地址的流量。
例如，您可以使用以下命令更新 iptables ↗：
# For IPv4 addresses
iptables -A INPUT -p tcp -m multiport --dports http,https -j DROP
# For IPv6 addresses
ip6tables -A INPUT -p tcp -m multiport --dports http,https -j DROP如需更具体的指导，请联系您的托管提供商或网站管理员。
为避免意外阻止 Cloudflare IP 地址，请检查外部工具，确认：
- 任何安全插件（例如 WordPress 插件）允许 Cloudflare IP 地址。
- ModSecurity ↗ 插件已更新。
有关保护源站服务器的更多建议，请参阅我们的保护源站服务器指南。
不想使用 Cloudflare IP 地址（所有已代理主机名共享）的 Enterprise 客户有两个潜在替代方案：
- Bring Your Own IP (BYOIP)：Cloudflare 在所有位置 ↗宣告您的 IP（您租用/拥有的 IP 地址范围）。
- Static IP addresses（静态 IP 地址）：Cloudflare 为您的域名设置静态 IP 地址。有关更多详情，请联系您的账户团队。
Business 和 Enterprise 客户还可以通过上传自定义 SSL 证书减少域名与其他 Cloudflare 客户域名共享的 Cloudflare IP 数量。
Cloudflare 的 IP 范围不会频繁更改。更改时，会在投入生产之前添加到我们的 IP 范围列表 ↗。您也可以使用 Cloudflare API 以编程方式保持配置更新。
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），与 172.64.0.0/13 不重叠。
AWS VPC 路由表有时包含覆盖 172.16.0.0/12（或更广泛的超网如 172.16.0.0/8）的路由，用于 Transit Gateway 或 VPN 连接。如果此路由指向内部目标而非 Internet Gateway，它可能在流量到达 Internet Gateway 之前捕获 Cloudflare 的 172.64.x.x 流量，导致使用此范围的 Cloudflare 数据中心出现连接错误（521、522）。
解决方法：
- 检查 AWS VPC 路由表是否有覆盖
172.x.x.x范围且路由到内部目标（Transit Gateway、VPN Gateway、NAT Gateway 或 VPC 对等连接）的路由。 - 添加更具体的路由，目标为
172.64.0.0/13，指向 Internet Gateway。更具体的路由在 AWS 路由中优先。 - 或者，将广泛路由缩小为精确的
172.16.0.0/12（RFC 1918 范围），不包含 172.64.0.0/13。
此问题不会出现在安全组审计中，因为安全组在实例级别评估，而非路由层。