CDN 缓存策略怎么配?缓存规则、回源、刷新与预热全解析
作者:备案源头内容团队内容审核:备案源头内容团队更新于 2026年7月14日
很多站长接了 CDN 却发现两类问题:要么"改了内容用户还看到旧的",要么"命中率很低、CDN 形同虚设"。这都是缓存策略没配好。接入 CDN(见 备案网站怎么接入 CDN)只是第一步,真正让 CDN 又快又不出错,靠的是精细的缓存规则。本文系统讲清。
缓存的基本原理
CDN 在全国节点缓存你的资源副本,用户就近取,减轻源站压力、加快访问。核心概念:
| 概念 | 含义 |
|---|---|
| 缓存键(Cache Key) | CDN 用什么区分"同一个资源"(URL、部分参数、Host 等) |
| TTL | 缓存有效期,过期后回源重新拉取 |
| 命中(HIT)/ 未命中(MISS) | 节点有无该资源副本 |
| 回源 | 缓存未命中或过期时,节点去源站取内容 |
按内容类型设 TTL:最关键的一步
不同资源该用不同缓存时长,一刀切是大多数问题的根源:
| 资源类型 | 建议缓存 | 原因 |
|---|---|---|
| 带指纹的静态资源(app.a1b2.js) | 长缓存(如 1 年) | 文件名变了才更新,可放心长存 |
| 图片 / 字体 | 较长(如 30 天) | 变动少 |
| HTML 页面 | 短缓存或不缓存 | 内容会更新,缓存久了用户看到旧页 |
| 接口 / 动态数据 | 不缓存 | 实时性要求高 |
"改了内容不生效"几乎都是 HTML 设了长缓存。给 HTML 设短 TTL(或不缓存),给带指纹的静态资源设长 TTL,是既快又不出错的黄金组合。这也直接影响 网站访问慢怎么优化 的效果。
缓存键:别让参数把命中率打穿
如果 CDN 把每个带不同 query 参数的 URL 都当成不同资源缓存,命中率会暴跌。常见做法:
- 对静态资源忽略无关参数(如营销追踪参数 utm_*),只按路径缓存;
- 对确实影响内容的参数(如分页 page)才纳入缓存键;
- 注意别把用户身份相关的 Cookie 纳入缓存键,否则要么缓存穿透、要么串号(把 A 的页面缓存给 B)。
回源与源站保护
- 回源协议:建议回源用 HTTPS,避免节点到源站明文传输,证书见 网站 HTTPS 怎么配置;
- 回源 Host:确保源站按正确域名匹配站点;
- 缓存穿透防护:大量请求不存在的资源会全部回源打垮源站,可对 404 也做短暂缓存、或用 CDN 的防护规则;
- 回源收敛:热点资源过期瞬间大量并发回源(缓存击穿),可用 CDN 的回源合并 / 短暂 stale-while-revalidate 缓解。
刷新与预热:更新内容的正确姿势
更新了内容,不能干等缓存自然过期:
- 刷新(Purge):主动让 CDN 删除指定 URL 或目录的缓存,下次访问回源取新内容。改了页面/图片后刷新对应 URL。
- 预热(Preheat):主动让 CDN 节点提前拉取资源,避免大促/发布时第一批用户全部 MISS 回源。
典型发布流程:
部署新版本 → 刷新变更的 HTML/资源 URL → (可选)预热首页等热点页
→ 抽查 cf-cache-status / x-cache 头确认命中
用响应头 Cache-Control / Expires(源站设置)+ CDN 控制台规则共同决定缓存行为;排查时看响应里的缓存状态头(如 cf-cache-status: HIT/MISS)。
和备案的关系
用境内 CDN 节点要求域名已完成 ICP 备案(见 网站用了 CDN 还要备案吗);CDN 只是缓存加速层,不改变备案要求,也不替代源站——缓存未命中仍要回源,源站必须正常运行。
常见问题
Q:改了内容 CDN 还是旧的怎么办?
先刷新(Purge)对应 URL;根因通常是 HTML 设了长缓存,把 HTML 改成短 TTL、给带指纹静态资源设长 TTL 即可长期避免。
Q:CDN 命中率很低是什么原因?
多为缓存键把过多参数/Cookie 纳入,或大量资源设了不缓存。忽略无关参数、按类型合理设 TTL 可提升命中。
Q:怎么确认某个请求走了缓存?
看响应头的缓存状态(如 cf-cache-status、x-cache),HIT 表示命中节点缓存,MISS 表示回源。
资料来源
- 各 CDN 服务商缓存配置、刷新预热官方文档
- MDN HTTP 缓存(Cache-Control)文档:https://developer.mozilla.org/docs/Web/HTTP/Caching
以上为通用策略,具体规则以你使用的 CDN 厂商文档为准。
相关阅读
网站数据怎么备份与恢复?备份策略、异地备份与恢复演练
服务器故障、误删、被攻击、迁移出错,任何一种都可能让网站数据丢失。备份不是"有就行",而是要能在需要时真正恢复回来。本文讲清网站该备份什么、怎么备、多久备一次,以及恢复怎么做。 备份什么 | 对象 | 说明 | |---|---| | 数据库 | 网站核心数据(文章、订单、用户等),优先级最高 | | 站点文件 | …
网站定时任务与运维自动化怎么做?自动备份、证书续期与巡检
证书忘了续、备份忘了做、日志忘了清——运维事故很多不是不会做,而是"忘了做"。把重复的运维动作交给定时任务自动执行,是最省心也最可靠的做法。本文讲清哪些该自动化、定时任务怎么用,以及自动任务本身也要监控。 哪些运维适合自动化 | 任务 | 自动化收益 | |---|---| | 数据备份 | 定时全量/增量,避免漏备…
网站数据库运维怎么做?选型、性能优化、主从与备份全解析
对大多数网站,数据库是最核心、也最难重建的资产:程序挂了能重启,数据库数据丢了或被拖慢,整站跟着崩。数据库运维不是"装完能用就行",而要在选型、性能、可靠性、安全四条线上持续投入。本文系统梳理网站数据库运维的关键点。 选型:关系型还是其它 大多数网站用关系型数据库(MySQL/MariaDB、PostgreSQL)就…
网站打不开怎么排查?从解析、端口到备案的运维排查清单
网站突然打不开,原因可能在任何一层:域名没解析、端口没放行、服务挂了、证书过期、甚至掉备案或被墙。乱试一通只会浪费时间。本文给一份从外到内、分层排查的运维清单,按顺序走一遍就能快速定位。 排查总原则:分层,从外到内 按"域名解析 → 网络与端口 → 服务器与 Web 服务 → HTTPS 证书 → 备案与被墙"的顺序…
开发、测试、生产环境怎么分离?配置管理与发布流程
直接在生产服务器上改代码、连生产数据库调试,是运维事故的高发来源。把开发、测试、生产环境分开,让改动先在安全的地方验证,是稳定运维的基础。本文讲清三套环境怎么分、配置怎么管、怎么一步步发布到线上。 三套环境各干什么 | 环境 | 用途 | 数据 | |---|---|---| | 开发(dev) | 写代码、本地调试…
网站错误页怎么做?404、50x 自定义页与优雅降级实操
用户访问到一个"Nginx 默认 502 白页"或浏览器原生 404,会直接流失;搜索引擎抓到大量返回 200 的"软 404"也会伤收录。错误页看似小事,做好了却能留住用户、保护 SEO。本文讲清怎么把错误页做对。 先分清常见错误码 | 状态码 | 含义 | 典型原因 | |---|---|---| | 404 |…
网站高可用架构怎么做?负载均衡、多节点与故障转移全解析
单台服务器承载的网站,只要这台机器宕机、升级重启或被打满,网站就整体不可用。当业务对可用性有要求时,就需要从"单点"走向"高可用(HA)架构"——通过冗余和自动故障转移,让任何单一组件失效都不至于让整站瘫痪。本文系统讲清高可用的核心组件与落地要点。 先理解:可用性和单点故障 可用性常用"几个 9"衡量:99.9%(全…
备案通过后网站怎么上线?域名解析、服务器绑定与部署实操
很多站长拿到 ICP 备案通过通知后,反而卡在"接下来怎么让网站真正打开"这一步。备案解决的是"能不能上线"的资质问题,真正上线还需要一套运维动作:把域名解析到服务器、在服务器上部署站点、绑定域名、配好 HTTPS,最后验证访问。本文按实操顺序梳理。 上线前提:备案与接入都已就绪 开始部署前先确认两件事:一是备案已通…