先把当时的情况摆出来。同一篇文章在源站 curl 测 TTFB 是 120ms，走 CDN 在广东节点测到 800ms，回源日志显示每次都要重新建连，缓存命中率不到 40%。
排查方向其实有限，先把可能性排一排。回源没有开长连接，每次请求都重新握手。也可能是边缘到源站的线路绕路，跨运营商回源。
另外，缓存键里带了客户端 IP 的哈希，命中率被人为拉低。
第一件事是分别测源站与边缘的耗时
curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} ttfb:%{time_starttransfer}\n" https://www.example.com/post/1再往下开启回源长连接
upstream keepalive 32; proxy_http_version 1.1; proxy_set_header Connection "";简化缓存键
proxy_cache_key "$scheme$host$request_uri";我习惯把每一步的执行时间和结果记在一边，后面复盘省事。
改之前我把相关日志按时间截了一段存着，事后对时间线用得上。
别只看报错消失，验证要多做一步。边缘 TTFB 降到 200ms 以内，缓存命中率升到 80% 以上，回源日志里新建连接数下降一个量级。
提醒一点。边缘慢不一定是源站慢，先分段量 DNS、连接、首字节三段耗时，再决定改哪一层。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。