CDN节点延迟高但源站正常，问题通常不在源站本身

线上排障时经常遇到这种场景：源站直接 ping 只有 20ms 到 40ms，curl 源站接口也很快，但用户访问 CDN 域名就是慢，瀑布图里 TTFB 飙到 800ms、1.5s，甚至偶发 5xx。很多人第一反应是源站扛不住，或者 CDN 厂商有问题，但实际使用中发现，这类问题更常见的是“用户到 CDN 节点”“CDN 节点到源站”“CDN 调度策略”这三段链路里某一段出了偏差。

排这种问题不要只看源站监控。源站 CPU、内存、负载、Nginx upstream、数据库连接都正常，只能说明源站没明显瓶颈，不代表 CDN 访问链路没问题。CDN 是中间层，延迟高可能发生在用户接入边缘节点之前，也可能发生在边缘节点回源时，还可能是命中了一个不适合当前用户网络的节点。

先把访问路径拆开，不要只盯一个 ping 值

CDN 访问路径大致是：用户终端 → Local DNS / DoH → CDN 调度系统 → CDN 边缘节点 → CDN 中间层或回源节点 → 源站。源站正常，只验证了最后一段的一部分。用户看到慢，可能慢在前面任何一个环节。

比较典型的数据是这样的：用户访问 CDN 域名，ping 延迟 180ms，页面 TTFB 1200ms；同地区机器直接访问源站 IP，ping 35ms，curl TTFB 90ms。这个结果不能直接下结论说 CDN 节点差，因为还要看用户被调度到了哪里，节点是否回源，回源链路是否跨运营商，是否有 HTTPS 握手异常，是否缓存未命中。

排查时建议同时抓四组数据：用户到 CDN 节点的 ping / mtr，用户访问 CDN 域名的 curl 时间拆分，CDN 节点回源日志或厂商侧回源耗时，源站本机 access log 的 request_time。少一组数据，就容易误判。

常见场景：用户被调度到了远节点

CDN 延迟高但源站正常，最常见的一类问题是调度不准。比如用户在华南电信，理论上应该命中华南或华东电信节点，结果 DNS 解析到了华北联通节点，甚至解析到海外节点。ping 一下 CDN 域名发现 150ms 起步，这种情况下源站再快也没用，用户第一跳就绕远了。

实际使用中发现，调度不准不一定是 CDN 厂商单方面的问题，Local DNS 也经常参与“捣乱”。有些企业内网出口 DNS 使用了异地公共 DNS，用户人在广州，DNS 出口却在北京；CDN 调度系统看到的是北京 DNS，自然给北京节点。还有一些用户用 8.8.8.8、1.1.1.1、DoH，调度结果就更容易偏。

可以这样对比：

用户 A：广州电信，使用本地运营商 DNS，CDN 解析到广州节点，ping 18ms，TTFB 120ms。

用户 B：广州电信，使用公共 DNS，CDN 解析到北京节点，ping 58ms，TTFB 260ms。

用户 C：广州电信，企业出口走香港代理，CDN 解析到香港节点，ping 90ms，TTFB 480ms。

这里补充一点，traceroute 或 mtr 看到的节点 IP，不一定就是业务实际处理节点。有些 CDN 使用 Anycast IP 或节点内层转发，IP 归属地库也可能不准。更靠谱的是结合 CDN 控制台里的命中节点、X-Cache、Via、Age、自定义响应头一起看。

缓存没命中，CDN 每次都在回源

源站正常，但 CDN 慢，还有一种非常常见：缓存策略没生效。用户以为访问的是 CDN，实际每个请求都在穿透回源。源站在监控里看起来没压力，是因为 QPS 不高；但每次请求都要走 CDN 节点到源站的链路，TTFB 自然比直连更高。

特别是动态接口、带 Cookie 的请求、带 Authorization 的请求、URL 后面拼了随机参数的静态资源，很容易导致缓存绕过。比如 /static/app.js?v=timestamp 每次 timestamp 都变，CDN 认为每个 URL 都是新对象；或者响应头里带 Cache-Control: no-store，CDN 就不会缓存。

现场看过一个案例，源站直连下载 50MB 文件速度 80MB/s，用户通过 CDN 下载只有 2MB/s。开始怀疑 CDN 节点带宽不足，后来查响应头发现 Age 一直是 0，X-Cache 一直 MISS。原因是源站给大文件统一加了 Set-Cookie，CDN 默认不缓存带 Set-Cookie 的响应。去掉这个头以后，同区域用户下载速度回到 40MB/s 到 70MB/s。

判断缓存是否命中，不能只看“是否配置了缓存规则”，要看线上响应结果。重点看这些字段：X-Cache 是 HIT 还是 MISS，Age 是否增长，CDN 控制台命中率是否稳定，回源带宽是否跟用户访问同步上升。如果命中率长期低于 30%，那这个 CDN 基本就在当反向代理用。

回源链路绕路，源站本地看不出来

还有一类比较隐蔽：用户到 CDN 节点不慢，源站本身也不慢，但 CDN 节点回源慢。比如用户在上海，命中了上海 CDN 节点，ping 节点 15ms；源站在香港，用户自己直连源站 45ms；但 CDN 上海节点回源香港源站却要 180ms，中间走了普通国际线路或跨运营商绕路。

这种问题源站监控很难直接暴露。源站看到的是请求到达以后处理很快，Nginx request_time 可能只有 30ms，但 CDN 侧 total time 是 600ms。慢在 CDN 节点发起连接、TLS 握手、跨境链路传输这部分。

多说一句，海外源站接国内 CDN 时，回源线路比很多人想得更重要。普通国际链路、BGP、CN2、CN2 GIA、精品线路，体验差异很大。静态资源缓存命中率高时差异没那么明显；一旦有大量动态回源，线路质量会直接体现在 TTFB 上。

如果业务源站需要放在香港、韩国、台湾这类地区，同时又比较看重大陆访问质量，可以在购买源站服务器时就考虑线路类型。比如面向 SEO 站群、企业站点，可以看香港 CN2 精品线路；游戏、接口类业务更关注稳定回国链路和防护能力。如果你也在找这种海外云服务器、G口大带宽服务器或高防服务器，可以看看129云，像香港多 IP 站群-C 型、韩国-G 型这类产品更适合有明确线路和防护诉求的场景，选型不确定也可以直接问客服热线 400-9177118。

HTTPS 握手和证书链也会把延迟拉高

有些 CDN 延迟高，看起来像网络问题，实际是 HTTPS 握手慢。尤其是移动网络、跨境访问、老旧客户端、证书链过长、OCSP 查询异常时，首包时间会被明显拉高。

curl 可以把时间拆出来看，例如：

namelookup_time 20ms，connect_time 45ms，appconnect_time 420ms，starttransfer_time 900ms。

这种数据说明 TCP 建连还行，但 TLS 阶段明显偏慢。常见原因包括 CDN 节点证书配置异常、证书链过长、TLS 版本兼容策略太宽、HTTP/2 协商异常、OCSP stapling 没开或状态不稳定。

如果 appconnect_time 长期高于 connect_time 很多，就不要一直拿 mtr 查路由。mtr 只能告诉你网络层大概情况，不能解释 TLS 握手细节。可以用 openssl s_client、curl -w、浏览器 DevTools、CDN 控制台 HTTPS 监控一起看。

节点负载高，表现是抖动而不是一直慢

CDN 节点负载高的时候，表现通常不是稳定高延迟，而是抖动。比如同一个 URL，连续访问 10 次，有 7 次 TTFB 80ms，有 3 次 TTFB 1200ms。这种情况更像节点队列、磁盘 IO、缓存热度、连接池、限速策略或局部故障。

如果是网络绕路，延迟通常比较稳定，比如一直 150ms 到 200ms。如果是节点负载或缓存层问题，曲线会像尖刺，偶发慢请求比较多。线上排障时可以把请求时间按 P50、P90、P99 分开看，不要只看平均值。平均 200ms 可能掩盖 P99 3s 的问题。

一个实际场景：某下载站用户反馈“偶尔特别慢”，源站带宽和负载都正常。CDN 控制台看整体命中率 92%，似乎没问题。后来按节点维度拆开，发现某个华东节点 P99 TTFB 到 4s，其他节点只有 300ms。把该区域节点临时摘除后，投诉量明显下降。这类问题要找 CDN 厂商看节点级别指标，客户侧只看域名整体数据很难发现。

跨运营商访问，源站正常不代表用户链路正常

国内网络里，电信、联通、移动之间的互联质量会影响 CDN 体验。源站在电信机房，用户也是电信，直连当然很快；但 CDN 节点如果调度到联通或移动出口，链路可能绕一圈。反过来也一样。

测试时不要只拿一台办公电脑说事。至少要覆盖电信、联通、移动，多地区取样。比较常见的现象是：

上海电信访问 CDN：ping 18ms，TTFB 100ms。

上海移动访问 CDN：ping 38ms，TTFB 260ms。

河南联通访问 CDN：ping 75ms，TTFB 600ms。

广东移动访问 CDN：ping 25ms，TTFB 130ms。

这种数据说明不是源站统一慢，而是某运营商或某区域节点存在链路质量问题。对 CDN 厂商提工单时，最好带上客户端 IP、解析到的 CDN IP、访问时间、mtr 结果、curl -w 数据、请求 URL。只说“用户反馈慢”，厂商很难定位到具体节点。

DDoS 清洗、WAF、防盗链也可能引入额外耗时

CDN 前面如果叠了 DDoS 清洗、WAF、Bot 管控、鉴权、防盗链，延迟也可能增加。尤其是规则配置比较复杂时，每个请求都要经过多层判断，动态接口会更明显。

比如某站点启用了 URL 鉴权、Referer 防盗链、IP 信誉检测、JS Challenge。静态图片访问还好，接口请求 TTFB 却从 150ms 变成 700ms。排查后发现 Bot 防护对移动端 WebView 误判，部分请求被挑战流程拖慢。关闭对应规则后恢复正常。

安全功能不是不能开，而是要看业务类型。游戏登录接口、支付回调、API 网关、图片下载站，对延迟的敏感度完全不同。高防场景下更要关注清洗中心位置和回源线路，不然攻击没来时就已经比普通线路慢一截。

如何判断慢在用户侧、CDN侧还是回源侧

现场排障可以按时间拆分，不要靠感觉。curl -w 输出比较直接：

DNS 解析慢：time_namelookup 高，比如超过 100ms，重点看 Local DNS、DoH、域名解析链路。

TCP 连接慢：time_connect 高，重点看用户到 CDN 节点网络、路由绕路、丢包。

TLS 慢：time_appconnect 高，重点看 HTTPS 配置、证书链、TLS 协商、OCSP。

首包慢：time_starttransfer 高，但 connect 和 TLS 不高，重点看 CDN 缓存命中、节点处理、回源耗时、源站应用。

总耗时慢但首包不慢：重点看下载带宽、限速策略、大文件分片、Range 请求、节点出口拥塞。

源站日志也要配合看。如果 CDN 侧显示请求总耗时 1200ms，源站 access log 里 request_time 只有 80ms，并且 upstream_response_time 也很低，说明慢大概率不在应用处理。再看源站日志中的请求到达时间，如果用户发起请求后很久源站才收到，那就是 CDN 到源站或 CDN 内部链路耗时。

不要忽略 DNS TTL 和灰度调度

CDN 厂商调整节点后，不是所有用户都会立刻生效。DNS TTL、Local DNS 缓存、浏览器缓存、企业 DNS 缓存都会让旧节点继续存在一段时间。看起来像“已经切了节点怎么还有人慢”，其实是部分用户还在访问旧解析。

有些 CDN 还有灰度调度策略，同一个地区同一个运营商，不同用户可能被分到不同节点。这个设计本身没问题，用来做负载均衡和容灾，但排障时会增加复杂度。用户 A 正常不代表用户 B 一定正常，必须采集用户 B 的实际解析结果和访问链路。

这里有个小技巧：让用户访问一个专门的诊断 URL，返回客户端 IP、CDN 节点标识、X-Cache、请求时间、回源状态。比让用户截图 ping 结果靠谱得多。很多线上问题拖很久，就是因为缺少这些基础信息。

源站选择不合适，CDN 只能缓解，不能完全抹平

CDN 对静态资源效果明显，对动态请求效果有限。如果业务大量动态回源，源站位置和线路质量会变成关键因素。比如国内用户访问海外源站，CDN 只能优化接入和部分缓存，真正回源时还是要走跨境链路。

台湾大带宽、香港 CN2、韩国回国优化线路，适合的场景并不一样。台湾大宽带适合大流量、宽带峰值需求高的业务，但如果明确要求大陆访问稳定，就要注意“不保证大陆网络访问”这类产品说明。香港 CN2 更适合企业站、SEO 站群、对大陆访问质量要求更高的站点。韩国-G 型带傲盾防火墙和回国优化，更偏向需要防护和稳定线路的业务。

选择源站时别只看 CPU、内存、硬盘。CDN 场景下更要看机房出口、回源线路、峰值带宽、是否支持 IPv6、是否容易被 DDoS 打穿、是否方便做多源回源。源站线路差，缓存命中时看不出来，一旦 CDN MISS 或动态请求增加，问题会马上暴露。

工单里应该带什么信息

给 CDN 厂商或服务器厂商提工单时，信息越完整，定位越快。不要只写“访问慢”。比较有用的信息包括：访问域名、具体 URL、用户公网 IP、用户地区和运营商、访问时间点、解析到的 CDN IP、curl -w 结果、mtr 到 CDN IP、响应头、是否 HIT、源站日志对应记录。

如果怀疑回源慢，还要提供源站 IP、源站所在机房、源站 access log 时间、CDN 回源日志截图或数据。跨境业务最好补充源站线路类型，比如普通 BGP、CN2、GIA、国际精品线路。很多时候厂商看到这些信息，才能判断是节点异常、调度异常、回源链路拥塞，还是源站侧配置问题。

一个排查顺序更贴近现场

先看用户解析到了哪个 CDN IP，再看这个 IP 是否符合用户地区和运营商。解析不对，先处理调度和 DNS。

解析看起来合理，再测用户到 CDN IP 的 mtr。丢包、绕路、延迟高，就按网络链路问题处理。

用户到 CDN 节点正常，再看 curl 时间拆分。TLS 慢查 HTTPS，首包慢查缓存和回源，总下载慢查带宽和限速。

缓存 MISS 多，就查 Cache-Control、Cookie、Set-Cookie、Vary、URL 参数、Range 请求、CDN 缓存规则优先级。

缓存 HIT 仍然慢，就按节点负载、节点出口、局部故障找 CDN 厂商核查。

回源慢，就把 CDN 回源耗时和源站 request_time 对齐。源站处理快但 CDN 回源慢，重点看回源线路、跨运营商、跨境链路、回源协议和连接复用。

如果业务长期依赖海外源站回源，源站线路要提前选好，别等 CDN 上线后再用排障补设计缺口。香港 CN2、韩国回国优化、高防线路、大带宽线路各有适用场景，选错了后面会反复在 TTFB、MISS 回源、跨网抖动上花时间。