CDN 的测速结果里，真正能互相比的只有两类：同一个加速域名、同一组节点。换掉其中任何一个，两份数字就只能各看各的。

下面五个说法，是我见过最容易把 CDN 测出错误结论的。

「用本机 ping 一下 CDN，就知道快不快」

ping 给的是 ICMP 往返时间，跟 CDN 返回网页的快慢不是一回事。

CDN 节点离你近，ping 数字好看，但页面照样可能慢：命中率低、回源慢、首字节晚，ping 全都看不出来。

要看的是五段：DNS、连接、TLS、首字节、下载。ping 只能算一个粗筛。

「测速工具测的是我的网站，跟 CDN 没关系」

测的时候域名解析到哪个 IP，测的就是哪个节点。

想确认某一台 CDN 节点的表现，得把请求固定到那个 IP 上：

`` curl -o /dev/null -s -w '%{http_code} %{time_namelookup} %{time_connect} %{time_appconnect} %{time_starttransfer}\n' --resolve 你的加速域名:443:节点IP https://你的加速域名/ ``

正常：返回 200，首字节段明显短于直接测源站。

异常：--resolve 之后报证书错误，多半是这个节点上没有你这张证书，先别当成 CDN 慢。

不指定 IP 的时候，你测到的是调度给你的那台，每次可能不一样。要一次看多个省落在哪台节点上，用宝塔拨测的网站测速选多个地区多个运营商跑一轮，再按地区分组看。

「节点越多越准，拉满全国就行」

节点多解决的是覆盖，不解决可比性。

一次跑八十个节点，你得有能力把结果按运营商、按省份分开看，否则一堆数字只会得出「平均 800 毫秒」这种没用的结论。

想判断 CDN 好不好，先固定十来个有代表性的节点：覆盖两三家运营商、东西南北各有。数字少一点，但每一组都能对上具体地区和运营商。

要扩大范围，也在固定这十来个之后再加，别一次全铺开。

「回源地址和 CDN 地址测出来应该一样」

<figure><img src="https://image.bt.cn/20261110/8d15b68a85ff178e5ed1d0b9d7903b81.svg" alt="两种测法的路径对照图：直接测源站得到基线，测加速域名经 CDN 边缘节点、未命中才回源；下方标注「走 CDN 更慢则慢在 CDN，两边一样慢则回站点」" loading="lazy" width="1200" /><figcaption>回源那个数是地板。走 CDN 比地板还慢，慢在 CDN；跟地板一样慢，就别在 CDN 上折腾了。</figcaption></figure>

这两个地址测出来的数字本来就不该一样，一个是边缘节点给你，一个是从源站直接拿。

回源地址的价值在于基线：同一个页面，回源 300 毫秒、走 CDN 一秒钟（举例），说明问题在 CDN；两边都一秒钟，说明问题回到站点本身。

两个地址各跑一遍，节点组选同一批，结果并排放，才看得出 CDN 是加速了还是拖慢了。

顺手看一眼缓存：同一个 URL 连测两次，第二次首字节还是一样长，要么没命中，要么缓存时间设得太短。

「换个地区测差距大，就是节点坏了」

地区之间的差距，先看是不是不同节点。

同一个 CDN 在不同省通常落在不同节点上，节点之间配置、回源链路、缓存状态都可能不同，差三五百毫秒很常见。

要判断「坏了」，得同一个节点、同一时段、连测三次，三次都异常才算。

分散在多个省的节点同时变慢，更可能是回源侧或调度出问题，不是某一个节点。

反过来说，如果你只在办公室测了一次，看到三秒，就断定 CDN 有问题——那个数字很可能是你这条线路的事，也可能本来就是回源的正常水平。先固定地址、固定节点、固定时段，再谈快慢。