浏览器通过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 模块且配置生效，它会按请求头中编码的顺序优先匹配可用压缩方式：

小红书长文-谷歌浏览器

在 Linux 上通过 Chrome 挂载/VNC 自动发布小红书长笔记。Agent 撰写标题和正文后执行 xhs_publish.sh --publish --submit，触发小红书发布。

下载

• 若请求含 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