更新S3存储桶文件后CloudFront仍返回304状态码问题排查

首先得明确，304的核心逻辑是客户端或CloudFront节点认为请求的资源没有变化，所以直接返回本地缓存的版本。你已经尝试了重命名文件、替换文件和调整边缘缓存设置，那我们来看看容易被忽略的几个点：

1. 检查S3对象的元数据（缓存控制头） #

S3对象的Cache-Control、Expires和ETag元数据会直接影响CloudFront和客户端的缓存行为：

• 如果你上传文件时没有显式设置Cache-Control，S3默认不会添加这个头，但有些上传工具（比如AWS CLI、第三方客户端）可能会自动添加上较长的缓存过期时间，导致客户端长时间缓存旧资源。
• 即使你替换了文件，如果新文件的ETag和旧文件一致（比如文件内容完全相同，或者上传时意外禁用了ETag生成），也会触发304。
• 操作路径：进入S3存储桶，找到目标ZIP文件，右键选择属性，拉到元数据部分，检查是否有Cache-Control（比如max-age=31536000这类长期缓存设置），以及新旧文件的ETag是否不同。

2. 验证CloudFront的缓存策略与请求头转发 #

CloudFront的缓存行为设置里，有两个容易被忽略的配置：

• 对象缓存设置：如果你选择的是使用源站标头，那么S3返回的Cache-Control会完全主导CloudFront和客户端的缓存时长。即使你调整了边缘缓存的TTL，源站的标头优先级更高。建议暂时切换为自定义缓存设置，把最小/最大/默认TTL都设为0（测试用），看看是否还返回304。
• 转发请求头：如果你的CloudFront行为没有转发If-Modified-Since或If-None-Match请求头到S3，CloudFront会直接用自身缓存的资源状态来判断是否返回304，而不会去源站验证最新状态。检查行为设置里的转发请求头，确保至少转发这两个头，或者选择转发所有请求头（测试阶段）。

3. 排除客户端本地缓存的干扰 #

很多时候，问题出在你的测试浏览器本身——浏览器会顽固地缓存之前的响应，即使服务器端已经更新。你可以：

• 用无痕/隐私模式重新访问URL，看是否返回200。
• 用curl命令强制跳过本地缓存测试：

  curl -H "Cache-Control: no-cache" -I https://your-cloudfront-domain/your-file.zip
  

  观察返回状态码是否为200，同时检查ETag是否和S3上的新文件一致。

4. 检查CloudFront缓存失效（Invalidation） #

即使你替换了S3上的文件，CloudFront边缘节点可能还缓存着旧版本的资源。这时候即使源站更新了，边缘节点可能仍返回旧的缓存，进而触发客户端的304。你可以手动提交一次缓存失效请求：

• 进入CloudFront控制台，找到对应的分发，选择失效标签，输入/*（或目标文件路径），提交失效请求。等待1-5分钟（边缘节点同步时间）后再测试。

5. 确认S3版本控制的影响（如果开启） #

如果你的S3存储桶开启了版本控制，替换文件时会生成一个新版本，但如果没有将新版本设置为当前版本，CloudFront访问的仍然是旧版本的文件。进入S3文件的版本标签，确认当前活跃版本是你刚上传的新文件。

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