回源率才是 CDN 的成本黑洞

一个站接上 CDN，账单出来，经常出现一个让人困惑的对比：流量用的是套餐里的，回源费用却单独占了三四成。

这件事的原因不复杂：CDN 计费的是「边缘到用户」的流量，而「边缘到源站」的回源流量，多数厂商单独计费，而且单价往往更高。

先算清楚一件事：命中率多少

命中率有两种口径，经常被混用：

• 请求命中率 = 命中缓存的请求数 ÷ 总请求数
• 流量命中率 = 命中缓存的流量 ÷ 总流量

这两个数可以差很多。一个站可能有 90% 的请求命中（大量小图片），但只有 60% 的流量命中（少数大文件没缓存）。成本看的是流量命中率，因为钱按 GB 算。

所以「我们命中率 95%」这句话，要先问是哪个口径。

回源的几种典型成因

我把见到过的原因按出现频率排一下：

1. 缓存键（Cache Key）设计不对

默认的缓存键通常是「完整 URL」。这意味着：

• ?utm_source=xxx 这种营销参数，会让同一个页面变成 N 个不同的缓存对象
• 时间戳参数（?_t=1699999999）会让缓存永久不命中
• 大小写、末尾斜杠不一致，也会被当成不同资源

处理办法：在 CDN 配置里设置「忽略指定 query 参数」，或者用「参数排序后取部分」作为缓存键。

2. Cookie 导致不缓存

很多 CDN 默认「带 Cookie 的请求不回源缓存」。而现实中，统计脚本、埋点、A/B 测试都会给页面种 Cookie。结果就是 HTML 全部不缓存，每次都回源。

处理办法：对静态资源路径配置「忽略 Cookie」，对 HTML 用「忽略除指定 Cookie 外的全部 Cookie」。

3. TTL 设得太短

Cache-Control: max-age=60，意味着每分钟回源一次。一个日均 10 万 PV 的页面，一天回源 1440 次——看起来不多，但如果每次回源拉的是 200KB 的 HTML，就是 280MB/天的回源流量，还没算动态内容。

静态资源（JS/CSS/图片）应该用带 hash 的长缓存（max-age=31536000, immutable），HTML 用短缓存或不缓存。

4. 源站没开压缩

如果源站返回的是未压缩内容，CDN 回源拿到的也是未压缩的。一个 300KB 的 JS，gzip 后 90KB——回源流量直接差 3 倍。

5. 预热没做

大促、发布会、投放开始前不预热，第一波用户全部打回源站。轻则慢，重则源站被打挂。

一个真实的账

假设一个站：

• 月流量 30TB，边缘单价 0.15 元/GB
• 流量命中率 85%，回源 15%
• 回源单价 0.30 元/GB

项目	用量	费用
边缘流量	30TB = 30,720GB	4,608 元
回源流量	30TB × 15% ≈ 4,608GB	1,382 元
合计		5,990 元
回源占比		23%

如果命中率从 85% 提到 95%：

项目	用量	费用
边缘流量	30,720GB	4,608 元
回源流量	3,072GB	922 元
合计		5,530 元

省 460 元/月，约 8%。不算爆炸性，但如果同时把单价谈到 0.12，或者把回源单价压下来，叠加效果就明显了。

真正夸张的情况是命中率低于 60% 的站——那时候回源费用可以超过边缘费用本身。

但别走极端

「回源率越低越好」这句话是错的。有些内容不该缓存：

• 用户的个人页面（缓存了就是事故）
• 实时性要求高的数据（库存、价格、行情）
• 登录态相关的内容
• 支付、订单类接口

把这些强行缓存，省下的钱远远不够赔一次数据错乱。

正确的目标不是「命中率最高」，而是**「该缓存的全缓存，不该缓存的一律不缓存」**。中间地带最费钱——既缓存又频繁失效的那种。

我的排查顺序

遇到 CDN 账单异常，我按这个顺序看：

1. 分离回源流量与边缘流量 —— 先看占比，不要看总额
2. 拉状态码分布 —— 大量 200 但没命中，说明缓存键或 TTL 有问题；大量 206/304，说明配置了分段或协商缓存
3. 看 MISS 原因分类 —— 多数 CDN 控制台能给出「未配置缓存」「已过期」「缓存键不同」的分布，这一项最直接
4. 抽查 Top URL —— 按流量排序前 50 个 URL，逐个看缓存策略
5. 检查 Cookie 与 query 参数 —— 这两个是命中率杀手
6. 最后才谈价格 —— 配置没优化之前谈单价，等于给漏水的桶换个更便宜的桶

一句话

CDN 的成本优化，八成在配置，两成在商务。

配置对了，同样的单价能省 20-30%；配置不对，谈下来 10% 的折扣也被漏掉了。