如何配置CloudFront为不支持压缩的请求者解压预压缩对象？

核心结论 #

CloudFront本身没有内置类似nginx gunzip模块的自动解压功能，但可以通过以下两种可行方案实现需求：

方案1：双版本存储 + CloudFront路径重写 #

这是最稳定且成本可控的方案：

• S3端准备：为每个对象同时上传两个版本：
  • 压缩版：例如app.js.gz，设置Content-Encoding: gzip和对应Content-Type（如application/javascript）
  • 未压缩版：app.js，正常配置Content-Type
• CloudFront配置：
  1. 在缓存行为中，将Accept-Encoding添加到缓存键，确保不同压缩偏好的客户端获取对应内容
  2. 使用CloudFront Functions或Lambda@Edge编写轻量逻辑：
     • 检查请求的Accept-Encoding头部，若包含gzip/br，则重写请求路径到压缩版（如/app.js → /app.js.gz）
     • 若客户端不支持任何压缩格式，直接请求未压缩版
• 优势：逻辑简单，无额外计算开销，兼容性拉满
• 劣势：需占用双倍S3存储容量

方案2：Lambda@Edge响应阶段动态解压 #

适合无法存储双版本的场景：

• 前置配置：确保CloudFront缓存键包含Accept-Encoding，避免缓存混淆
• Lambda@Edge逻辑：创建Viewer Response或Origin Response类型的函数，执行以下操作：
  1. 检测客户端请求的Accept-Encoding头部，确认是否不支持gzip/br
  2. 读取S3返回的压缩内容，利用Node.js的zlib模块完成解压
  3. 修改响应头部：移除Content-Encoding字段，更新Content-Length为解压后的文件大小
  4. 返回解压后的原始内容给客户端
• 注意事项：
  • 仅对文本类文件（JS/CSS/HTML等）启用该逻辑，避免对二进制文件无效操作
  • 大文件解压可能触发Lambda超时，需合理配置内存与超时时间
  • 解压操作会增加Lambda计算成本，同时降低响应速度

关键提醒 #

若S3已存储预压缩对象，务必关闭CloudFront的自动压缩功能，避免重复压缩导致内容损坏。

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