CDN检测查不出来，是没用CDN还是没识别到？

输入域名，点击检测，等了几秒，结果却只告诉你：未识别到CDN。

看到这里，很多人的第一反应是：“这个网站没用CDN。”也有人马上怀疑工具不准，因为自己明明在后台开通过加速服务。

这两种情况都有可能，但都不能只凭一次“未识别”下结论。

CDN检测本质上是在公开网络中寻找证据：DNS有没有指向CDN调度域名、响应IP属于谁、响应头里有没有厂商特征、不同地区是否连接到不同节点。

证据足够时，可以识别出具体厂商；证据被隐藏、请求受阻或样本不足时，就只能得到“未识别”。

先记住一句话：

“未识别到CDN”描述的是当前检测没有获得足够证据，不等于已经证明网站没有使用CDN。

“没用CDN”和“没识别到”到底差在哪里？

可以把检测结果理解成四种状态：

真正的“没有使用反向代理型CDN”，通常需要更多信息互相印证。

例如：站点所有者确认CDN配置未开启；公开DNS直接指向自有源站；CDN日志里也没有对应流量。

如果只是普通访客，只能观察公开信号。最严谨的说法应该是“暂未检测到明显CDN证据”，而不是“这个网站肯定没用CDN”。

为什么网站用了CDN，却可能检测不出来？

1. 查错了域名：主站没走，静态资源在走

这是最常见、也最容易忽略的一种情况。

一个网站可能把页面放在：

www.example.com

图片、JavaScript和下载文件却放在：

static.example.com
img.example.com
download.example.com

如果只检测 www.example.com，结果可能没有CDN；但用户实际加载的大部分资源已经由静态资源域名加速。

还有些网站会把裸域名 example.com 301跳转到 www.example.com。检测裸域名和检测最终落地的主机名，得到的结果也可能不同。

所以第一步不是换工具，而是先确定：你检测的到底是哪一个业务域名？

2. CDN配置存在，但代理并没有真正开启

“在CDN平台注册了域名”和“线上流量已经经过CDN”不是一回事。

常见情况包括：

• CNAME还没有修改；

• DNS仍然指向源站；

• CDN域名处于暂停、审核或部署中；

• 只完成了证书配置，没有完成流量切换；

• 某条记录被设置成仅DNS解析，没有启用代理。

以Cloudflare为例，官方的代理状态说明明确区分了Proxied和DNS-only：前者让HTTP/HTTPS流量经过Cloudflare，后者只提供DNS解析并直接返回源站地址。

这种情况下，检测工具查不出CDN并不是“漏判”，而是当前被检测的请求确实没有经过CDN。

3. CNAME被扁平化，厂商特征藏在了后面

很多检测会先看CNAME，因为 example.cdnprovider.net 这类调度域名往往带有比较明显的厂商特征。

但根域名通常不能使用普通CNAME，一些DNS服务会通过ALIAS、ANAME或CNAME Flattening直接返回最终A/AAAA地址。这样一来，查询者只能看到IP，看不到中间的CDN调度域名。

Cloudflare在CNAME Flattening说明中介绍了这种机制：DNS平台会沿着CNAME链找到最终IP，再把地址直接返回给查询者。

所以，“查询不到CNAME”只能说明公开答案里没有CNAME，不能单独证明没有CDN。

4. 使用了自定义域名或白标CDN

有些CDN会提供厂商域名作为CNAME目标，特征很明显；另一些服务则会使用客户自己的调度域名、白标域名或云平台通用入口。

例如CloudFront允许用户为分配配置自定义域名和证书，DNS可以通过CNAME或根域名ALIAS指向分配。

AWS的CloudFront域名配置文档也说明，根域名可以通过ALIAS接入，而不一定在公开结果中出现普通CNAME。

当厂商名称没有直接出现在DNS链里，检测只能继续依靠IP归属、TLS和HTTP特征。如果这些信号也不明确，就可能只能判断“疑似使用代理网络”，无法准确报出品牌。

5. 厂商特征响应头被删除或改写

常见CDN可能在响应中加入 Via、Age、X-Cache、请求ID或厂商自定义字段，但这些头不是强制存在的。

站点可以通过边缘规则删除部分响应头，也可能在CDN前后叠加网关、负载均衡或另一层代理。最终返回给客户端的字段，未必保留最初的厂商特征。

反过来也一样：看到一个 X-Cache 并不能立即认定是哪一家CDN，因为源站或普通反向代理也能添加同名字段。

响应头应该被当作证据之一，而不是唯一答案。

6. 请求经过CDN，但内容没有缓存

这是很多站长最容易误判的地方：

没有看到 HIT ≠ 没有经过 CDN

登录页面、购物车、API接口以及带有 Cache-Control: private 或 no-store 的响应，本来就可能不缓存。

CDN还可以只提供TLS终止、WAF、DDoS防护和动态加速，每次请求仍然回源。

Google Cloud的Cloud CDN排障文档也说明，只有符合缓存条件的响应才会被缓存，应结合后台配置、响应头和日志判断。

换句话说，连续出现 MISS、BYPASS，或者完全没有 Age，都不能单独证明请求没有经过CDN。

7. 使用多CDN或按地区、运营商调度

网站可能同时接入两家甚至多家CDN：

• 中国大陆走国内厂商，海外走全球厂商；

• 移动、联通、电信走不同线路；

• 主CDN故障时自动切到备用CDN；

• 部分流量用于灰度测试；

• IPv4和IPv6采用不同入口。

如果检测只从一个地区、一个网络发起，它看到的只是当时命中的那条路径。某个节点没有识别出来，不代表其他地区也一样。

这类网站最好使用CdnChart网站测速从不同地区交叉测试，再比较响应IP、运营商、ASN和HTTP结果。

8. WAF、反爬虫或访问策略挡住了探测请求

检测通常至少需要完成DNS解析、TLS握手和HTTP请求。

如果网站对数据中心IP、特定地区、User-Agent或访问频率有限制，探测节点可能只拿到403、验证码页面、连接重置或超时。

此时工具看到的可能是WAF返回的错误页，也可能根本拿不到足够的HTTP证据。

这应当被理解成“检测受阻”，而不是“没有CDN”。

9. 使用自建边缘网络或较小的服务商

CDN识别依赖可维护的特征库。

大型厂商通常有相对稳定的CNAME规则、IP段、ASN或响应字段；自建CDN、区域服务商和刚上线的产品，公开特征可能很少，也可能尚未被收录。

这时可以观察到“多地区IP不同”“响应来自共享边缘网络”等现象，却不一定能给出准确厂商名称。

对检测平台来说，宁可显示未知，也不应该为了给出答案而强行猜测。

CDN检测查不出来，应该怎么复核？

下面这套流程不要求你一定是运维工程师。普通用户可以完成前四步；如果是站点所有者，再继续检查后台和日志。

第一步：确认最终访问的域名

先看域名是否发生跳转：

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

重点看：

• 最终URL是否从裸域跳到 www；

• 是否跳到另一个品牌域名；

• 最终连接IP是什么；

• 是否正常返回200，还是403、5xx或超时。

如果最终域名已经改变，要把跳转后的域名重新放进CDN检测工具检查。

第二步：分别查询A、AAAA和CNAME

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

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

不要只查A记录。部分网站的IPv4与IPv6路径不同，裸域和 www 也可能采用完全不同的接入方式。

结果可以这样理解：

• 出现明显的CDN调度域名：属于较强证据；

• 只返回CDN网络IP：可能经过CDN，但还要结合其他信号；

• 只返回普通云主机或源站IP：可能没有代理，也可能是难以识别的云边缘入口；

• 没有CNAME：可能是A记录直连，也可能是ALIAS或CNAME扁平化。

第三步：换公共解析器对比DNS结果

dig @1.1.1.1 www.example.com A +noall +answer
dig @8.8.8.8 www.example.com A +noall +answer

dig @1.1.1.1 www.example.com AAAA +noall +answer
dig @8.8.8.8 www.example.com AAAA +noall +answer

如果答案不同，可能涉及DNS缓存、地域调度、多CDN或配置变更。

公共解析器的结果仍然不能代表所有真实用户，因此需要继续做多地区测试。

第四步：查看完整响应头，不要只搜一个字段

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

可以重点观察：

• Via；

• Age；

• X-Cache或相似缓存状态；

• 厂商请求ID；

• Server；

• 证书和TLS连接情况；

• HTTP状态码和跳转位置。

某些CDN在缓存命中时会加入 Age。例如Google Cloud文档给出的示例中，Age表示响应由已有缓存条目提供。

但没有这些字段仍不能排除CDN，因为字段可能被隐藏，当前内容也可能不可缓存。

可以连续请求一个公开的静态文件进行观察：

for i in 1 2 3; do
  curl -sS -D - -o /dev/null https://www.example.com/assets/logo.png
done

不要用带登录状态、订单信息或用户数据的页面做缓存测试。

第五步：从多个地区和网络测试

本机查询只能代表一条访问路径。

使用CdnChart网站测速时，可以把不同探测地区的结果放在一起比较：

• 响应IP是否变化；

• IP归属和ASN是否一致；

• 国内与海外是否命中不同厂商；

• IPv4、IPv6路径是否一致；

• 某些地区是否集中出现403或超时。

如果多个地区都连接到同一个明确的源站IP，只能说明“没有观察到明显的边缘调度”；如果不同地区连接到不同网络，则应继续判断是CDN、云负载均衡、DNS调度还是多活架构。

第六步：站点所有者检查控制台和日志

对于自己的网站，最可靠的证据始终来自第一方配置：

1. CDN加速域名是否处于启用状态；

2. 线上DNS是否已经指向当前分配或代理入口；

3. CDN访问日志中是否有对应请求；

4. 源站日志里的连接来源是否为CDN回源网络；

5. 缓存规则是否允许测试资源被缓存；

6. WAF或访问控制是否拦截了探测节点。

可以在自己控制的站点上放置一个不含敏感信息的小型静态文件，例如：

/_cdn-check.txt

给文件写入明显的版本标识，在CDN后台查看请求、缓存状态和日志；必要时执行一次缓存刷新，再观察后续请求。

由于不同地区可能进入不同缓存节点，一次 MISS 后不一定马上出现 HIT，仍应以厂商控制台和日志为准。

根据结果，怎么判断更稳妥？

哪些判断方法最容易出错？

“没有CNAME，所以没用CDN”

不准确。根域名ALIAS、CNAME扁平化和A记录接入都可能不显示普通CNAME。

“没有缓存HIT，所以没用CDN”

不准确。动态内容、私有响应、首次访问和主动绕过缓存都可能没有HIT，但流量仍经过CDN。

“IP属于云厂商，所以一定是该厂商CDN”

不准确。同一个云网络可能同时承载计算、负载均衡、托管平台和CDN业务，ASN只能证明网络归属，不能单独证明具体产品。

“换三个检测工具都没识别，所以一定没有”

也不够严谨。多个工具可能依赖相似的公开特征库。如果网站隐藏了相同的证据，工具数量增加并不会自动补齐证据。

常见问题

CDN检测未识别是什么意思？

通常表示当前收集到的DNS、IP、HTTP、TLS等公开信号不足以确定CDN厂商。

它可能是没有使用CDN，也可能是特征被隐藏、检测受阻、只在部分域名使用，或该服务商尚未收录。

CDN检测显示未使用，但网站访问很快，怎么回事？

速度快不等于一定使用CDN。

源站可能离你很近、服务器性能较好，也可能使用了云负载均衡、专线或其他网络优化。

反过来，使用CDN的网站也可能因为回源慢、缓存率低或线路异常而访问较慢。

为什么同一个域名换个地区就能识别出来？

网站可能使用地域DNS、多CDN或运营商调度，不同地区会进入不同的网络；也可能某个地区的请求被WAF拦截，另一个地区获得了完整响应。

单节点结果不能代表全球访问路径。

能不能通过一个响应头直接确定CDN厂商？

有些厂商字段具有较强特征，但稳妥的识别仍应结合CNAME、IP/ASN、TLS和多地区结果。

通用字段可能被改写、伪造或由普通反向代理添加。

自己的网站明明开了CDN，为什么还是查不到？

优先检查检测域名是否正确、线上DNS是否完成切换、代理状态是否启用，以及请求是否被WAF阻断。

然后查看CDN控制台和访问日志。后台有真实请求记录，比任何外部指纹判断都更可靠。

最后：未识别是结果，也是边界说明

CDN检测不是看见一个IP就给它贴标签。一个可靠的判断，通常需要把CNAME、响应IP与ASN、HTTP响应头、TLS证书和多地区观测放在一起。

因此，遇到“未识别”时，正确的处理顺序是：

1. 确认检测的是最终业务域名；

2. 分别检查A、AAAA和CNAME；

3. 查看完整HTTP响应和跳转；

4. 使用多地区探测交叉验证；

5. 如果是自有站点，再回到CDN控制台和日志确认。

你可以先使用CdnChart CDN检测查看域名的公开证据，再通过CdnChart网站测速比较不同地区实际命中的响应IP。

想了解平台如何组合CNAME、响应头、ASN和TLS信号，可以继续阅读如何识别网站使用的CDN和CdnChart方法论。