设置cache-control: no-store等规则后Cloudfront仍返回RefreshHit的原因？

问题原因分析 #

1. RefreshHit的本质 #

CloudFront的RefreshHit状态意味着：边缘节点收到需要验证缓存有效性的请求后，向源站发送了验证请求，源站返回304 Not Modified确认内容未变更，边缘节点直接返回本地缓存的内容，因此标记为RefreshHit。

你遇到的现象符合以下几个常见配置逻辑：

• 客户端发送的Cache-Control: no-store不生效：CloudFront默认不会遵循客户端请求中的缓存指令，除非你在缓存策略中明确开启了尊重客户端Cache-Control配置。未开启的情况下，客户端的no-store、max-age=0只会触发CloudFront回源验证，不会阻止CloudFront缓存内容。
• Minimum TTL为0不代表禁止缓存：Minimum TTL是CloudFront强制缓存的最短时间，设为0仅表示CloudFront不会强制缓存超过源站指定的缓存时长。只要源站返回的响应头包含可缓存标识（比如Cache-Control: public、ETag、Last-Modified），CloudFront就会正常缓存内容，后续验证请求就会返回RefreshHit。
• 缓存失效不会阻止新内容缓存：你执行的/*路径缓存失效只会删除边缘节点已有的缓存内容，失效后的第一个请求回源拿到可缓存的响应后，边缘节点会重新缓存该内容，后续请求依然会触发RefreshHit逻辑。

2. 后续修改后仍出现缓存命中的原因 #

• 你修改的如果是客户端请求的Cache-Control头，不会影响CloudFront的缓存逻辑：CloudFront默认根据源站返回的响应Cache-Control头决定是否缓存，而非客户端的请求头。如果源站返回的响应没有明确的Cache-Control: no-store, no-cache头，CloudFront依然会缓存内容。
• Firefox观测到的命中可能是浏览器本地缓存：可检查响应的X-Cache字段，只有该字段值为Hit from cloudfront才是CloudFront边缘节点的缓存命中，否则为浏览器本地缓存，和CloudFront配置无关。

排查解决步骤 #

• 检查CloudFront缓存策略配置：开启「遵循客户端Cache-Control指令」、「遵循源站Cache-Control指令」，如果完全不需要缓存，可直接将缓存策略的默认TTL、最大TTL都设为0。
• 调整源站响应头：给不需要缓存的响应添加Cache-Control: no-store, no-cache, must-revalidate, private头，明确告知CloudFront不要缓存内容。
• 确认缓存失效完成：CloudFront全球边缘节点完成缓存失效最长需要15分钟，提交失效任务后等待10~15分钟再测试，避免命中未完成失效的节点缓存。

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