CDN缓存配完，回源流量掉了一大截

回源流量掉下来，多数时候不是你配错了，而是缓存终于开始干活了。源站的带宽曲线一平，CPU 负载跟着往下走，看的人心里确实舒服——不过先别急着庆祝，得弄清楚掉的是哪一部分流量。同一条向下的曲线，有可能是规则正常生效，也可能是你把不该拦的东西拦在门外了，用户那头已经开始骂，你还不一定知道。

CDN缓存命中率上去了，回源自然就少

道理不复杂。用户请求打到离他最近的边缘节点，节点上有这份副本就直接返回，没有才回源站取。命中率越高，回源的次数越少，源站的带宽、连接数、数据库压力全跟着降。这也是大家上 CDN 的初衷，不是为了让源站清闲，是为了让用户少等。所以那条向下的回源曲线，本来就是个积极信号，别把它当成故障指标看。

反过来才该着急：规则配了、缓存也开了，回源流量一点没降。常见原因是缓存键带了一堆没用的参数，比如随机的 utm、时间戳，每来一次请求都被算成不同资源；或者源站返回的头里写着 no-cache、private，边缘节点根本不敢存。

掉得不对劲，先查这三处

第一种，缓存键没带查询参数。有人图省事把 query string 忽略掉，结果 /list?page=1 和 /list?page=10 在节点眼里成了同一份东西，用户翻页翻出一堆重复内容。第二种，整站目录一股脑缓存，把 /admin、/api 也一起收了，后台改完数据页面纹丝不动，运营还得跑来找你。第三种最要命，带 Set-Cookie 的响应被当成公共资源存了下来，A 用户的登录态让 B 用户拿到了，这已经不是流量问题，是事故。

TTL 设长了省流量，也省出了麻烦

TTL 拉长，回源次数肉眼可见地减少，账面上很好看。代价是内容更新滞后。运营改了首页 banner，截图发过来说线上没变，你手动刷一下才发现是缓存的旧副本。所以 TTL 最好按内容类型分开设：图片、字体、带版本号的 JS/CSS 可以设很长；HTML 首页、列表页短一点；接口类干脆不缓存。改版之前先做刷新预热，URL 刷新和目录刷新各家都有配额，用多少、多久生效，以控制台说明为准。

还有一层别忽略：浏览器本地缓存和边缘节点缓存是叠在一起的。你把 CDN 的 TTL 调短了，用户浏览器里那份旧文件照样还在，清不掉。带 hash 的静态资源好办，改版就换文件名；不带的就得靠响应头里的缓存指令控制。

哪些内容压根不该进 CDN缓存

登录后的个人中心、购物车、下单页、支付回调地址、后台路径、实时库存和价格，这些东西都不该进公共缓存。规则里用路径前缀排除，或者让源站直接返回 private / no-store。POST 请求默认不缓存，这个不用多说，但有些框架把查询也走 POST，容易被漏掉。判断标准其实一句话：这份内容给不同用户看，会不会不一样？会，就别缓存。

怎么验证这次是真生效

别只盯回源流量一条线。打开命中率曲线看趋势稳不稳，再挑几个不同地区的节点实际请求一下，看看响应头里的缓存状态字段。阿里云、腾讯云、Cloudflare 这些厂商的字段名都不一样，以各自官方文档为准，别拿一家的经验套另一家。有条件的话对比源站日志：回源请求的 URL 是不是你预期的那些，UA 里带的是不是节点标识，这些比曲线更直白。

命令行也能看个大概，curl -I 后跟你的资源地址，重点看 age、cache 状态这一类字段。另外提醒一句，缓存刷新之后不是全网立刻生效，不同节点回源的时间点不一样，你在一个节点测到新内容，不代表所有地方都更新了。

回源流量降了，账单怎么没动静

这里有个容易误解的地方。CDN 流量和回源流量，有的厂商合并计费，有的分开算；流量包有优先级和有效期，峰值带宽是按日峰值还是按 95 峰值，各家口径都不一样。你看见源站带宽掉了一半，账单只少了一点点，不一定是算错了，很可能计费项本来就不在一块儿。具体还是以服务商控制台的用量明细和官方计费说明为准，别自己拍脑袋。

上线后我一般盯这几样

命中率有没有稳住，别忽高忽低。回源请求的 URL 分布里，有没有冒出本不该回源的路径。缓存键是不是带上了必要的查询参数。排除名单里有没有登录态、接口、后台。TTL 是不是按内容类型分过。改版或上新以后有没有做刷新预热。最后对一遍用量明细和账单，看两边能不能对上。这七条照着走一遍，大部分坑当场就能发现。

说到底，回源流量掉下来这个现象本身不值得庆祝，值得确认。曲线往下、用户体验往上，那是配对了；曲线往下、客服工单往上，那就是缓存把问题盖住了，早晚还得翻出来。