CDN IP地址范围全解析：从查询到白名单的实战指南
当你要在源站防火墙里放行 CDN、要从访问日志里分辨真实访客、或者只是怀疑某个 IP 到底是不是 CDN 节点时，「cdn ip地址范围」这个问题就会浮上来。它看起来像一个可以直接抄下来的清单，实际上更像一份随时会变的动态地图：一份 IP 段清单只代表某个时刻的快照，而 CDN 的网络每天都在扩容、调整和下线。
一、CDN 的 IP 为什么总是以「范围」出现
CDN 的基本思路是把内容放到离用户更近的地方。一个成熟的 CDN 服务商会在不同地区、不同运营商部署大量边缘节点，每个节点持有若干公网地址，汇总起来就是成百上千个网段。它不像一台普通服务器那样只有一个出口 IP，而是以地址块的形态存在，用 CIDR 表示，例如 203.0.113.0/24 这样一段。
任播让同一个 IP 出现在多个地方
很多 CDN 使用任播（Anycast）技术：同一段 IP 前缀通过 BGP 在多个机房同时对外宣告，用户的路由协议会把请求送到网络意义上「最近」的那个点。所以你在不同城市去 ping 同一个 CDN 的 IP，延迟差别可能很大，但 IP 确实是同一个。这直接打破了「一个 IP 对应一台机器、一个机房」的直觉，也让「这个 IP 属于哪个节点」这类问题失去了标准答案。
扩容、调度与线路调整都会改变地址集合
新节点上线、老旧机房退役、运营商互联质量变化、调度策略调整，都会让某些网段被加入或撤出。因此任何一份 cdn ip地址范围清单都带有保质期，把它当成永久配置写死在防火墙里，往往是后续故障的起点。
IPv4 与 IPv6 是两套并行的地址
同一个加速域名通常同时返回 A 记录和 AAAA 记录。IPv6 的网段是单独的一套，需要单独放行。很多「部分用户访问不了」的事故，追到最后就是白名单只配了 IPv4。
二、CDN IP 地址范围通常长什么样
以 CIDR 为基本单位
边缘节点的地址一般以 /22、/24 这类粒度对外发布。粒度越大，聚合越简洁，但把不属于 CDN 的地址一并包进来的风险也越高；粒度越小越精确，维护成本却随之上升。实际使用时应当优先采用厂商标注的小粒度段。
单播段与任播段并存
一部分网段用于常规的边缘接入服务，另一部分是任播段。做源站白名单时，两类都要覆盖，只放行其中一类，会出现部分地区的回源请求被拦截的情况。
与其他云服务共用地址池
有些厂商的边缘网络会与 WAF、大流量转发、对象存储等业务共用出口地址或相邻网段。这意味着你在日志里看到的「CDN IP」，未必只承载 CDN 流量，反过来，你放行的某个大段里也可能混着别的业务。
公开清单与私有清单
头部厂商大多提供公开的、机器可读的地址清单，而不少商业 CDN 只对签约客户提供回源段，甚至按账号定制。这种差异决定了你查 cdn ip地址范围时，方法要因厂商而异。
三、如何查到一个 CDN 的 IP 地址范围
官方公开清单是首选
能拿到官方清单就不要自己猜。比较典型的有 Cloudflare 的官方 IP 段页面，以及 AWS 的 ip-ranges.json（其中按 service 字段区分了 CloudFront 的网段），Google 也提供 goog.json 这样的机器可读清单。这类数据会持续更新，适合写脚本定时拉取，而不是人工复制粘贴。
DNS 解析加多地探测
把目标域名放到多个地区、多个运营商环境下解析，收集返回的 A 与 AAAA 记录，可以拿到边缘入口 IP。这种方法的好处是直观，缺点是只能覆盖被解析到的那一小部分地址，拿不到完整的网段，也无法反映尚未被调度到的节点。
用 BGP 与 WHOIS 反查归属
把探测到的 IP 拿去查 ASN 与路由宣告，往往能顺着前缀找到整段被宣告的地址块，再结合厂商信息确认其中哪些属于该 CDN。公开的 BGP 数据服务（如 RIPEstat、bgp.he.net 一类工具）可以完成这一步，对没有公开清单的厂商尤其有用。
从响应头与证书反推
HTTP 响应里的 Via、X-Cache、Server-Timing、CF-Ray 之类的字段，以及 TLS 证书中包含的组织信息，都能作为佐证，帮你判断某个 IP 是否出自某家 CDN。这类信息适合做交叉验证，而不是当作唯一依据。
四、拿到地址范围之后能做什么
源站放行：只允许 CDN 回源
这是最经典的用法。源站的安全组或防火墙只放行 CDN 的回源网段，其余来源一律拒绝，再配合回源鉴权头、共享密钥或双向 TLS，就能有效防止攻击者绕过 CDN 直连源站、绕过 WAF 与限流。
日志还原真实客户端 IP
访问日志里的 remote_addr 往往记录的是 CDN 节点地址。要还原真实访客，应读取 X-Forwarded-For 或厂商专用头，如 CF-Connecting-IP、True-Client-IP、X-Real-IP。关键在于：只有请求确实来自 CDN 网段时，才信任这些头。否则任何人都能随手伪造一个头部，把自己的身份伪装成任意 IP。
判断一个站点是否使用 CDN
解析出的 IP 是否落在已知 CDN 的地址段里，是判断对方是否启用加速的粗略依据。做性能对比、排查链路问题时，这个判断能帮你快速定位问题出在源站还是分发层。
灰度观测与故障定位
把某个网段临时加入观测名单或单独限流，可以在 CDN 侧调整线路、切换机房时，快速判断是哪一片节点出了问题，而不是笼统地认为「CDN 挂了」。
五、使用时容易踩的坑
清单一配就不再更新
最危险的不是配错，而是配完不管。厂商新增网段没有同步，新节点回源被源站拦掉，表现为部分用户 502 或超时，而且往往只在特定地区、特定运营商下复现，排查成本极高。
段内并不全是 CDN
大段宣告里可能混入其他业务，无条件放行整个 /16 等于把门开得过大。尽量使用厂商提供的小粒度段，并对放行范围做定期复核。
把「来自 CDN 段」等同于「可信用户」
放行只是网络层可达，不代表流量无害。CDN 节点会把大量真实客户端流量带进来，攻击者同样可以购买 CDN 服务发起攻击。因此限流、WAF、鉴权、验证码一个都不能省。
忽略 IPv6 与私有清单
IPv6 用户被拒绝、回源段与边缘段混用，是两类高频错误。边缘接入 IP 段和回源出口 IP 段常常不是同一批地址，做白名单时应当使用厂商明确标注为「回源」的那份清单，而不是随手拿解析结果凑。
六、更稳妥的工程做法
IP 清单是必要条件，但不是全部。把 cdn ip地址范围管理好，可以从几件事入手：一是自动化同步，定时拉取官方 JSON，做差异对比并在变化时告警，配置由代码管理而非手工点选；二是双重校验，除了判断来源是否在段内，还对转发头做签名或密钥校验；三是兜底策略，更新失败时保留上一版配置并在监控中告警，而不是让回源直接断掉；四是留痕，谁在什么时候改了白名单、为什么改，都要可追溯。
说到底，cdn ip地址范围不是一份可以一次性抄完的清单，而是一份需要持续维护的基础设施数据。把它当作配置代码来对待，配合自动同步、交叉验证与最小放行原则，源站的安全性和可用性才能同时得到保障。
