怎么查询竞品网站使用的CDN和节点分布？完整调查方法

准备给网站更换CDN时，很多团队会先研究同行：

• 竞品用了哪家CDN？

• 国内和海外是不是同一家？

• 图片、API和下载业务有没有分开部署？

• 用户访问时进入了哪些节点？

• 同一家CDN为什么不同地区速度差别很大？

• 能不能根据竞品方案直接选择同一家厂商？

这些问题都可以从公开网络信息中获得一部分答案，但不能只查询一次DNS，就把某个IP对应的城市写成“竞品CDN节点分布”。

现代网站可能同时使用多CDN、Anycast、智能DNS、云负载均衡、WAF和自建边缘节点。一个IP也可能从世界各地的多个机房同时宣告。

因此，竞品CDN调查应该分成两个问题：

1. 识别竞品可能使用的CDN厂商；

2. 观察目标域名在不同地区实际进入了哪些公开入口。

第一个问题可以通过CNAME、IP、ASN、响应头和TLS证据判断；第二个问题必须依靠多地区、不同运营商和不同时间的重复观测。

先记住一个边界：

外部调查可以较可靠地识别“当前观察到的CDN入口和厂商证据”，但通常无法还原竞品的完整节点拓扑、合同资源、节点容量和真实源站架构。

查询前先确定研究目标

如果只是想知道“这个网站用了哪家CDN”，检查主域名可能就够了。

但如果目的是做竞品基础设施分析，至少应该回答以下问题：

调查目的不同，需要测试的对象也不同。

如果只检测首页域名，可能得到“竞品使用Cloudflare”；但进一步查看页面资源后，可能发现图片使用CloudFront、视频使用专业媒体CDN、API又通过另一家WAF服务。

第一步：不要只查地址栏里的主域名

竞品CDN调查最容易出现的错误，是只查询：

www.example.com

一个真实网站通常还包含：

example.com
www.example.com
static.example.com
img.example.com
api.example.com
download.example.com
video.example.com
assets.example.com

这些域名可能使用完全不同的基础设施。

怎么收集业务域名

使用浏览器打开竞品网站，按F12进入开发者工具，再查看Network面板中的请求域名。

可以按照资源类型整理：

调查时要把“竞品自有域名”和“第三方公共服务”区分开。

页面加载了Google Analytics，并不意味着竞品选择Google作为网站CDN；调用第三方支付接口，也不代表该支付域名属于竞品基础设施。

记录最终跳转地址

裸域可能只负责跳转，真正的网站位于www或其他域名。

可以执行：

curl -sS -L -o /dev/null \
  -w 'final_url=%{url_effective}\nremote_ip=%{remote_ip}\nstatus=%{http_code}\n' \
  https://example.com/

重点记录：

• 最终URL；

• 最终主机名；

• HTTP状态码；

• 实际连接IP；

• 是否发生跨域跳转。

不要把跳转前域名和跳转后域名的CDN结果混为一谈。

第二步：查询CNAME、A和AAAA记录

对每个重点业务域名，分别查询：

dig www.example.com CNAME +noall +answer
dig www.example.com A +noall +answer
dig www.example.com AAAA +noall +answer

CNAME能告诉你什么

许多CDN会要求客户把业务域名指向厂商调度域名，例如：

static.example.com → customer.cdn-provider.example

如果CNAME后缀属于公开且稳定的CDN厂商，它通常是一条比较强的识别证据。

但不能只依靠CNAME，因为以下情况可能看不到明显厂商名称：

• CNAME被展平；

• 根域使用ALIAS或ANAME；

• CDN直接返回Anycast地址；

• 企业使用自定义调度域名；

• 白标CDN隐藏上游品牌；

• 多CDN前面还有独立流量调度平台；

• 厂商调度域名采用中性化命名。

所以“没有CNAME”不等于“没有使用CDN”。

A和AAAA需要分开记录

一些网站在IPv4和IPv6上使用不同架构：

IPv4 → CDN A
IPv6 → CDN B或源站

也可能IPv4已经迁移到新CDN，而IPv6仍然保留旧配置。

只查询A记录会漏掉IPv6路径，只查询AAAA记录也无法代表大部分IPv4用户。

第三步：查询IP和ASN，但不要直接等同于CDN品牌

拿到响应IP后，可以继续查询：

• IP注册机构；

• 所在网段；

• ASN；

• 网络组织名称；

• 反向DNS；

• 是否属于云平台或CDN厂商。

RDAP是查询IP地址、ASN及相关互联网资源注册信息的标准方式。ARIN的RDAP说明指出，RDAP可以用于查询IP和ASN的注册数据，并以JSON形式返回结果。

但IP注册信息和实际CDN品牌不是完全相同的概念。

例如，一个IP可能属于：

• CDN厂商自有网络；

• 公有云平台；

• 合作机房；

• 运营商网络；

• 企业自有ASN；

• 上游白标CDN；

• BYOIP客户地址；

• 多家服务共享的边缘平台。

因此，下面这种结论并不严谨：

IP属于AWS，所以网站使用CloudFront。

该网站也可能只是把服务器部署在AWS EC2、使用ALB，或者由另一家厂商租用AWS资源提供服务。

更合理的说法是：

当前响应IP注册于AWS网络；是否使用CloudFront，还需要结合CNAME、响应头和多地区结果判断。

第四步：查看HTTP响应头

执行：

curl -sS -D - -o /dev/null https://www.example.com/

重点观察：

Server
Via
Age
X-Cache
X-Cache-Status
CF-Cache-Status
CF-Ray
X-Amz-Cf-Pop
X-Amz-Cf-Id
CDN-Cache-Status
Server-Timing

不同CDN可能添加自己的请求标识、缓存状态或节点代码。

哪些响应头证据比较强

例如Cloudflare官方文档说明，CF-Ray响应头包含处理请求的数据中心信息，并以三字母代码表示。但在使用Argo Smart Routing或分层缓存时，这个代码也可能表示连接源站的数据中心，而不是用户最初进入的入口。

所以即使厂商公开了PoP代码，也必须先弄清字段描述的是：

• 用户接入节点；

• 上层缓存节点；

• 回源节点；

• 请求最终处理位置。

为什么响应头有时看不到厂商

可能原因包括：

• 竞品主动删除品牌字段；

• CDN允许自定义响应头；

• 最外层WAF覆盖了上游字段；

• 网站使用白标CDN；

• 当前请求返回源站错误页；

• 请求被Bot规则拦截；

• 多层CDN只显示最外层或内层的一部分信息。

因此，响应头是证据之一，不是唯一答案。

第五步：检查TLS证书，但不要把签发机构当成CDN

可以查看证书：

openssl s_client \
  -connect www.example.com:443 \
  -servername www.example.com \
  </dev/null 2>/dev/null |
openssl x509 -noout -subject -issuer -ext subjectAltName

记录：

• 证书覆盖域名；

• 签发机构；

• 有效期；

• 是否为通配符证书；

• 是否包含其他业务域名；

• 不同地区看到的证书是否一致。

TLS证书可以帮助发现：

• 多个业务域名是否共用入口；

• 不同节点的证书是否同步；

• 是否存在CDN托管证书特征；

• 某个地区是否接入了错误节点；

• IPv4和IPv6是否返回不同证书。

但证书签发机构不能直接代表CDN厂商。

看到Let’s Encrypt、DigiCert或Sectigo，只能说明证书由相应机构签发，不能据此判断网站使用哪家CDN。

第六步：必须从多个地区和运营商重复查询

在本地执行一次dig或curl，只能回答：

当前时间，我所在网络看到了什么。

它不能回答：

• 中国大陆用户走哪家CDN；

• 海外用户是否使用另一家CDN；

• 电信、联通、移动是否命中相同入口；

• IPv4与IPv6是否一致；

• 故障切换后会不会换厂商；

• 晚高峰是否调整节点；

• 竞品是否使用加权多CDN。

使用CDNChart CDN检测时，可以先查看不同地区观察到的：

• CNAME；

• A和AAAA记录；

• 响应IP；

• ASN；

• HTTP响应头；

• 候选CDN厂商；

• 识别证据和置信度。

再通过CDNChart网站测速记录：

• 探测地区；

• 运营商；

• 解析IP；

• 状态码；

• DNS时间；

• 连接时间；

• TLS时间；

• TTFB；

• 下载时间；

• HTTP协议版本。

节点至少应该根据竞品的真实市场覆盖来选。例如竞品主要服务中国大陆和东南亚用户，那么只从美国云服务器查询，没有多少参考价值。

第七步：怎么估算竞品的CDN节点分布

这里要先区分三个概念。

1. CDN厂商公开的全球节点

这是厂商对外公布的整体网络覆盖，表示这家CDN可能拥有或使用哪些节点。

它不能证明竞品购买的具体产品一定开放全部节点，也不能证明竞品在每个地区都能获得相同服务质量。

2. IP数据库标注的地址

IP地理数据库可能把地址标记到某个国家、城市或运营商。

这类结果适合做辅助参考，但不能直接当成物理机房地址。MaxMind的官方说明也指出，IP地理定位不能精确到具体住户、个人或街道，而且不少IP只能定位到较大区域。

对于CDN和Anycast地址，城市级归属尤其容易产生误导。

3. 实际观察到的服务入口

这是最有价值的数据：从某个地区、某家运营商访问竞品域名时，实际得到哪个IP、ASN、节点代码和网络时延。

一条完整记录可以写成：

这里描述的是“从该位置观察到的入口”，不是声明物理服务器一定就在对应城市。

为什么不能用“不同IP数量”计算节点数量

假设20个地区最终得到5个不同IP，不能直接写成竞品只有5个CDN节点。

原因包括：

• 一个IP可能由多个Anycast节点共同宣告；

• 多个IP可能属于同一机房；

• DNS可能返回地址池而非物理节点；

• CDN可能根据负载轮换IP；

• 不同运营商可能通过同一个IP进入不同地点；

• IPv4和IPv6可能对应相同边缘集群；

• 同一节点可能有多个服务地址。

Cloudflare官方说明，其Anycast网络会从世界各地的数据中心同时宣告相同IP，使不同访客被路由到附近的数据中心。

因此：

唯一IP数量 ≠ 节点数量

反过来：

所有地区得到同一个IP ≠ 所有用户进入同一个机房

节点地理位置也不一定等于最近城市

CDN调度通常追求网络质量，而不是单纯的地理距离。

Amazon CloudFront官方文档说明，DNS会把用户请求路由到更适合服务该请求的PoP，通常是网络延迟更低的边缘位置。

一个广州用户可能因为运营商互联、节点容量或故障调度进入香港、深圳之外的其他节点；地图上更近的城市，也未必拥有更低的网络延迟。

Cloudflare也说明，Anycast请求不一定进入地理距离最近的数据中心，网络可靠性、拥塞和流量工程都会影响最终路径。

所以竞品节点分析应该同时记录：

• 探测位置；

• 运营商；

• PoP代码；

• 网络时延；

• TTFB；

• 响应IP；

• 时间；

• HTTP状态码。

只根据IP地理库画一张节点地图，容易产生过度确定的结论。

怎么判断竞品是不是用了多CDN

可以关注以下几种结果。

情况一：同一域名在不同地区稳定识别为不同厂商

例如：

如果多次查询结果保持一致，竞品可能按照地区或线路使用多CDN。

情况二：不同业务域名使用不同厂商

例如：

www.example.com       → CDN A
static.example.com    → CDN B
video.example.com     → CDN C
api.example.com       → WAF或动态加速D

这说明竞品按业务拆分了基础设施，但不能写成“主域名同时使用四家CDN”。

情况三：响应IP属于一家，响应头出现另一家

可能原因包括：

• CDN叠加；

• 最外层WAF加内层CDN；

• 白标服务；

• 上游残留响应头；

• 识别规则误判。

此时通常优先把实际连接IP对应的网络视为外层入口，再调查另一家厂商的证据是否长期、稳定、跨地区重复出现。

情况四：昨天和今天识别结果不同

可能是：

• CDN迁移；

• 灰度切换；

• 主备故障切换；

• DNS缓存；

• 动态流量调度；

• 检测条件不同。

只有两家CDN在同一时间窗口、不同地区或不同权重下持续出现，才更像并行使用。更完整的判断方法可以参考一个网站能用多个CDN吗？多家检测结果怎么看。

一套可以直接执行的查询流程

第1轮：整理业务域名

从浏览器Network面板整理：

主页面域名
静态资源域名
图片域名
API域名
下载域名
视频域名
WebSocket域名

第2轮：采集DNS证据

dig HOSTNAME CNAME +noall +answer
dig HOSTNAME A +noall +answer
dig HOSTNAME AAAA +noall +answer

对每个重要主机名分别执行。

第3轮：采集HTTP与连接信息

curl -sS -D - -o /dev/null \
  -w 'remote_ip=%{remote_ip}\nhttp_version=%{http_version}\nstatus=%{http_code}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\n' \
  https://HOSTNAME/

记录响应头，不要只保存最终厂商名称。

第4轮：查询IP网络信息

使用RDAP、RIR或可信ASN数据源记录：

• IP网段；

• ASN；

• 网络组织；

• 注册地区；

• 数据查询时间。

注意把“网络注册主体”和“最终CDN品牌”分开。

第5轮：进行多地区测试

从核心市场的不同运营商发起相同请求，并保持：

• URL一致；

• 请求方法一致；

• 测试时间接近；

• IPv4和IPv6分开；

• HTTP协议有记录；

• 缓存状态有记录；

• 重试次数一致。

第6轮：连续观察

快速调查可以先完成一次横向检查，但要判断多CDN和节点稳定性，应继续覆盖：

• 工作日；

• 周末；

• 白天；

• 晚高峰；

• 多个连续时间点；

• 可能的促销或高流量时段。

不要把一次故障切换结果误认为竞品的长期架构。

竞品CDN调查报告应该怎么写

可以采用下面的结构。

一、调查范围

调查对象：
调查日期：
观测地区：
运营商：
业务域名：
测试URL：
IPv4/IPv6：

二、CDN识别结果

三、节点观测结果

四、结论边界

报告中建议明确写出：

• 节点城市属于响应头、网络路径或IP数据库推测；

• 唯一IP数量不能代表物理节点数量；

• 调查只覆盖指定时间、地区和URL；

• 未观察到的CDN不代表一定不存在；

• CDN厂商可能清理或自定义公开指纹；

• 无法从公开检测确认合同容量和防护规格；

• 结果不涉及源站探测或访问控制绕过。

这样的报告虽然没有一句“百分之百确定”，但比用单个IP画出一张看似精确的全球节点图更可信。

查询竞品CDN时最常见的误区

误区一：一个CNAME就能确定整个网站的CDN

CNAME只能说明当前主机名的DNS关系。图片、API、视频和下载域名可能由不同厂商承载。

误区二：IP属于某云厂商，就等于使用它的CDN

云平台IP可能用于虚拟机、负载均衡、对象存储、托管服务或第三方产品，需要更多证据支持。

误区三：IP定位显示上海，节点就一定在上海

IP地理数据库是估算数据。Anycast、运营商注册信息和代理网络都可能让定位结果与实际服务位置不同。

误区四：不同地区返回同一个IP，所以没有节点调度

Anycast可以让多个地区的节点同时宣告相同IP。不同用户即使连接同一地址，也可能进入不同机房。

误区五：查询到10个IP，就等于竞品有10个节点

IP数量、主机数量、边缘集群数量和物理PoP数量不是同一个概念。

误区六：竞品用了某家CDN，我们也应该选它

同一家CDN对不同客户的表现可能受套餐、节点范围、流量规模、配置、缓存策略和商务资源影响。竞品方案可以作为候选线索，不能代替自己的真实测试。

哪些行为不属于正常竞品调查

公开的DNS、HTTP响应头、TLS证书和常规低频访问可以用于基础设施研究，但不应进一步进行：

• 未授权端口扫描；

• 高频请求或压力测试；

• 尝试绕过WAF；

• 探测或验证竞品源站；

• 利用错误配置访问非公开服务；

• 破解管理后台；

• 获取不属于公开响应的数据；

• 影响网站可用性的测试。

竞品CDN分析的目标应该是理解公开交付路径，而不是绕过对方的安全边界。

最终应该相信什么结果

竞品CDN调查中，证据可信度可以大致这样排序：

CDNChart CDN检测适合把CNAME、响应IP、ASN和HTTP响应头放在同一个结果中查看；节点覆盖则需要继续结合多地区网站测速。具体节点查询方法还可以参考CDN节点怎么查？查看域名节点IP和地区的方法。

最有价值的竞品结论通常不是：

竞品有37个节点。

而是：

竞品主站在中国大陆和东南亚观察到不同CDN入口；
静态资源与API采用不同厂商；
核心地区的响应IP、PoP代码和TTFB较稳定；
海外路径疑似使用Anycast，无法按唯一IP推算物理节点数量。

这种表达既保留了调查价值，也没有把有限的公开观测包装成完整内部架构。

常见问题

1. 输入域名就能准确查出竞品用了哪家CDN吗？

有时可以，但不能保证。明显的CNAME、专属IP和响应头可以提供高置信度结果；白标CDN、自建节点、CNAME展平和多层代理可能导致结果不明确。

2. 怎么判断查询到的IP是CDN节点还是源站？

结合CNAME、ASN、响应头和多地区结果判断。不同地区出现不同边缘地址，且具有厂商缓存或节点特征时，更像CDN入口。不要仅凭一个IP下结论。

3. 能否根据IP数量计算竞品有多少CDN节点？

不能。一个Anycast IP可以对应多个节点，多个IP也可能属于同一个机房。外部调查更适合统计“观察到的入口IP和PoP”，不适合计算物理节点总数。

4. 为什么不同查询工具显示的节点城市不一样？

不同工具可能使用不同IP地理数据库，数据更新时间和定位方法也不同。CDN、Anycast和运营商网络的地址尤其难以精确定位。

5. 竞品不同地区查出不同CDN，是检测错误吗？

不一定。可能是地域多CDN、线路调度、主备切换、IPv4与IPv6分流，也可能处于迁移阶段。需要在相同时间窗口从多个地区重复验证。

6. 响应头没有CDN字段，是不是没有使用CDN？

不是。厂商字段可能被删除、覆盖或白标化，也可能只在特定响应中出现。还要检查DNS、IP网络和不同地区结果。

7. 竞品使用的CDN速度很好，我们接入后也会一样吗？

不一定。CDN表现取决于用户地区、运营商、套餐、缓存策略、协议配置、源站位置和业务资源。竞品调查只能帮助缩小候选范围，最终仍需使用自己的域名和用户分布测试。

8. 多长时间的观测结果才有参考价值？

一次检测适合做快速判断；要分析多CDN、故障切换和节点稳定性，应覆盖多个时间点、主要流量时段及核心地区，并保留每次原始结果。