CDN检测工具哪个好？输入域名后应该返回哪些信息

想知道一个网站用了哪家CDN，很多人会打开一个CDN检测工具，输入域名，然后等待页面显示“Cloudflare”“阿里云CDN”或者其他厂商名称。

问题是，只返回一个厂商名称，并不足以证明识别结果可靠。

域名可能启用了CNAME隐藏或扁平化解析，节点IP可能属于云服务商而不是CDN厂商，多家CDN也可能根据地区动态调度。甚至有些网站只是使用了反向代理、WAF或负载均衡，并没有使用完整的CDN服务。

因此，判断CDN检测工具哪个好，关键不是它能识别多少个品牌，而是它能否回答三个问题：

1. 为什么判断这个域名使用了某家CDN？

2. 判断依据来自DNS、IP、HTTP还是TLS？

3. 如果不同证据互相冲突，工具会不会如实提示不确定性？

一个真正有用的CDN检测结果，应当同时返回识别结论、原始证据、置信度、数据时间和必要的风险提示，而不是只给出一个看似确定的答案。

CDN检测工具哪个好？先看它能不能解释结果

不同工具擅长的方向并不相同，不能只凭页面简单、查询速度快就判断优劣。

如果只是临时查看CNAME，普通DNS工具已经够用；如果需要判断网站到底使用了哪家CDN，则应选择能够进行多维度交叉验证的综合工具。

CDNChart的CDN检测工具目前会从CNAME链、HTTP响应头和公开网络信号等方向交叉判断疑似CDN厂商，并展示识别证据。页面同时说明识别结果会提供置信度与更新时间，而不是把单一特征直接当成最终结论。

输入域名后，第一项应该返回明确的识别结论

检测结果顶部应当先给用户一个可以直接理解的结论，例如：

• 疑似使用Cloudflare；

• 发现Akamai相关网络特征；

• 可能同时使用两家CDN；

• 发现反向代理，但暂时无法确认CDN厂商；

• 未发现足够的公开CDN特征；

• 域名无法解析或目标拒绝访问。

这里最好使用“已确认”“高概率”“疑似”或“证据不足”等不同等级，而不是所有结果都用同一种肯定语气。

工具还应区分“网络服务商”和“CDN产品”。某个IP属于一家大型云厂商，只能说明请求进入了该厂商控制的网络，不能直接证明网站购买了该厂商的某款CDN、WAF或DDoS防护产品。

同样，检测出Cloudflare网络，也不代表工具能够进一步确认网站使用的是免费套餐、企业套餐，或者已经开启某项具体安全功能。

CNAME链是CDN识别的重要起点

较完整的结果应展示从用户输入域名到最终解析目标的整个CNAME链，而不是只显示最后一个IP。

例如：

www.example.com
→ www.example.com.cdn-provider.example
→ edge-region.example
→ 203.0.113.10

CNAME中的厂商域名后缀经常具有较强的识别价值。按照RFC 9499对DNS术语的说明，CNAME记录用于说明某个名称是别名，并指向对应的规范名称。

用户也可以自行检查：

dig www.example.com CNAME
dig www.example.com A
dig www.example.com AAAA

Windows环境可以使用：

nslookup -type=CNAME www.example.com
nslookup www.example.com

需要关注的不是“有没有CNAME”这么简单，而是：

• CNAME最终指向什么域名；

• 是否存在多级CNAME；

• IPv4与IPv6是否进入不同网络；

• 根域名和www子域名是否采用相同配置；

• 不同DNS服务器是否返回不同结果。

不过，没有查到CNAME并不等于没有使用CDN。根域名可能采用ANAME、ALIAS或CNAME Flattening，某些服务也会直接返回Anycast IP。因此，CNAME应当作为重要证据之一，而不是唯一标准。

响应IP、ASN和IP归属信息不能缺失

CDN检测工具还应返回当前解析到的IPv4、IPv6、ASN以及IP登记信息。

比较实用的字段包括：

• 响应IP；

• IPv4或IPv6；

• ASN编号；

• ASN名称；

• IP登记机构；

• 国家或地区；

• 网络前缀；

• 查询节点；

• DNS解析时间；

• 数据更新时间。

ASN比单纯的IP地理位置更适合判断网络归属。用户可以通过RDAP查询IP地址和自治系统的公开登记数据。ICANN对RDAP的介绍说明，该协议用于访问当前注册数据，并逐步替代传统WHOIS查询。

但IP归属同样不能独立证明CDN厂商。常见情况包括：

• CDN租用了第三方运营商的地址；

• 网站运行在云服务器上，但没有启用CDN；

• 多个产品共享同一段边缘网络；

• IP登记信息仍显示历史持有者；

• Anycast地址在多个地区同时发布；

• 数据库显示的位置只是注册地址或推测位置。

所以，工具如果只凭“IP属于某云厂商”就直接给出确定结论，误判概率并不低。

HTTP状态码和响应头应显示原始证据

请求到达目标后，检测工具应展示HTTP状态码、协议版本、重定向过程以及与CDN有关的响应头。

值得关注的字段可能包括：

Server
Via
Age
Cache-Status
X-Cache
X-Cache-Hits
X-Served-By
CF-Ray
CF-Cache-Status
X-Amz-Cf-Pop
X-Amz-Cf-Id
X-Akamai-Transformed

这些字段并不是每个网站都会返回，也没有任何一个字段能够覆盖全部CDN厂商。

按照RFC 9110定义的HTTP语义，响应状态码用于描述请求的处理结果；响应头则携带与消息和响应处理有关的字段。 对CDN识别来说，状态码可以帮助判断检测请求是否真正成功到达目标，而特征响应头则可以提供厂商、节点或缓存路径线索。

可以使用下面的命令自行检查：

curl -I -L https://www.example.com/

重点查看：

• 最终状态码是不是200；

• 是否先经过301或302跳转；

• 每次跳转的域名是否发生变化；

• 是否出现CDN特征响应头；

• Age、Cache-Status或厂商缓存头是否表明命中缓存；

• 403或429是否由安全策略、限流或反爬规则产生。

需要注意，站长可以隐藏或修改Server等响应头，部分安全网关也会重写后端返回内容。一个名为X-Cache的字段甚至可能由站点自行添加，所以单个响应头不能作为绝对证据。

TLS证书和SNI能提供辅助线索

HTTPS网站的检测结果还可以返回：

• TLS协议版本；

• 证书覆盖的域名；

• 证书签发机构；

• 证书有效期；

• 证书链是否完整；

• ALPN协商结果；

• 当前是否支持HTTP/2或HTTP/3；

• 使用指定域名进行SNI握手时返回的证书。

检查TLS信息时，必须保留正确的域名和SNI。因为同一个边缘IP上可能承载大量HTTPS网站，直接访问IP得到的证书和响应通常没有判断价值。RFC 6066说明了SNI的用途：客户端在TLS握手中提供目标服务器名称，使同一网络地址上的多个虚拟服务能够返回合适的配置。

手动查看证书可以使用：

openssl s_client -connect www.example.com:443 \
  -servername www.example.com </dev/null

如果要验证某个响应IP是否能够承载该域名，应使用：

curl --resolve www.example.com:443:203.0.113.10 \
  -I https://www.example.com/

--resolve会把域名临时指定到目标IP，同时保留HTTP Host与TLS SNI。相比直接访问https://203.0.113.10/，这种方法更接近真实访问过程。

不过，证书由常见CA签发并不能证明CDN身份；多个CDN也可能使用相同CA。TLS信息更适合用于确认域名是否被该边缘节点正确接管，以及检查证书和SNI配置是否正常。

好的CDN检测工具应展示“证据为什么成立”

理想的检测结果不应只有一行厂商名称，而应该把证据拆开显示。例如：

如果CNAME指向厂商A，但响应IP和HTTP特征更像厂商B，工具不应强行选择一个答案。这可能是多层代理、CDN套CDN、迁移未完成，也可能是指纹数据过期。

更合理的输出是：

主要判断：疑似使用厂商A
置信度：中等

支持证据：
- CNAME后缀与厂商A匹配
- 两个响应头符合厂商A特征

冲突信息：
- 当前响应IP登记在厂商B的ASN下

建议：
- 从更多地区重新检测
- 分别检查根域名与www子域名

这样的结果才便于用户复核，也能避免把算法猜测包装成确定事实。

为什么CDN检测需要多地区结果

只从一个地区查询域名，可能只能看到调度系统的一小部分。

多CDN系统可能根据用户国家、运营商、网络质量、故障状态或业务规则返回不同服务商。即使使用同一家CDN，北京电信、广州移动和海外节点解析到的响应IP也可能完全不同。

如果检测目的是确认多CDN调度或节点覆盖，可以先使用CDN检测工具查看服务商与识别证据，再通过CDNChart的网站测速工具观察不同地区和运营商返回的响应IP、IP位置、状态码、解析时间、连接时间和总耗时。

CDNChart当前网站测速页面会按中国电信、中国联通、中国移动以及港澳台和海外节点展示测试结果，并提供响应IP、IP位置、状态、解析、连接、下载、重定向和总耗时等字段。

这里要分清两个功能的职责：

• CDN检测解决“疑似用了哪家CDN，判断依据是什么”；

• 多节点测速解决“不同地区访问到了哪些IP，速度和状态是否一致”。

速度快慢本身不能证明厂商身份，但多地区响应IP可以帮助发现多CDN、调度异常和部分地区未接入CDN的问题。

输入域名后还应返回检测范围与时间

CDN指纹不是永久不变的。厂商会新增IP段、调整CNAME后缀、修改响应头，网站也可能随时迁移服务商。

因此，检测结果至少要标明：

• 检测时间；

• 指纹库更新时间；

• 查询位置；

• 查询的具体主机名；

• 是否跟随重定向；

• 是否检测IPv6；

• HTTP请求方法；

• 请求是否被阻断；

• 原始证据是否可以展开查看。

如果工具只显示一个厂商Logo，却不显示检测时间和输入主机名，用户很难判断结果对应的是当前域名、历史缓存还是跳转后的另一个网站。

还要特别注意“域名”与“网站”的区别。以下地址可能使用完全不同的服务商：

example.com
www.example.com
static.example.com
api.example.com
download.example.com

检测www.example.com的结果不能自动代表所有子域名。

哪些情况容易让CDN检测工具判断错误

私有CDN或小型服务商

私有CDN没有公开的CNAME后缀、IP段或响应头指纹，工具可能只能识别出托管网络，无法判断具体产品。

根域名隐藏了CNAME

DNS服务商可能在权威端完成CNAME Flattening，对外只返回A或AAAA记录。这时必须结合IP、ASN和HTTP特征判断。

网站同时使用多家CDN

不同地区、运营商或业务子域名可能进入不同CDN。一次查询只看到一家，并不能排除其他服务商。

WAF、反向代理与CDN混在一起

工具可能识别到最外层代理网络，但无法判断后面是否还有另一层CDN，也不能仅凭网络特征确认WAF是否开启。

检测请求被拦截

如果工具得到403、429、连接超时或验证码页面，返回的响应头可能来自安全拦截页，而不是正常业务内容。

IP位置被当成节点物理位置

IP数据库通常只能提供登记位置或推测位置。它不能精确证明服务器机房所在城市，更不能代表请求一定在那里完成处理。

选择CDN检测工具时可以这样判断

如果你的目的只是查看域名解析，选择能够完整展示CNAME、A和AAAA记录的DNS工具即可。

如果需要判断网站使用的CDN服务商，应优先选择同时具备以下能力的工具：

• 展示完整DNS解析链；

• 返回响应IP和ASN；

• 保留HTTP原始响应头；

• 说明具体识别证据；

• 给出置信度而非绝对结论；

• 显示检测时间和数据更新时间；

• 支持识别多CDN或冲突结果；

• 能与多地区节点测速衔接；

• 明确说明没有识别出来的原因。

CDNChart适合用来完成初步服务商识别和证据核对；如果还要判断不同地区的实际访问情况，可以继续进行多节点测速。平台的测试方法与评分标准则用于了解探针、样本、指标和已知局限。检测结果适合发现线索和排查配置，但不能代替企业内部网络日志、CDN控制台记录或供应商合同确认。

常见问题

1. CDN检测工具显示“未识别”，是不是网站没有使用CDN？

不是。未识别只表示当前公开证据不足。私有CDN、隐藏CNAME、自定义响应头、IP数据库更新延迟以及检测请求被拦截，都可能导致工具无法确认厂商。

2. CNAME指向某个CDN，就能确定网站正在使用它吗？

CNAME是较强证据，但仍应检查最终响应IP和HTTP结果。迁移残留、错误配置或失效的接入域名，都可能造成“DNS看起来已接入，实际请求却没有正常经过CDN”。

3. 为什么两个CDN检测工具给出的结果不同？

它们可能使用了不同的指纹库、IP数据库、查询地区和判断规则。可以比较两边展示的CNAME、ASN、响应头和检测时间，不要只比较最终厂商名称。

4. 检测结果出现两个CDN厂商正常吗？

正常。网站可能按地区使用多CDN，也可能采用CDN套WAF、CDN套CDN或迁移期间双轨运行。应从多个地区重复查询，并分别检查各个业务子域名。

5. 只查IP地址能识别CDN吗？

只能获得部分线索。共享网络、租用地址和云平台IP都会造成误判。更可靠的方法是把IP与CNAME、ASN、HTTP响应头和TLS握手结果交叉验证。

6. CDN检测能判断缓存是否命中吗？

有时可以。Age、Cache-Status以及厂商特征缓存头可能显示HIT、MISS或缓存驻留时间，但这些字段并非所有网站都会公开。没有缓存头不代表一定没有缓存。

7. CDN检测结果可以作为更换厂商的依据吗？

可以作为初步调查依据，但不能单独决定迁移。正式选型还应测试真实业务URL，比较目标用户地区的延迟、可用性、吞吐、安全能力、价格和技术支持，并通过试用或POC验证。