LightSail迁EC2后CloudFlare缓存HIT不稳定 流量费用过高求助

• Cloudflare的缓存有效性校验不仅依赖URL，默认会同步校验源站返回的ETag、Last-Modified响应头。迁移到EC2后如果文件的修改时间、ETag生成规则和原LightSail环境不一致，哪怕文件内容、URL完全相同，Cloudflare也会判定原有缓存失效，触发全量回源拉取，导致缓存重建。
• Cloudflare分布式边缘节点的DNS缓存生效存在时差，修改DNS解析后，不同区域节点的旧解析记录会在TTL到期后陆续切换到新的EC2源站，每批节点切换时都会触发一轮回源校验，直接导致缓存HIT率不稳定。
• 现有Nginx的add_header配置缺少always参数，默认仅对200、201、301等少数状态码的响应返回Cache-Control头，若源站返回其他状态码（如304、404）时未携带缓存头，Cloudflare会启用默认缓存策略，大幅缩短缓存有效期，频繁触发回源。
• 若迁移前后调整过Cloudflare的页面规则、缓存规则，或误触发过缓存清理操作，也会导致原有缓存批量失效。

• 优先修正Nginx缓存头配置，加上always参数确保所有响应均携带缓存规则：

  add_header Cache-Control "public,max-age=315360000,immutable" always;
  

  同时可在Cloudflare控制台的缓存规则中，开启「stale while revalidate」（过时内容提供策略），节点回源校验时优先返回已有缓存内容，后台异步拉取新内容，避免用户请求直接触发回源。
• 临时开启Cloudflare Cache Reserve功能，将热点资源持久化存储到Cloudflare的免费存储层，大幅减少回源到EC2的请求量，降低出网带宽成本。
• 检查Cloudflare控制台配置，确认「开发模式」已关闭，原有针对媒体资源的页面规则、缓存规则未被修改，将解析TTL调整为1小时以上，避免边缘节点频繁刷新解析触发回源。
• 针对热点媒体资源可通过Cloudflare的缓存预热接口批量预热，提前将资源推送到各边缘节点，避免用户访问时触发回源。

内容的提问来源于stack exchange，提问作者Farukh Zahoor