双压缩指边缘到客户端和边缘到源站两层独立压缩：前者依浏览器accept-encoding返回br/gzip，后者要求边缘主动带accept-encoding: br回源并源站真实响应br内容，同时缓存键须含$http_accept_encoding以防污染。
直接启用 Brotli 并不能自动缩短 HTTPS 响应时间，尤其在高并发场景下。真正起效的是“双压缩策略”——即在边缘节点（如 CDN 或反向代理）与源站之间建立 Brotli 回源链路，同时确保终端浏览器能拿到最优编码版本。这需要三端协同：边缘、源站、缓存系统，缺一不可。
明确双压缩的两个作用层
“双压缩”不是指两次压缩同一内容，而是指：
- 边缘到客户端：边缘节点根据浏览器 Accept-Encoding 头决定是否用 Brotli 压缩响应（如 br/gzip/无压缩）
-
边缘到源站：边缘主动带
Accept-Encoding: br请求源站，源站返回真实 br 编码内容，而非仅靠边缘自己压缩
后者才是降低 HTTPS 回源带宽、减少源站 CPU 压力、提升整体吞吐的关键。若只做第一层，所有压力仍集中在边缘；若只做第二层，但边缘不识别 br，用户也收不到。
高并发下必须配置的三项硬性规则
在 Nginx 类边缘网关中，以下配置不可省略，否则双压缩链路断裂：
-
强制回源携带 br 头：在
location块中添加proxy_set_header Accept-Encoding "br,gzip,deflate";，且br必须排第一位 -
源站真实响应 br 内容：源站 Nginx 需加载
ngx_http_brotli_filter_module，并开启brotli on;和brotli_static on;（推荐预生成 .br 文件，避免实时压缩争抢 CPU） -
缓存键区分编码类型：
proxy_cache_key中必须包含$http_accept_encoding，例如："$scheme$request_method$host$request_uri$http_accept_encoding"，否则 gzip 版本可能被误返回给请求 br 的用户
适配全网终端的兼容性兜底方案
不是所有客户端都支持 br，尤其旧版安卓 WebView 或企业内网环境。需分层响应：
- 浏览器请求头含
br→ 边缘查缓存（key 含 br）→ 命中则直发；未命中则回源带 br 请求 → 源站返回 br → 边缘缓存并返回 - 浏览器仅支持
gzip→ 边缘查对应 key → 若无缓存，则回源时仍发br（因源站已支持），再由边缘解压后用 gzip 重压返回（不推荐）或直接转发源站 br 内容（需浏览器兼容） - 更稳妥做法：源站统一返回 br，边缘按需转码（极少见）；或配置
map规则，对明确不支持 br 的 UA（如 MSIE）直接禁用 br 回源
验证双压缩是否真正生效
不能只看浏览器 Network 面板里“Transferred”变小——那可能是边缘用 gzip 压的。要确认三点：
- 边缘 access log 中
$upstream_http_content_encoding字段值为br - 源站 access log 中，对应请求的
$http_accept_encoding头含br - 用 curl 直连源站：
curl -H "Accept-Encoding: br" -I https://origin.com/test.js，响应头含Content-Encoding: br且 body 大小与经边缘访问一致
