又有人来问：CDN 接了两周，首页打开还是三秒多，是不是服务商不行。这类问题我们见得多，先别急着换厂商或者加钱升套餐——大部分「没变快」是配置层的毛病，跟节点质量关系不大。还有一个前提：别凭感觉调配置，先拿数据。
动手之前，先把这几个数拿到手
改缓存规则、加节点之前，先在本地跑几条命令，留一份基线记录。
- 直连源站：
curl -o /dev/null -s -w "connect:%{time_connect} ttfb:%{time_starttransfer} total:%{time_total}n" http://源站IP/。地址写 IP，绕过 DNS 和 CDN，这个数字是后面所有对比的基准。 - 走 CDN 的同一路径：把地址换回域名再跑一次。两次 TTFB 的差值，就是 CDN 实际帮你省下的时间。
- 解析落在哪：
dig +short www.你的域名.com，再换公共 DNS 对比dig @223.5.5.5、dig @8.8.8.8。
下面这张表先填一遍，空着的格子就是接下来要查的方向。
| 指标 | 怎么拿 | 什么情况算异常 |
|---|---|---|
| 缓存命中率 | 控制台曲线，或响应头 X-Cache / Age | 静态资源长期低于 80%，先怀疑缓存规则 |
| 源站 TTFB | 直连 IP 的 time_starttransfer | 稳定高于 300ms，先修应用再看 CDN |
| DNS 解析结果 | dig +trace，或多地解析工具 | 返回源站 A 记录而不是 CNAME，等于没切 |
| TLS 握手耗时 | time_appconnect 减 time_connect | 跨境场景 300ms 以上，值得做协议优化 |
| 回源耗时 | CDN 控制台的回源监控 | 明显高于源站 TTFB，通常是链路绕路 |
按顺序排查这七个原因
一、缓存命中率低
先看这个。命中率低，等于请求照样打到源站，CDN 只当了个反向代理，省不下多少。
怎么确认：curl -sI https://你的域名/static/app.js | grep -iE "x-cache|age"，HIT 是命中，MISS 是回源。更准的做法是去源站 access_log 里数 CDN 回源 IP 的请求量，跟 CDN 侧统计的请求总量比一下。
命中率上不去，常见原因有这么几个：URL 后面挂了随机数或时间戳；缓存键里带了 Cookie 或 User-Agent；Cache-Control 只给了 60 秒；静态文件名不带 hash，一更新就整站回源。
二、缓存规则写错，或者写太宽
怎么确认：同一个 URL 用不同 UA、不同 Cookie 各请求一次，看返回的 Age 和内容是否一致；再看响应头里的 Cache-Control 有没有被 CDN 改写成 no-cache。
两种相反的错都常见。一种是源站已经写了 Cache-Control: max-age=31536000，后台却配了「不缓存 js/css」；另一种是图省事开全局缓存，把带登录态的接口响应也缓存了，用户刷出别人的数据——这就不是慢，是事故。稳妥做法是按目录分级：/static、/assets、/img 长缓存，HTML 短缓存或协商缓存，/api 不缓存。
三、动态请求没做分离
怎么确认：从访问日志按 URL 前缀统计请求占比，或者看浏览器 DevTools 的瀑布图。如果 TTFB 长的请求集中在 /api、/search 这类路径上，缓存怎么调都没用，因为它们本来就不该被缓存。
动态部分的加速不靠缓存，靠回源链路：节点到源站走专线还是公网、有没有复用长连接、TCP 慢启动有没有被反复触发。这跟静态缓存优化是两条腿，别混在一起调。
四、回源慢
怎么确认：curl -w "@fmt.txt" -o /dev/null -s http://源站IP/big.jpg，看 time_connect 和 time_starttransfer；再在控制台看回源耗时和回源失败率。
回源慢经常不是源站慢，是路慢。节点在东南亚，源站在国内单线机房，回源绕一圈 RTT 就 200ms 起步。要么把源站挪到网络质量更好的机房，要么选回源线路做过优化的 全球 CDN 加速 服务。回源带宽也得看，源站出口打满的时候，节点等的是你的带宽，不是它自己的。
五、DNS 没切干净
怎么确认：dig +trace www.你的域名.com 看 CNAME 链是否指向 CDN 域名；如果直接返回源站 A 记录，说明压根没生效。多地解析用第三方工具测，别只在自己电脑上 ping。
坑点有三个：切换前 TTL 设成 86400，改完得等一天；部分运营商 LocalDNS 缓存顽固；同一条记录里 A 和 CNAME 并存，解析结果随机。切换前把 TTL 降到 300 秒，能省很多事。
六、TLS 握手开销吃掉了收益
怎么确认：curl -w "connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer}n" -o /dev/null -s https://你的域名/。time_appconnect 减去 time_connect 大致就是握手耗时，跨境访问时这段经常有 200-400ms。
能做的：开 TLS 1.3、开会话复用、OCSP stapling 别让它自己出去查、证书链别塞四五个中间证书、开 HTTP/2 或 HTTP/3。这些不用换服务商，后台勾一勾就有差别。
七、源站本身就慢
怎么确认：直连源站 IP 反复跑几次，curl -o /dev/null -s -w "%{time_starttransfer}n" http://源站IP/，或者用 ab / wrk 打一轮。如果源站 TTFB 稳定在 500ms 以上，CDN 帮不了你——它只能优化传输和缓存，没法替你跑 SQL。
顺手要看的还有数据库慢查询、PHP-FPM 排队、磁盘 IO，以及源站是不是跑在一台小带宽云主机上。这些不解决，节点铺再多，也只是把慢内容更快地送到用户面前。
顺序别乱，每改一项就回测一次
这七条里，一、二、三是配置问题，改起来几分钟；四、五、六是链路问题，要动 DNS 和服务端；七是应用问题，工作量通常大。建议按顺序走，每改一项重新跑一遍基线命令，把数字记下来。没有对比数据的「优化」，本质上是在猜。
我们自己的习惯是做一张表，把直连 TTFB、CDN TTFB、命中率、回源耗时四项按周记录，改动前后差多少一目了然，也能判断花出去的钱值不值。想看 CDN 和直连在不同场景下差多少，可以参考 CDN 加速与直连的实测对比。如果源站在国内、用户散在东南亚或欧美，路由和节点选择的影响会被放大，跨境电商 CDN 方案 里那套就近接入的思路更适用。
下一步很简单：今天就跑一遍上面那几条 curl，把五个指标填进表里，再决定动哪一项。要是某项数字拿不准该算正常还是异常，把输出贴过来发到 bd@319keji.com，或者走 联系合作 页面，我们一起看瓶颈落在哪一层。