华为云 CDN 加速后静态资源命中率骤降的一次完整排查：缓存键、URL 参数与回源带宽三线定位

华为云 CDN 加速后静态资源命中率骤降的一次完整排查：缓存键、URL 参数与回源带宽三线定位

一、问题现场

我们给一个前端站点接了华为云 CDN，主要加速 /static/ 下的 js、css 和图片，日常缓存命中率稳定在 96% 上下，回源带宽不到 20 Mbps。上周一发版之后，命中率一夜掉到 71%，回源带宽峰值冲到 180 Mbps，源站 ECS 的网卡和 Nginx 连接数都开始告警，个别图片接口还出现了 504。前端同学第一反应是「CDN 挂了」，但监控看边缘节点状态码都正常，5xx 没有抬升，说明请求确实到了源站而不是节点本身出错。

这类问题最容易被误判成「回源超时」，其实命中率下降和源站压力上升是同一件事的两面：大量本该在边缘被接住的请求穿透回源了。所以第一步不是调超时，而是找出「哪些请求突然变成了 Miss」。

二、先把口径对齐：命中率是怎么算的

在 CDN 控制台的「统计分析 → 命中率」里，我先按域名和时间粒度拉了发版前后各 24 小时的曲线，确认掉点是发版后 20 分钟内开始的，不是统计延迟。然后做了一件很关键的事：把「请求数」和「命中率」放在同一张图里看。命中率从 96% 掉到 71%，但总请求数只涨了约 8%，说明不是流量洪峰稀释了命中率，而是有一批固定请求从 Hit 变成了 Miss。

接下来用「热门 URL」和「回源流量 TOP」两张报表做交叉对比，发现异常集中在几类带查询串的图片地址上，形式类似 /static/banner.png?v=20261110 和 /static/avatar/12345.png?x-oss-process=image/resize,w_200。发版时前端把静态资源版本号从文件路径改成了查询参数，图片组件又开始拼接缩放参数，两类 URL 的请求量加起来差不多正好能解释那 25 个百分点的缺口。

三、第一轮排查：缓存规则与 URL 参数

华为云 CDN 的缓存规则是按优先级匹配的，控制台里我们原本只配了一条 /static/ 下所有文件缓存 30 天。这时候我犯了一个想当然的错误：以为只要路径命中规则，带不带参数都一样缓存。实际上 CDN 的缓存键默认包含完整查询串，也就是说 banner.png?v=1 和 banner.png?v=2 在边缘是两个完全不同的对象，每个新版本号都会产生一次回源；更糟的是缩放参数在客户端有十几种组合，等于把一张图拆成了十几个缓存对象，命中率被摊薄得很厉害。

验证方法很直接：在控制台缓存配置页打开「忽略 URL 参数」，先只对 /static/ 这条规则生效，观察 15 分钟。命中率从 71% 回到 88%，但没有回到 96%，说明参数确实是主因之一，却不是全部。

四、第二轮排查：忽略参数不能一刀切

继续看回源 TOP，发现还有一批 /api/preview 开头的请求也进了回源统计。查了配置才发现，「忽略 URL 参数」如果开得太宽，会让那些靠参数区分内容的动态接口也被当成同一个对象缓存，这属于风险操作。于是我把策略收窄：只对图片后缀（png/jpg/webp）和静态资源后缀忽略参数，动态接口保持原样；同时把参数白名单化，只忽略 v、x-oss-process 这几个已知的无语义参数，而不是全部忽略。

这一步之后命中率到 92%。剩下的 4 个百分点来自另一个地方。

五、第三轮排查：源站响应头覆盖了 CDN 规则

抓了几条仍然 Miss 的请求，用 curl -I 直接看源站响应：

curl -I 

cache-control: no-cache, max-age=0

pragma: no-cache

发版时运维给源站 Nginx 加了一段通用的安全头，把 /static/ 也一起套上了 no-cache。CDN 在「缓存遵循源站」开启时会优先采信源站的 Cache-Control，控制台配的 30 天规则被直接覆盖，边缘拿到 no-cache 就不落盘，每次都回源确认。这个隐藏得很深，因为控制台显示规则一切正常，只有回源日志里的 MISS 和响应头能说明问题。

修法是把源站 location 分级：/static/ 单独给 Cache-Control: public, max-age=2592000，其余路径继续保留 no-cache；CDN 侧对静态规则关掉「遵循源站」或至少把源站优先级调低。

六、修复与验证

三处改动按「先边缘、后源站」的顺序上线：① 静态规则开启忽略参数并限定白名单；② 缓存键去掉无语义查询串；③ 源站 /static/ 恢复长缓存头。上线后 30 分钟，命中率回到 96.4%，回源带宽从 180 Mbps 回落到 18 Mbps，源站 504 归零。

验证我没有只看控制台曲线，而是用带随机参数的请求连打 20 次，确认第 2 次起全部返回 X-Cache: HIT；再分别带 v=1 / v=2 访问同一张图，确认命中同一个缓存对象；最后挑一个动态接口带不同参数请求，确认没有被误缓存。三件事都过了才敢说修完。

七、复盘：三条可以复用的检查项

第一，命中率下降先做「请求数 / 命中率 / 回源 TOP URL」三表交叉，定位到具体 URL 形态，不要一上来就调超时或扩容源站。第二，改静态资源版本号策略时，必须同步评估 CDN 缓存键，查询串和路径不是等价的；忽略参数要限定后缀和白名单，别全站一刀切。第三，控制台规则和源站响应头是两层配置，源站 Cache-Control 的优先级可能更高，排查时一定要 curl 源站而不是只看 CDN 侧配置。

另外留了个长期动作：把「命中率低于 90%」和「回源带宽环比涨 3 倍」做成 CES 告警，并在发版清单里加一条「静态资源 URL 形态变更需复核 CDN 缓存规则」。这次是发版引入的，下一次未必还会有人第一时间想到 CDN。