一句话答案：先看拨测给出的「响应 IP 去重数」——只有 1 个 IP，说明 CDN 根本没接管流量；冒出多个 IP，说明分发已经在工作。接着看失败节点是否扎堆在少数 IP、同一 IP 内部快慢是否一致、跟源站直连相比差距是否说得通，四步走完，责任方基本就浮出来了。
上了 CDN 之后，常有人反馈「我这边打不开，可你网站明明是好的」。到底是边缘节点出了毛病、某条线路在抽风，还是源站自己撑不住？这篇用宝塔拨测的一次全国实测（2026-10-27，覆盖 60 个地区、约 390 个成功节点）当样本，带大家用四个判据把 CDN 的问题判清楚。
一、先摆两组基线两个站点各跑一次全国 HTTP 拨测：
站点
| 响应 IP 去重数
| 成功节点
| 总耗时中位数
| 直连源站
| 1 个
| 392
| 269.2 ms
| 走 CDN
| 22 个
| 391
| 455.6 ms
|
直连那个站点，392 个节点无一例外落在同一个 IP 上；接 CDN 的站点则是 391 个节点散到 22 个 IP、铺在 21 个位置。这组对照最能说明 CDN 有没有生效——「一堆 IP」本来就是 CDN 该有的样子，算不上异常。
二、判据一：响应 IP 是不是散的
看结果先找「响应 IP 去重数」这一列。这次 CDN 站点的 IP 分布（按节点数排序，取前五）：
响应 IP
| 节点数
| IP 所属位置
| 117.69.71.130
| 68
| 安徽宿州 / 中国电信
| 123.6.40.77
| 44
| 河南郑州 / 中国联通
| 43.174.246.30
| 24
| 新加坡 / 腾讯云
| 112.84.131.71
| 23
| 江苏扬州 / 中国联通
| 119.36.225.67
| 22
| 湖北襄阳 / 中国联通
|
- 只看到一个 IP → CDN 没接上，或者接了但解析还指着源站。
- 看到多个 IP、而且分布在不同地区 → CDN 在正常分发。
这一步专治一种高频误判：嘴上说「早就上 CDN 了」，实际解析压根没切，全国节点其实都在直连源站。
三、判据二：失败是不是扎堆在少数 IP
CDN 起来以后，个别地区打不开通常是两种成因，方向正好相反：
- 情况 A：个别边缘节点挂了。 表现为失败节点集中在一个或几个响应 IP 上。换个 IP 就能打开，责任在 CDN 服务商那边。
- 情况 B：源站出问题，所有边缘节点回源一起失败。 表现为各个 IP 都有失败或 5xx，且失败原因里带着回源相关的报错。
这次 CDN 拨测，391 个成功节点清一色返回 200，失败只有 3 个（成功率 99.2%），三条分别是 DNS 临时失败、连接超时、任务超时，各占 1 个——彼此原因不同，也没扎堆在某个 IP 上，属于探针或链路的偶发波动，不能算节点故障。
四、判据三：同一个 IP 内部，快慢是否一致
要分清是边缘节点自己出了故障，还是它到用户的链路有问题，就看这一条。
- 边缘节点自身的毛病，会让连它的所有探针一起变慢或一起失败。
- 同一个 IP 下只有一部分节点慢，而且恰好都在同一家运营商，那更可能是这家运营商连到该节点的链路有问题，节点本身是好的。
这次实测最慢的五个节点（5618 ms / 5595 ms / 5358 ms / 5289 ms / 5177 ms）落在五个省份、两家运营商，并没有收拢到同一个响应 IP；最快的反而是新加坡 49.7ms、澳门 112.3ms、德国 152.1ms，符合「边缘节点离用户越近越快」这个常识。两头都看不出哪个节点坏掉了。
五、判据四：拿源站直连做对照
把走 CDN 的那组数据，和直连源站的那组并排比：
指标
| 直连源站
| 走 CDN
| 差异
| 总耗时中位数
| 269.2 ms
| 455.6 ms
| CDN 慢 186.4 ms
| DNS 解析中位数
| 20.2 ms
| 116.4 ms
| CDN 慢 96.2 ms
| 首字节中位数
| 268.9 ms
| 454.6 ms
| CDN 慢 185.7 ms
| TCP 连接中位数
| 39.3 ms
| 21 ms
| CDN 更快 18.3 ms
|
接了 CDN 反倒更慢，慢的两段是 DNS 解析和首字节，TCP 连接这段却是它更快（毕竟边缘离用户更近）。这不算故障，是 CDN 本身的结构性代价：解析要沿 CNAME 一级级查下去，DNS 段自然拉长；边缘没命中缓存时还得回源取内容，首字节跟着变长。CDN 能快，前提是缓存命中。
判断合理性的三条线：
- 首字节比源站高出一截、DNS 又是正常的 → 命中率低，或者回源慢；
- TCP 段比源站还高 → 边缘节点的距离或线路不对。
六、按这个顺序操作- 先看响应 IP 去重数：只有 1 个，掉头去查解析，别在 CDN 上耗时间。
- IP 多于一个，就盯失败节点有没有扎堆：扎堆 → 节点问题；散开 → 接着往下看。
- 再比同一 IP 里的快慢分布：全都慢 → 节点毛病；只有一部分慢、且集中在某运营商 → 线路毛病。
- 最后把直连数据当尺子，定位差异落在 DNS、TCP 还是首字节。
七、自己怎么测
进宝塔拨测的网站测速入口 t.bt.cn/http/，填入域名即可开测。结果页会逐节点列出响应 IP、该 IP 的归属地、各段耗时和返回的状态码，四个判据要看的字段都齐了。想单独核对解析，再去 DNS 测速 跑一次，比较各节点拿到的结果是否相同。
字段含义参照文档《使用宝塔拨测》。本文数值来自 2026-10-27 的真实拨测，IP 归属和节点池随时会变，只代表采集那一刻的情况。
常见问题
怎么看网站到底有没有走 CDN？
看「响应 IP 去重数」最直观。这次接 CDN 的站点，391 个成功节点连出去 22 个不同 IP，落在 21 个位置上；作为对照的直连站点，392 个节点共用一个 IP。独占一个 IP 就是没有分发，多个 IP 且散在不同地区，才说明 CDN 在干活。
部分地区打不开，怎么排除是不是 CDN 节点的锅？
分三步收窄：第一步看失败的节点有没有扎堆在少数几个 IP 上，扎堆了就是那个边缘节点的问题；第二步看这些 IP 是否集中在某个地区或某家运营商，是的话属于区域性故障；第三步直接对源站 IP 拨一次测，源站响应正常而 CDN 异常，锅就在 CDN 侧。
接了 CDN 反而更慢，这正常吗？
有可能。这次实测里，接 CDN 的那组总耗时中位数是 455.6ms，直连源站则是 269.2ms。没命中缓存就得回源，中间还多一层代理，首字节自然抬高；DNS 解析也从 20.2ms 涨到 116.4ms。CDN 的价值在缓存命中和就近分发，并不是任何场景都比直连快。
同一个 IP 下有的快有的慢，说明什么？
说明节点本身大概率没坏，问题出在节点到用户之间那段路。节点真故障的话，连它的探针会一起慢、一起失败；只有一部分慢且集中在某家运营商，基本就是这家运营商到节点的链路在拖后腿。
部分节点拿到的 IP 和预期对不上，怎么办？
先去 CDN 服务商公布的地址段里核对这些 IP 在不在范围内。不在范围内的话，可能是 DNS 缓存还没过期、本地 DNS 被劫持，或者这些节点绕开 CDN 直连了源站。配合 DNS 测速看各节点的解析结果，能进一步区分。
以上就是判断 CDN 节点故障的四个判据。下次再有人反馈「我这儿打不开」，先跑一次拨测看分布，别急着把锅甩给 CDN 或者源站。有问题欢迎回帖。
|
|
运维要高效，装宝塔
