清洗生效后业务依旧卡顿，核心瓶颈多半在回源链路CDN把请求转给源站的那段路，才是拖慢响应的大头。先分清缓存没生效和回源慢是两回事，再用分段计时把每一跳的耗时拆开，基本就能锁定问题出在哪个环节。
缓存清洗了，业务还是慢，先别急着怪CDN
很多运维朋友遇到过这种场景：刷新了URL，清掉了缓存目录，甚至把整个CDN节点都预热了一遍，结果用户打开页面还是转圈。这锅不一定让CDN背，回源链路才是隐藏最深的一环。
清洗生效和业务变快是两码事
缓存清洗只能保证CDN节点上不再保留旧数据，下一次请求会回源站取新内容。这个过程本身，就是一笔不小的开销。 如果源站处理慢，或者源站和CDN节点之间的网络质量差,清洗后的第一次请求反而比命中缓存时更慢。
这种情况下，排查思路要立刻从“清洗有没有生效”切换到“回源链路顶不顶得住”，业内专家指出，相当一部分站点清洗后依然慢，问题出在回源超时或源站响应过慢，而不是CDN没干活。
缓存命中率高不等于回源没压力
有些站点的缓存命中率做到了90%以上，但回源请求的绝对数量依然庞大。剩下的那10%请求，往往是动态接口、登录态页面或者带参数的URL，这些内容本身就很难缓存。 每一次回源都是一次完整的TCP连接加HTTP请求，源站扛不住,业务就会整体卡顿。
【cdn回源慢怎么排查】逐跳分段，看耗时花在哪
排查回源链路的方法不复杂，核心思路是把整条请求路径拆成几段，逐段测量耗时，行业共识认为，回源链路的瓶颈无非出现在四个位置：DNS解析、CDN节点到源站的网络链路、源站接入层、源站应用层。
网站慢是CDN没生效还是回源慢，怎么确认
最简单的验证办法，是绕开CDN直接访问源站IP。把域名解析到源站，或者用测试机修改hosts文件，体验一下真实响应速度。
- 如果直连源站也很慢，问题大概率在源站自身,和CDN无关。
- 如果直连源站快，走CDN后就变慢,说明回源链路或CDN节点配置有问题。
- 如果直连时快时慢，多数是源站带宽或负载波动,需要观察持续一段时间。
用cURL把回源耗时拆开看
在源站或CDN节点上执行一条带计时参数的cURL命令,能把各阶段耗时直接打出来：
curl -o /dev/null -s -w 'DNS解析: %{time_namelookup}snTCP建连: %{time_connect}sn开始传输: %{time_starttransfer}sn总耗时: %{time_total}sn' https://你的域名/需要排查的路径
把返回结果和直连源站的耗时对比，差距越大，回源链路的问题越明显。如果TCP建连阶段就花掉几百毫秒，多半是CDN节点到源站的网络线路质量问题。
看CDN回源日志里的状态码和时间戳
CDN控制台一般都有“回源统计”或“回源日志”入口,重点看两个指标：
- 回源状态码分布：5xx比例高，源站不稳定；499或408多,源站处理超时。
- 回源平均耗时：如果持续高于200毫秒,对用户体验影响已经很大。
回源日志里还能看到具体是哪些URL在频繁回源。把回源次数最多的URL按耗时排序，优先优化Top10，效果比盲目调优整体配置好得多。
回源链路慢的常见原因，按优先级排查
锁定了慢的环节之后，还要找到根因，以下按出现频率排序,建议逐个排查。
源站带宽被打满，回源请求排队等
源站的上行带宽是回源速度的硬上限。带宽跑满时，CDN节点发过来的请求会在源站网络层排队，表现就是连接建立成功但迟迟收不到响应。
排查方法：登录源站服务器，用iftop或nload看实时流量，如果长期贴着带宽上限，先看是哪个进程占的流量。流量异常高一般是日志采集器、备份任务或数据库同步搞的鬼，把这些任务错峰调度，回源速度立刻回升。
CDN回源协议和源站不匹配
这种情况比较隐蔽。比如CDN回源配置的是HTTP/1.1，源站只支持HTTP/2，或者源站强制HTTPS跳转，回源请求就会被反复302重定向，白耗两到三倍的往返时间。
建议在CDN控制台里把回源协议、端口、Host头这三个参数逐一核对，源站是什么协议，回源就用什么协议,能少一层转发就少一层。
动态请求没法缓存，回源链路先天吃力
很多业务系统把登录状态、购物车、实时价格都放在URL参数或Cookie里，这些请求默认不缓存，每一次都要回源。这类请求占用的回源连接数很大，容易把连接池占满，导致其他回源请求排队等待。
处理思路有两步：
- 对纯静态资源（图片、CSS、JS）设置较长的缓存时间,降低整体回源频率。
- 动态接口单独走动态加速线路，或者把接口迁移到更靠近用户的边缘节点,缩短物理距离。
源站应用层的慢查询和CPU争抢
回源请求到了源站之后，还要过Web服务器、应用框架、数据库这三道关。常见问题有几个：数据库慢SQL拖垮接口响应；PHP-FPM或Java应用线程池被打满；Redis缓存雪崩回源到数据库。
排查顺序建议：先看源站的top命令，确认CPU和内存有没有异常；再看应用日志里的耗时分布，找到最慢的那类请求；最后开数据库慢查询日志,把执行时间超过1秒的SQL捞出来。
某次实际排查中，朋友遇到一个场景：CDN回源耗时稳定在2秒，直连源站只要300毫秒，中间差的900毫秒全耗在TCP连接复用上，原因就是CDN的“回源连接数上限”设置太低，节点上的请求需要等空闲连接，高峰期排队严重，调高上限后,回源耗时直接降到400毫秒以内。
回源链路质量差，跨国跨运营商尤其明显
源站在电信机房，CDN节点在联通网络，跨运营商互访的丢包和延迟比想象中的严重。如果源站是单线机房，建议接入BGP多线，或者在CDN控制台开启“回源链路优选”功能。
对于源站在海外的情况，回源慢就更常见了。国内访问速度可能受国际链路波动影响，稳妥的方案是在源站前面再加一层境外CDN或云厂商的全球加速服务。
优化回源链路的几条实用配置
解决回源慢，除了硬件和网络层面的调整,CDN控制台里还有几个参数值得仔细设置。
| 配置项 | 推荐做法 | 效果说明 |
|---|---|---|
| 回源超时时间 | 从默认10秒调整为5秒 | 防止个别慢请求长期占用回源连接 |
| 回源重试次数 | 1-3次 | 超时后自动重试，提升单次请求成功率 |
| 回源SNI | 开启并配置域名 | 避免源站因SNI不匹配拒绝连接 |
| Range回源 | 开启 | 大文件分片传输，减少源站带宽占用 |
| 回源跟随重定向 | 按需关闭 | 避免循环跳转拖慢回源 |
回源慢能解决吗，关键看源站稳不稳定
只要源站本身没有硬件瓶颈，回源慢通常都能通过配置调整解决。先把超时时间调短，把连接数上限调高，再处理慢查询和带宽争抢，回源耗时基本能降一半以上。 如果这些都做了还是没有改善，可以给CDN服务商提工单,让他们帮忙看节点到源站的实际路由。
问题与答案
清洗生效后业务仍慢，和回源链路有关系吗
清洗生效只是代表旧缓存被清掉，新请求需要回源取数据。如果清洗后慢，回源链路是第一个要怀疑的对象。 建议先用cURL对比直连源站和走CDN的耗时差距，再查看回源日志里的状态码和耗时分布,这种方式能在几分钟内定位问题。
怎么看源站响应时间数不数正常
源站响应时间和业务类型强相关。纯静态资源响应在100毫秒内算正常，动态接口受数据库和中间件影响，200到500毫秒都可以接受。 如果超过1秒，建议查一下应用日志里的慢请求和数据库的慢查询记录，nginx的$request_time变量可以直接在access log里记录每个请求的处理耗时,修改nginx配置后重载即可。