CDN 预热任务显示成功，正式流量到来后命中率却没有提高，甚至出现更多回源请求。这个结果通常不是“预热没有生效”这么简单：预热请求可能没有覆盖真实缓存键，预热到了错误的节点或层级，或者对象在正式请求到来前已经过期、被刷新或被规则绕过。
排查时要把预热请求和真实用户请求逐项对齐：域名、路径、查询参数、请求头、协议、节点范围、缓存规则和源站版本。只看预热接口返回“成功”，不能证明目标对象已经在所有需要的边缘节点可复用。
先确认预热的对象与真实请求相同
找出命中率下降最明显的路径，记录真实请求的完整 URL、Host、查询参数、Accept-Encoding、语言请求头、Cookie 以及 CDN 缓存状态。再与预热任务提交的 URL 和请求条件比较。
常见差异包括：
预热使用了无查询参数 URL，真实流量带有版本、租户或追踪参数；
预热域名与正式访问域名不同；
gzip、Brotli 和未压缩响应生成了不同缓存变体；
预热请求使用了一个不会进入缓存键的请求头；
预热对象已经被新版本发布或失效任务替换。
如果查询参数确实影响响应内容，不能为了提高命中率把它们从缓存键中删除。先确认业务语义，再决定哪些参数可以归一化。
预热成功不等于每个节点都有对象
不同 CDN 对预热范围的定义不同。有的平台只保证向某个区域或指定节点发起请求，有的平台会把对象填充到上层缓存，再由边缘按需获取。控制台中的“成功”可能只代表任务被接受、源站返回了响应，或者某个填充动作完成。
核对服务商文档和任务详情中的区域、节点、状态、失败重试与完成时间。用多个网络重复请求同一个版本化对象，记录 Age、缓存状态、响应头和边缘追踪 ID。不要根据单个地区的一次命中就推断全网都已预热。
源站响应必须适合被缓存
如果源站返回 Cache-Control: private、no-store，或者带有与用户状态相关的 Set-Cookie，CDN 可能不会把响应作为共享对象保存。某些平台还会依据路径规则覆盖源站头部，实际行为要以当前配置验证。
预热前先检查对象的：
HTTP 状态码是否允许缓存；
Cache-Control、Expires和Vary；Set-Cookie是否存在；ETag、Last-Modified和对象版本；响应是否需要登录态或特定请求头。
不要用预热任务测试登录页面、购物车或个性化 API。对这些内容，正确目标通常是保持隔离和稳定回源，而不是提高共享缓存命中率。
用受控请求验证缓存填充
下面的示例只读取一个公开、较小、带版本号的静态对象。请替换域名和路径，不要用随机参数持续制造生产回源。
curl -sS --max-time 10 \ -D after-warm.headers -o after-warm.body \ 'https://cdn.example.com/assets/app.7f3a1c.js' sha256sum after-warm.body grep -Ei '^(age|cache-control|etag|vary|x-cache|cdn-cache|content-encoding):' after-warm.headers
在预热完成后、正式流量到来前，以及正式流量开始后的多个时间点执行。比较解码后的正文摘要、缓存状态、Age 和源站日志。Age 缺失不能单独证明没有缓存，MISS 也不一定说明请求已经直达源站，具体含义取决于服务商和缓存层级。
预热可能增加源站压力
预热任务会主动制造回源请求。如果任务覆盖大量对象、多个缓存变体或多个区域，源站可能在正式流量到来前就出现连接数、带宽或存储读取峰值。对象正在更新时，预热还可能把旧版本和新版本分别填充到不同节点。
为预热设置并发、速率和对象范围限制。先选择少量热点对象验证，再逐步扩大范围。发布流程应先确保所有源站版本一致，再预热新版本，最后从多个网络验证。不要在源站尚未就绪时用预热掩盖发布问题。
按证据修复
如果实际请求与预热请求的缓存键不同，修正预热输入或缓存键设计；如果预热范围没有覆盖目标节点，按服务商能力调整区域和层级；如果源站头部禁止共享缓存，先判断这是有意的隐私边界还是误配置。
每次只改变一个缓存条件或一个资源组，保存原配置、预热任务 ID、对象版本和回滚方式。验收同时观察缓存命中率、回源请求数、回源字节、源站错误率和响应延迟。命中率短时升高并不等于预热长期有效，仍需覆盖正式业务窗口。
参考资料
资料核验日期：2026 年 11 月 12 日。本文命令为受控读取示例，不代表已在读者的生产环境执行。
