浏览器通过accept-encoding头声明支持的压缩算法，nginx严格按此协商自动选择br或gzip；需同时开启brotli与gzip、对齐types、设最小长度1024字节，并通过真实请求验证content-encoding响应值。
浏览器对压缩算法的支持完全由 Accept-Encoding 请求头决定，Nginx 的 Brotli 配置本身不解析 User-Agent，而是严格遵循 HTTP 协商机制——这是自动适配的核心逻辑。
浏览器如何声明支持能力
现代浏览器在发起请求时，会主动在请求头中带上它能解压的编码格式：
- Chrome 49+、Firefox 44+、Edge 11+、Safari 11+（HTTPS 下）发送：
Accept-Encoding: br, gzip, deflate - IE 或旧版 Android WebView 等只支持 Gzip 的环境发送：
Accept-Encoding: gzip, deflate - HTTP 站点默认不发
br，仅 HTTPS 下浏览器才启用 Brotli 协商
Nginx 如何响应并自动选择
只要 Nginx 已正确集成 ngx_brotli 模块且配置生效，它会按请求头中编码的顺序优先匹配可用压缩方式：
- 若请求含
br且服务端启用了brotli on，则返回Content-Encoding: br - 若请求不含
br但含gzip，且已配置gzip on，则自动回落为Content-Encoding: gzip - 整个过程无需额外判断 UA，也不需要重写规则或条件分支
确保双压缩共存不冲突的关键点
Brotli 和 Gzip 可同时开启，但必须注意配置边界，避免覆盖或重复压缩：
-
禁用重复压缩：若 CDN 或网关层已做压缩，后端 Nginx 应关闭
gzip和brotli，否则可能造成Content-Encoding冲突或 SRI 校验失败 -
类型控制一致：
brotli_types和gzip_types应完全对齐，都只作用于文本类 MIME（如text/html、application/json），绝不压缩.jpg、.png、.woff2等已压缩格式 - 最小长度统一设为 1024 字节：防止对极短响应（如空 JSON、内联 script）做无效压缩，节省 CPU
验证是否真正适配成功
不能只看配置是否存在，要通过真实请求确认协商结果：
- 浏览器开发者工具 → Network → 刷新页面 → 查看任意 HTML/JS/CSS 请求的 Response Headers 中
content-encoding值 - 终端命令验证：
curl -I -H "Accept-Encoding: br,gzip" https://yoursite.com/app.js，应返回content-encoding: br - 再试：
curl -I -H "Accept-Encoding: gzip" https://yoursite.com/app.js，应返回content-encoding: gzip
