Hostease 专区实测讨论：CDN回源策略与缓存规则设计，动态内容站点的加速实践需要验证哪些指标

电商页面价格实时变、社区帖子列表不断更新——这类动态内容站点接入 CDN（内容分发网络）之后，最常被拿去论坛里问的问题就两个：命中率为什么死活上不去，以及回源请求为什么把源站打满。这两个问题其实是一体两面：缓存规则决定哪些请求根本不必回源，回源策略决定剩下的请求怎么走得更快更稳。这篇讨论用一个可以复制粘贴的流程，教你把两件事拆开逐项落地：该缓存的坚决缓存，必须回源的高效回源，每一步都配一条能直接跑的验证命令，跑完拿数据说话，不靠感觉。

先弄清楚：回源是什么，为什么它决定动态站点的速度

回源，指 CDN（内容分发网络）边缘节点在自己没有可用缓存（cache miss）时，向源站服务器取数据的过程。用户请求先落在离他最近的边缘节点：本地命中缓存就直接返回（cache hit），未命中才回源。命中越多，用户等待越接近节点的几毫秒；回源越多，源站 CPU、数据库连接和带宽（数据传输容量）压力越大。

命中情况不用猜，CDN 会写在响应头里。跑一条命令就能看到标记：

curl -sI https://example.com/style.css | grep -i cache

重点看 X-Cache 是 HIT 还是 MISS，以及 Age（内容已在节点上存放的秒数）。同一 URL 连续请求两次，先 MISS 后 HIT 说明链路正常；始终 MISS，多半是响应头禁用了缓存，或者缓存键配错。

对动态站点来说，真正的麻烦在于”不可缓存的内容占比高”。商品详情页的静态框架可以缓存，但价格、库存、购物车必须实时。如果规则把整页 HTML 都标成不缓存，每次访问都触发完整回源，CDN 就退化成一个普通反向代理，加速无从谈起。

第一步：把页面拆开，区分可缓存与不可缓存部分

设计规则前先做内容盘点。打开浏览器开发者工具的 Network 面板，刷新一次典型页面，把请求按变化频率分成三类：几乎不变的 JS、CSS、字体；分钟级变化的商品图片、分类页 HTML；每次都变的购物车、个性化推荐、登录态。这个分类直接决定每类资源的 TTL（缓存生存时间）。

静态资源最好办：文件名带版本号（如 app.a3f9c2.js），响应头写一年不过期：

Cache-Control: public, max-age=31536000, immutable

更新靠换文件名，发布时只有文件名变化的资源回源。仅这一条通常就能把命中率从 40% 拉到 80% 以上——按请求数算，静态资源往往占一个页面的八成。

半动态内容是提升空间最大的部分，常用做法有两个。其一是”短 TTL + 主动刷新”：分类页 HTML 缓存 60-300 秒，后台改价后调用 CDN 的缓存刷新 API 精准清除对应 URL，让缓存失效由业务事件驱动而不是被动等过期。其二是把页面拆成模板与数据接口：HTML 模板长缓存，价格库存这类实时数据走 XHR 请求回源，页面主体仍然秒开。SKU 数量巨大、刷新配额吃紧的站点更适合模板与数据分离。

对每一次都必须回源的接口，规则同样重要：

Cache-Control: private, no-store

明确告诉所有中间层不要缓存，避免”购物车串号”这类严重事故。漏配 private 的后果很实际：曾有站点把登录用户的昵称缓存在共享缓存里返回给其他访客，这类事故在接入后才暴露，排查成本远高于事前配置。CDN 之外如果还要叠加安全防护层，可以参考这篇CDN 与高防服务的协同关系详解，讲的就是内容加速与防御层怎么共用一套边缘架构。

第二步：回源方式怎么选——协议回源、回源跟随与回源 Host

缓存规则解决”哪些请求不必回源”，回源策略解决”必须回源的请求怎么走得更稳”。这里有三个关键决策，一个一个过。

第一个决策是协议回源。CDN 回源时用 HTTP 还是 HTTPS，取决于源站的能力：源站已部署 SSL（安全传输协议）证书时，开启”协议跟随回源”，用户 HTTPS 访问则节点 HTTPS 回源，全链路加密；源站没有证书时只能 HTTP 回源，用户到节点一段仍加密，但节点到源站是明文，存在被嗅探的风险。生产环境的建议是源站直接部署免费证书（例如 Let’s Encrypt，90 天有效期，可用 Certbot 自动续期），然后开启全链路 HTTPS 回源，别给中间那段留明文。

第二个决策是回源跟随。开启”回源跟随 301/302″后，节点会在边缘直接处理源站返回的重定向，而不是把 302 丢给用户再发起第二次请求。典型场景是源站做 HTTP 跳 HTTPS：不开启时每个请求多一次往返，开启后节点自己跳转并缓存最终结果。验证方法：

curl -sI http://example.com/path

返回 302 且 Location 指向同一域名时，就该开启这个选项。

回源 Host（回源主机头）是第三个容易踩坑的点。回源 Host 默认是加速域名本身，但源站如果是 Nginx 虚拟主机或对象存储 Bucket，就必须显式改成源站实际识别的 Host，否则可能返回 404 或默认页。排查时在源站抓包确认 Host 头即可。源站侧如果还有别的性能瓶颈，比如线路选择问题，可以先看这篇影响服务器速度的核心因素与优化指南，把源站本身先调顺，再谈回源优化。

第三步：控制回源并发，防住缓存过期瞬间的回源风暴

动态站点最危险的时刻，是热门内容缓存过期的那个瞬间：一个缓存 60 秒的分类页过期那一秒涌入 3000 个请求，没有并发控制时会被全部转发到源站——这就是回源风暴，也是”接了 CDN 反而更慢”的直接原因。

解决方案叫请求合并（request coalescing），多数服务商称作”缓存合并回源”：同一 URL 的并发回源请求在边缘被合并成一个，第一个请求回源拿结果，其余请求等待后共享同一份结果。开启后，上面场景中真正到达源站的请求只有 1 个。这个开关在动态站点上属于必开项，效果立竿见影。

即便有请求合并，源站也要做第二层保护。Nginx 用 limit_req 限速，把超出承载的请求挡在应用之前：

limit_req_zone $binary_remote_addr zone=origin:10m rate=100r/s;
limit_req zone=origin burst=200 nodelay;

应用层面则给数据库连接池设上限（如 200），并在缓存重建路径加互斥锁，让同一时刻只有一个请求回源重建。观察回源量是否健康，看两个指标：回源率（回源请求数 / 总请求数）与源站 QPS 曲线。回源率稳定在 20% 以下、源站 QPS 无周期性尖刺，说明缓存规则与并发控制生效；如果每次整点出现同步尖刺，多半是大量内容被设置了相同的 TTL 同时过期——把 TTL 加上随机偏移（如 300 秒基础值 ± 60 秒抖动）即可打散。

第四步：上线前跑一遍验证清单，别等事故替你发现问题

规则写完不等于生效，上线前逐项验证每类资源的实际行为与设计是否一致，四条检查可以直接照抄。

静态资源：连续两次请求同一 URL，第二次应返回 X-Cache: HIT，且 Cache-Control 中的 max-age 与规划值一致。私有接口：登录态下请求购物车接口，响应头应为 private, no-store，且 Age 不存在或为 0。半动态页面：修改内容并触发刷新 API 后，60 秒内再次请求应返回新内容。回源链路：源站访问日志中，回源请求的 Host 头与协议与规划一致，没有出现 404 或默认页。

监控层建议同时盯三处：CDN 侧的命中率与回源率、源站的 QPS 与 P95 延迟、核心接口的报错率。命中率下降 5 个百分点往往意味着某条规则被误改，越早发现回滚成本越低。WordPress 站点还应注意插件输出对缓存头的影响，插件多输出的一个 Cookie 就可能让整页变回 MISS，这方面的源站侧排查思路可以参考WordPress 网站迁移与优化指南里的服务器配置核对方法，逐个响应头过一遍。

总结：一套可以复用的设计顺序

整个流程可以压缩成四步：先盘点内容分类请求，再为每类资源定缓存规则，然后为必须回源的请求选合适的回源方式，最后用并发控制与监控守住源站。核心原则一句话：缓存规则跟着内容变化频率走，回源策略跟着源站承载能力走。

给两个实操建议。第一，先从回源率看板拿到基线，每次只改一类资源的缓存规则并观察一周，避免大改导致问题无法定位。第二，如果你在挑选或升级源站，可结合业务量评估主机形态：中小型动态站点用 VPS（虚拟专用服务器）即可起步，业务量更大的站点再考虑独服（独立服务器）的配置选项，Hostease 的技术支持也可以协助核对回源配置。

你站点的回源率现在是多少？命中率卡在哪个区间？欢迎在评论区贴出你的 X-Cache 和 Age 数据，一起看看问题出在哪一层。