同时启用gzip和br时CloudFront有时返回gzip而非br的原因是什么？

常见成因 #

• 缓存遗留问题
  CloudFront边缘节点的缓存具备惰性更新特性：若节点中已缓存了某文件的gzip版本（例如缓存策略调整前的旧缓存、历史上不支持Brotli的客户端请求触发的回源缓存），在缓存TTL过期前，节点不会主动重新生成Brotli版本，会直接返回已缓存的gzip内容，这是该现象最常见的诱因。
• 压缩效率优先逻辑
  CloudFront自动压缩时会在底层对比两种压缩格式的最终产出大小：当Brotli压缩后的文件体积大于等于gzip压缩结果时（该场景常见于小于1KB的极小文件、本身已经过高压缩处理的文本类资源），会直接返回体积更小的gzip版本，该逻辑属于平台内部性能优化项，未在公开文档中明确标注。
• 源站预压缩干扰
  若你的源站对部分资源返回了已压缩的内容（响应头携带Content-Encoding: gzip），CloudFront默认不会对已压缩的资源进行二次转压缩，会直接透传源站返回的gzip内容，不会生成Brotli版本。
• 内容类型适配问题
  CloudFront默认仅对指定的Content-Type类型的资源开启自动压缩，若部分资源的Content-Type不在支持列表中，即使缓存策略开启了压缩也不会生效，不过该场景下通常会返回未压缩内容而非gzip，可作为次要排查方向。

排查方案 #

• 对返回gzip的异常文件提交一次缓存失效操作，清除边缘节点的旧缓存后重新发起支持Brotli的请求，确认是否仍返回gzip。
• 检查源站响应头，关闭源站的预压缩逻辑，交由CloudFront统一处理压缩逻辑；或源站同时提供gzip和Brotli的预压缩资源，通过内容协商规则匹配返回。
• 对比异常文件的大小和内容特征，若均为1KB以下的极小文件或压缩空间极低的资源，该现象属于正常优化逻辑，无需额外处理。

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