CloudFront分发S3存储桶JS/CSS文件MIME类型错误问题求助

可能的原因及排查步骤 #

• Lambda Edge函数篡改了响应头
  检查关联的Origin Request或Origin Response类型Lambda Edge函数代码，很多SPA场景下的函数会把404请求重定向到index.html，但如果逻辑写得太宽泛，可能把JS/CSS的请求也强制返回index.html的内容，同时将Content-Type设为text/html。比如查看函数中是否有类似response.headers['content-type'] = [{key: 'Content-Type', value: 'text/html'}]的代码，或者直接替换了响应体却没同步修正头信息。

• CloudFront缓存行为的响应头设置错误
  检查CloudFront的缓存行为配置：

  1. 确认是否启用了自定义响应头，有没有手动添加Content-Type: text/html的规则覆盖了Origin返回的值；
  2. 查看缓存策略，是否在“缓存键和源请求”设置中，将Content-Type排除在了从源获取的响应头之外，导致CloudFront没有正确缓存并返回源的MIME类型；
  3. 若开启了Origin Shield，可能需要同时对Origin Shield的缓存执行失效操作。

• S3对象元数据未实际生效
  即使S3控制台显示MIME类型正确，也可能存在以下情况：

  1. S3开启了版本控制，当前对外提供的是旧版本的对象，旧版本的MIME类型仍为text/html，需要切换到正确版本或删除旧版本；
  2. 上传对象时使用的工具（如AWS CLI、第三方上传脚本）自动覆盖了元数据，之后在控制台修改的元数据没有同步到实际请求的对象上，可以通过aws s3api head-object --bucket <bucket-name> --key <object-key>命令查看实际返回的Content-Type，确认是否和控制台一致。

• 缓存失效操作未覆盖目标路径
  确认缓存失效的路径是否精准覆盖了问题JS/CSS文件，比如如果文件在/assets/js/app.js，只执行/*的失效可能因缓存键的差异未生效，建议直接指定具体路径（如/assets/js/*、/assets/css/*）再次执行失效。

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