启用Brotli回源需三步：边缘Nginx显式添加proxy_set_header Accept-Encoding "br,gzip,deflate"；源站Nginx开启brotli on并配置brotli_types；proxy_cache_key中加入$http_accept_encoding避免缓存污染。
直接在 Nginx 上启用 Brotli 压缩本身并不能自动降低 HTTPS 回源带宽——关键在于让边缘节点主动向源站发起带 Accept-Encoding: br 的请求，并确保源站能响应 Content-Encoding: br，同时缓存系统正确区分不同编码版本。
源站必须真实返回 Brotli 编码内容
边缘 Nginx 默认不会在 proxy_pass 请求中携带 Accept-Encoding 头。即使你启用了 brotli on，那只是压缩「发给浏览器」的响应，和「回源请求」无关。
- 需在反向代理 location 块中显式添加：
proxy_set_header Accept-Encoding "br,gzip,deflate";（注意br放最前） - 源站（如另一台 Nginx）必须加载
ngx_http_brotli_filter_module并开启：brotli on;brotli_types text/css application/javascript ...; - 若源站是静态文件服务，建议配合
brotli_static on;，提前生成.br文件，避免实时压缩开销
缓存键必须包含 Accept-Encoding 变量
如果所有编码格式（br / gzip / 无压缩）都用同一个 cache key，就会出现缓存污染：比如先缓存了 gzip 版本，后续带 br 的请求可能错误返回 gzip 内容，导致浏览器解压失败。
- 在
proxy_cache_key中加入$http_accept_encoding：proxy_cache_key "$scheme$request_method$host$request_uri$http_accept_encoding"; - 不推荐混入
$http_user_agent或其他易变头，否则缓存碎片化严重 - 若只支持 br/gzip/无压缩三种情况，
$http_accept_encoding已足够区分
验证是否真正走通 Brotli 回源链路
不能单看浏览器 Network 面板里“Size”小就认为成功——那可能是边缘侧用 Gzip 压的。要确认三点：
- 查边缘 Nginx access log，加字段
$upstream_http_content_encoding，看到值为br - 抓包或查源站 access log，确认收到的 upstream 请求头含
Accept-Encoding: br - 用 curl 直连源站对比：
curl -H "Accept-Encoding: br" -I https://origin.example.com/test.js
与经边缘访问时的响应头、body 大小是否一致
HTTPS 环境下 Brotli 的前置条件
Brotli 协商依赖 TLS 加密通道，浏览器仅在 HTTPS 下才发送 Accept-Encoding: br。所以：
- 确保站点已启用 HTTPS，且证书有效
- 监听配置中启用 HTTP/2（可选但推荐）：
listen 443 ssl http2; - 无需额外开启 TLS 1.3，但若支持可进一步降低握手延迟
- 兼容性无忧：Chrome、Firefox、Safari、Edge 全部支持，仅 IE 和 Opera Mini 不支持（可保留 Gzip 作为降级）
