引言

CDN开通了，域名接了，加速也生效了——但监控面板上的缓存命中率只有60%，甚至更低。这意味着每10次请求中，有4次以上需要回源获取内容，CDN的加速效果被大幅稀释，源站带宽和计算资源被白白消耗。很多人遇到这种情况，第一反应是"CDN不行"，第二反应是"加带宽"。但真相往往藏在一个被严重忽视的地方——源站返回的HTTP响应头。据天翼云CDN团队的技术统计，超过七成的缓存命中率问题并非CDN节点故障或网络拥塞，而是源站响应头配置失当导致CDN节点"不敢缓存"或"缓存了但很快过期"。响应头是源站与CDN节点之间的"对话协议"，协议对了，缓存命中率轻松上95%；协议错了，再强的CDN也只是一个昂贵的中转站。本文将从响应头的底层逻辑出发，系统拆解哪些头在控制缓存、哪些头在破坏缓存，并给出一套可直接执行的优化方案与命中率分析方法，让你的CDN真正"存得住、命中得了"。

一、缓存命中率低的三大根因：不是CDN的问题，是你的响应头在"拆台"

在优化之前，必须先定位问题出在哪里。缓存命中率低的根因通常有三类，而这三类几乎都与源站响应头直接相关。

根因一：源站明确告诉CDN"不要缓存"

这是最直接也最常见的杀手。当源站返回的响应头中包含Cache-Control: no-cache或Cache-Control: no-store时，CDN节点会严格遵守源站指令，不缓存任何内容。每一次请求都回源，命中率直接归零。

更隐蔽的情况是Cache-Control: private。这个指令的本意是"只允许浏览器缓存，不允许中间代理缓存"，但部分CDN节点会将其解读为"不可缓存"，导致公网CDN节点不缓存该资源，只有终端浏览器本地缓存生效。对于多用户共享的公共资源（如产品图片、JS文件），这几乎等于没有缓存。

根因二：源站没说能缓存多久，CDN只能"猜"

当响应头中完全没有Cache-Control、Expires、ETag等缓存相关字段时，CDN节点会使用一套默认的启发式缓存策略——通常是根据Last-Modified时间计算一个经验值，默认缓存时间可能只有几分钟甚至几秒钟。

这意味着，一张今天上传的产品图，CDN节点可能只缓存了60秒就丢弃了。下一个用户访问时，又要回源。这种"无头缓存"策略在高并发场景下会导致回源率居高不下，源站压力巨大。

根因三：缓存了，但因为Vary头导致"命中却不敢用"

Vary响应头的作用是告诉CDN节点："同一个URL，如果请求头中的某些字段不同，返回的内容可能不同，请分别缓存。"

最典型的场景是Vary: Accept-Encoding。当源站同时支持Gzip和非Gzip两种编码时，如果没配置好Vary头，CDN可能会把Gzip版本缓存后返回给不支持Gzip的客户端，导致内容乱码。为了避免这种风险，部分CDN节点会选择"宁可不缓存，也不冒险"——尤其当Vary头包含多个字段时，缓存的分裂度会指数级上升，命中率断崖式下跌。

二、七个关键响应头：逐个拆解，逐个优化

2.1 Cache-Control：缓存策略的"总指挥"

Cache-Control是优先级最高的缓存指令，天翼云CDN默认遵循源站的Cache-Control策略。以下是核心指令的含义与推荐配置：

最优实践：对于天翼云CDN加速的静态资源，推荐配置Cache-Control: public, max-age=31536000（即1年）。如果资源会定期更新，可将max-age设为86400（1天）或3600（1小时），配合URL带版本号的方式实现缓存更新。

2.2 Expires：后备缓存指令

当Cache-Control缺失时，CDN会回退到Expires头来判断缓存时长。Expires的值是一个绝对时间（如Expires: Thu, 01 Dec 2025 16:00:00 GMT），CDN节点会用当前时间与之对比，未过期则继续使用缓存。

注意：Expires受限于客户端和CDN节点的时钟同步精度。如果服务器时钟偏差超过几分钟，可能导致缓存提前失效或过期后仍被使用。因此，Expires应作为Cache-Control的后备，而非主策略。

2.3 ETag：缓存验证的"指纹"

ETag是源站为每个资源生成的唯一标识（通常基于文件内容的哈希值）。当CDN节点缓存的资源即将过期时，会向源站发起条件请求，携带If-None-Match头，值为缓存中的ETag。源站对比后，如果内容未变，返回304 Not Modified，CDN继续使用缓存；如果内容已变，返回200 OK并携带新内容。

优化建议：确保源站为所有静态资源生成ETag，且ETag基于文件内容而非修改时间。天翼云CDN支持基于ETag的强缓存验证，开启后可大幅减少回源流量。某电商平台开启ETag验证后，回源带宽降低了35%，缓存命中率从78%提升至94%。

2.4 Last-Modified：ETag的"简化版"

Last-Modified记录资源的最后修改时间。CDN节点在缓存过期后会携带If-Modified-Since头向源站验证，源站对比后决定返回304还是200。

与ETag相比，Last-Modified的精度较低——如果文件内容变了但修改时间没变（如从FTP上传覆盖），CDN会继续使用旧缓存。因此，建议同时配置ETag和Last-Modified，CDN优先使用ETag验证，ETag缺失时回退到Last-Modified。

2.5 Vary：缓存分裂的"罪魁祸首"

Vary头控制的是"同一个URL能产生多少份缓存"。Vary: Accept-Encoding意味着Gzip和非Gzip各存一份；Vary: User-Agent意味着PC端和移动端各存一份；Vary: Accept-Encoding, User-Agent意味着PC-Gzip、PC-非Gzip、移动-Gzip、移动-非Gzip共存四份。

分裂度计算：如果Vary包含N个字段，每个字段有M种取值，理论缓存分裂数为M的N次方。当分裂度过高时，每个变体的命中率都会被稀释，整体命中率断崖式下跌。

优化建议：尽量减少Vary头中的字段数量。对于Accept-Encoding，天翼云CDN支持智能处理，可在控制台开启"忽略Vary: Accept-Encoding"功能，由CDN节点统一返回Gzip版本，避免缓存分裂。对于User-Agent，建议通过响应式图片方案替代，而非依赖Vary头做缓存分裂。

2.6 Pragma：HTTP/1.0时代的"遗留指令"

Pragma: no-cache是HTTP/1.0时代的缓存控制指令，功能等同于Cache-Control: no-cache。虽然现代浏览器和CDN节点主要看Cache-Control，但部分老旧设备仍会遵循Pragma指令。如果你的业务有老设备用户，务必同时清理Pragma头。

2.7 Age：CDN节点的"自述年龄"

Age头记录的是资源在CDN节点中已经缓存了多少秒。这个头由CDN节点自动添加，用户不可修改。但在分析缓存命中率时，Age头是判断"内容是否新鲜"的关键依据——如果Age接近max-age，说明缓存即将过期；如果Age远小于max-age，说明缓存还很新鲜。

三、缓存命中分析：四步定位命中率低的真因

优化不能盲目，必须先用数据定位问题。天翼云CDN控制台提供了完整的缓存分析能力，按以下四步操作：

第一步：看整体命中率。 进入CDN控制台的域名管理页面，查看缓存命中率指标。如果低于85%，说明存在明显的缓存失效问题。

第二步：看命中率趋势。 对比近7天的命中率曲线。如果命中率突然下降，说明近期有响应头变更或源站内容更新；如果命中率持续走低，说明缓存策略本身有问题。

第三步：看回源原因分布。 天翼云CDN提供回源原因统计，包括"源站未设置缓存头""源站设置no-cache""缓存过期回源""Vary命中"等分类。如果"源站未设置缓存头"占比最高，说明问题出在响应头缺失；如果"Vary命中"占比最高，说明缓存分裂是主因。

第四步：看具体URL的缓存状态。 抽取命中率最低的Top 20 URL，逐一检查其响应头配置。重点关注Cache-Control、Vary、ETag三个字段，90%的问题都藏在这里。

四、源站响应头优化清单：照着改，命中率提升20%

写在最后

缓存命中率不是一个"玄学指标"——它有原因、有工具、有方法。响应头是源站与CDN之间的契约，契约写对了，CDN节点就敢缓存、愿意缓存、缓存得久；契约写错了，CDN节点宁可回源也不敢冒险。从今天起，打开你的CDN控制台，看看回源原因分布，抽20条低命中率的URL检查响应头，对照优化清单逐项整改。这三个动作的答案，决定了你的CDN是在"加速"还是在"搬运"。真正的高命中率，从来不是CDN节点堆出来的，而是每一条响应头都写对了的结果。