brotli仅在https下生效，因浏览器仅在tls加密通道中主动发送accept-encoding: br；http站点永不触发协商，且nginx需加载ngx_brotli模块并正确配置brotli_static、proxy_set_header与cache_key等参数。
Brotli 在 HTTPS 环境下才能生效，不是配置了就能传出去——它依赖浏览器在 TLS 加密通道中主动发送 Accept-Encoding: br 请求头。HTTP 站点永远不会触发 Brotli 协商，这点必须前置确认。
HTTPS 是 Brotli 的硬性前提
现代浏览器（Chrome、Firefox、Edge、Safari 11+）只在 HTTPS 页面中发出带 br 的编码请求。若站点仍走 HTTP，即使 Nginx 全部配对，响应头里也绝不会出现 Content-Encoding: br。验证方式很简单：打开 Chrome DevTools → Network → 刷新 → 找 HTML 或 JS 请求 → 查 Response Headers，必须同时看到：
Content-Encoding: brVary: Accept-Encoding- “Size”明显小于“Content”（说明压缩真实生效）
Nginx 必须加载并启用 ngx_brotli 模块
官方 Nginx 不内置 Brotli 支持。运行 nginx -V，若输出中找不到 ngx_brotli，所有 brotli on 配置都无效。正确路径是：
- 下载 ngx_brotli 源码，执行
git submodule update --init - 重新编译 Nginx：
./configure --add-module=/path/to/ngx_brotli，再make && make install - 在主配置文件顶部（
events块之前）添加：load_module modules/ngx_http_brotli_filter_module.so;
关键配置项要精准控制
压缩不是开得越狠越好，尤其对首屏性能敏感的 HTML：
-
brotli_comp_level 5（4～6 安全区），避免用 11 级导致边缘节点首字节延迟升高 -
brotli_min_length 256，跳过极小响应（如空 JSON），防止压缩开销反超收益 -
brotli_types只列真正可压类型：text/html text/css application/javascript application/json image/svg+xml，不加*或text/plain - 启用预压缩支持：
brotli_static on，配合提前生成的.br文件（同目录、同名、权限一致）
回源链路需显式透传与缓存隔离
如果用 Nginx 做边缘代理，Brotli 要端到端生效，还需三步协同：
- 在
location块中加：proxy_set_header Accept-Encoding "br,gzip,deflate";（br必须最前） - 源站 Nginx 同样开启
brotli on和brotli_static on，确保真实返回br编码内容 - 缓存键必须区分编码：
proxy_cache_key "$scheme$request_method$host$request_uri$http_accept_encoding";，否则 gzip 版本可能污染 br 请求
