在AWS CloudFront里启用Gzip与Brotli压缩，本质是由边缘节点在回源拿到明文响应后，依据客户端请求里的Accept-Encoding字段动态完成编码再返回。很多团队以为只要在源站开了压缩，CDN就会自动透传，结果用户侧收到的仍是未压缩内容。理解CloudFront的压缩触发条件，是正确配置的前提。
CloudFront压缩的基本机制与前提条件
CloudFront的压缩发生在边缘站点（Edge Location），而不是源站。当 viewer 请求携带 Accept-Encoding: gzip, br 这类头时，边缘节点若判断该对象类型在可压缩名单中（如 text/html、application/javascript、application/json 等），且源站返回的是未压缩正文、大小在 1000 字节到 10 MB 之间，就会自动选用客户端支持的最优算法进行压缩。Brotli 仅在客户端声明支持 br 时才使用，否则回退到 Gzip。
这里有一个常见误区：如果源站自身已经对响应做了 Gzip 或 Brotli 压缩，CloudFront 默认不会二次压缩，而是直接缓存并转发该压缩版本。这要求源站必须根据 Accept-Encoding 正确返回对应编码，否则可能出现部分客户端拿到压缩包、部分拿到原包的不一致缓存。因此，若希望由 CloudFront 统一处理压缩，最干净的做法是源站关闭压缩，让边缘节点全权负责。
另外需要注意，CloudFront 的压缩只针对特定的 MIME 类型白名单，图片（如 jpg、png、webp）和视频本身已是二进制压缩格式，不在名单内。若你用 Lambda@Edge 自行改写响应，也要确保不破坏 Content-Length 与 Content-Encoding 的对应关系，否则客户端解压会失败。
通过控制台与CLI配置压缩行为
在 CloudFront 分配（Distribution）的 Cache Behavior 设置中，有一个 Compress Objects Automatically 开关，将其设为 Yes 即代表允许边缘节点自动压缩。该选项对 Web 分配和 RTMP 分配都有效，但 RTMP 实际不涉文本压缩场景。若使用 CLI 创建或更新分配，对应的字段是 DefaultCacheBehavior.Compress，值为 true 即可。
下面是一段用 AWS CLI 更新已有分配开启压缩的示例。先取出当前配置并修改，再提交变更。注意 CloudFront 要求每次更新都带 If-Match 头以防并发覆盖，这里用 ETag 占位。
# 获取分配配置 aws cloudfront get-distribution-config --id E123EXAMPLE --output json > dist.json # 手动将 DefaultCacheBehavior 中的 Compress 改为 true 后，提取 ETag ETAG=$(jq -r '.ETag' dist.json) CONFIG=$(jq '.DistributionConfig' dist.json) # 提交更新 aws cloudfront update-distribution --id E123EXAMPLE --if-match "$ETAG" --distribution-config "$CONFIG"
配置保存后，CloudFront 需要几分钟完成全局部署。此时不要立刻用浏览器验证，因为浏览器可能复用旧缓存。更可靠的方式是用 curl 指定编码头直接请求边缘域名，观察返回头。若返回里出现 Content-Encoding: br 或 gzip，且 body 大小明显小于源站直连，说明压缩链路通了。
对于已经存在大量缓存的旧分配，修改 Compress 选项不会让已缓存的未压缩对象失效，新请求命中旧缓存时仍可能返回无编码内容。可以通过 Invalidation 主动刷新关键路径，或者等待对象 TTL 过期自然更新。这也是为什么建议在新建分配时就确定压缩策略。
用curl与响应头验证压缩是否真正生效
验证的核心在于对比「源站直连」与「经过 CloudFront」两次响应。先用 curl 对源站 IP 或自有域名（未走 CDN）发请求，记录 Content-Length 与 Content-Type。再对 CloudFront 域名发同样请求，并显式带上 Accept-Encoding: br，查看是否返回 Content-Encoding: br 及更小的长度值。
以下命令演示了如何分别验证 Brotli 与 Gzip 支持情况。第一条强制只接受 br，第二条只接受 gzip，第三条不带编码头作为对照。
# 验证 Brotli curl -s -I -H 'Accept-Encoding: br' https://d123example.cloudfront.net/app.js # 验证 Gzip curl -s -I -H 'Accept-Encoding: gzip' https://d123example.cloudfront.net/app.js # 对照：无压缩请求 curl -s -I https://d123example.cloudfront.net/app.js
如果第一条返回头包含 content-encoding: br 且 content-length 较小，而第三条没有该头，说明 CloudFront 确实按客户端能力动态压缩。某些情况下你可能会发现带 br 仍返回 gzip，这是因为边缘节点依据自身策略与对象类型选择了兼容方案，并不影响节省带宽的目标。
当验证发现压缩未生效，优先检查三点：Cache Behavior 的 Compress 是否为 true；请求 MIME 类型是否在 CloudFront 压缩白名单；源站是否误回了 Content-Encoding 导致边缘跳过。通过逐层排除，基本都能在十分钟内定位问题。掌握这套配置与验证方法，才能让 AWS CloudFront 的 Gzip 与 Brotli 能力真正服务于前端性能优化。
CloudFrontGzipBrotli修改时间：2026-08-18 09:36:31