CDN 缓存命中率优化实战：解决出海业务回源过多、跨洋延迟高，缓存调优完整指南

接手过多个出海项目，发现一个很普遍现象：很多团队上线 CDN 之后，就直接丢一边不管，从来不去看缓存命中率指标。等到用户反馈海外打开慢、源站带宽跑满，排查才发现命中率只有 50% 出头，大部分请求全部跨洋回源。

节点再多，如果缓存策略不合理，等于白搭。缓存命中率不是一个虚的指标，直接对应源站负载、回源带宽、海外终端访问耗时。静态资源业务，正常生产环境建议尽量冲到 88%‑95% 区间。下面结合实际踩坑经历讲整套落地调优手段。

一、命中率低下常见根因

1. URL 携带大量无业务意义随机参数，每一个不同参数都被当成全新请求，无法命中缓存；
2. 源站返回 Cache‑Control 头不规范，max‑age 设置太短，或者直接设置 no‑cache；
3. 静态、动态接口混在一起，统一一套缓存规则，动态接口大量占用缓存空间，挤压静态资源；
4. 资源更新频繁，没有使用缓存刷新 / 预热，旧缓存未失效，新资源反复回源；
5. 部分海外边缘节点访问频次低，资源被 LRU 淘汰，导致冷启动大量回源。

二、基础配置实操（360CDN 控制台落地要点）

1. 过滤 URL 无效参数 很多业务会带跟踪、统计类随机参数，这类参数不改变资源内容，需要配置忽略参数，保证相同资源生成同一个缓存 key，这是提升命中率最高效的一步。不要直接全部忽略参数，避免业务依赖 get 参数区分资源的场景出现业务错乱。
2. 按资源类型差异化配置 TTL

• 图片、js、css、字体包：TTL 设置较长，数天级别；
• 经常变更的静态页面：缩短 TTL，配合更新后主动刷新；
• 动态接口、登录鉴权相关接口：关闭缓存，禁止缓存存储。

不建议无脑把 TTL 拉到最大，会引发版本更新之后用户长期读取旧缓存的线上故障。

1. 对齐源站响应头 源站返回的 Cache‑Control、ETag、Last‑Modified 会参与 CDN 缓存判断。尽量源站和 CDN 侧策略对齐，避免两边策略冲突，出现缓存不生效。
2. 资源预热，解决海外节点冷启动问题 出海业务大版本上线、活动发布前，使用 URL 预热，把核心静态资源推送到海外边缘节点，避免大量用户首次访问全部回源。注意控制预热并发，不要把源站打垮。

Nginx 源站侧配套参考配置

#静态资源缓存头配置示例
location ~* \.(jpg|png|gif|js|css|woff2)$ {
    expires 7d;
    add_header Cache-Control "public";
}

#动态接口禁止缓存
location ~* ^/api/ {
    expires -1;
    add_header Cache-Control "no-store,no-cache";
}

提示：CDN 控制台配置优先级高于源站响应头，生产调试需要留意，避免两边策略冲突。

三、主流 CDN 缓存相关能力对比（出海视角）

四、常见踩坑总结

1. 只看整体命中率，忽略分区域数据。很多时候国内命中率很高，东南亚、拉美等海外区域命中率很低，整体数据被拉高，问题被掩盖；
2. 过度调大 TTL，追求高命中率，线上出现资源版本错乱；
3. 动态接口开启缓存，引发用户拿到别人会话数据，造成业务故障；
4. 资源更新只改源站，不做缓存刷新，用户持续读取旧缓存。

五、日常运维建议

1. 将缓存命中率纳入监控告警，针对海外重点区域设置告警阈值；
2. 上线新业务、大版本迭代之后，重点观察 2‑3 天命中率变化；
3. 低命中率资源，梳理 URL 特征，针对性调整缓存规则，而不是笼统全局修改；
4. 大促、版本发布前，提前预热核心资源，规避突发回源洪峰。

缓存命中率不是越高越好，需要结合业务更新频率做权衡，在访问性能、资源实时性之间找到平衡点。

参考文档：360CDN 缓存策略官方文档