排查brotli头部异常核心是验证accept-encoding与content-encoding在客户端→代理→nginx→后端全链路是否被篡改、截断或错配：检查上游代理是否剥离br头、nginx是否透传$proxy_set_header accept-encoding $http_accept_encoding、响应头体是否匹配、vary: accept-encoding是否生效、静态.br路径是否因代理重写失效。
排查代理转发中 Brotli 头部异常，核心是确认 Accept-Encoding 和 Content-Encoding 在整条链路（客户端 → 代理 → Nginx → 后端）中是否被篡改、截断或错误透传。Brotli 白屏、降级为 gzip 或 406 错误，多数源于中间代理破坏了压缩协商逻辑。
检查 Accept-Encoding 是否被代理剥离或改写
现代浏览器发起请求时会带 Accept-Encoding: br, gzip, deflate，但很多传统代理、WAF、CDN 或网关（如某些版本的 HAProxy、Nginx 反向代理未配置 proxy_set_header Accept-Encoding $http_accept_encoding;）会默认清空或硬编码该头。
- 在客户端用
curl -v -H "Accept-Encoding: br,gzip" https://yoursite.com/app.js发起请求，抓包或查看 Nginx access 日志中的$http_accept_encoding变量，确认它是否到达 Nginx —— 若日志里为空或只有gzip，说明上游代理已过滤br - 若使用 Nginx 做反向代理，必须显式透传：
location /api/ {<br> proxy_pass http://backend;<br> proxy_set_header Accept-Encoding $http_accept_encoding;<br>}
漏掉这行，后端永远收不到br，Nginx 自身的 Brotli 动态压缩也不会触发（因判定客户端不支持）
验证 Content-Encoding 是否被代理重复添加或错配
常见问题：代理把后端返回的 Content-Encoding: br 直接透传，但实际响应体是未压缩的原始内容；或代理自己加了一次 br 头，却没真正压缩——浏览器收到头体不匹配，直接丢弃响应体导致白屏。
- 用
curl -I -H "Accept-Encoding: br" https://yoursite.com/app.js查看响应头，再用curl -H "Accept-Encoding: br" https://yoursite.com/app.js | brotli -d -t 2>/dev/null || echo "invalid"验证响应体能否解压。若头有br但解压失败，说明代理或 Nginx 没走压缩路径，只是透传了错误头 - 如果代理层（如 CDN）也启用了 Brotli，而 Nginx 又同时启用，容易出现双重压缩或头冲突。建议只在最靠近客户端的一层（通常是边缘 Nginx 或 CDN）启用 Brotli，后端代理关闭
brotli on，并确保proxy_hide_header Content-Encoding和proxy_ignore_headers Content-Encoding不被误配
确认 Vary: Accept-Encoding 是否被代理缓存污染
Vary: Accept-Encoding 是告诉缓存系统“不同压缩格式要存不同副本”。若代理（如 Squid、旧版 Nginx proxy_cache、部分云 WAF）不支持该头，或缓存策略忽略 Vary，就可能出现：用户 A 请求带 br，命中缓存返回了 br 响应；用户 B 请求只带 gzip，却拿到同一份 br 内容 + Content-Encoding: br，浏览器无法解压而报错或空白。
- 检查响应头中是否有
Vary: Accept-Encoding；若缺失，加add_header Vary Accept-Encoding;（注意不要和gzip_vary on或brotli_static冲突） - 在代理配置中禁用对
Vary的忽略行为。例如 Nginx 作为缓存代理时，确保没有proxy_cache_ignore_headers Vary;这类指令 - 临时绕过代理直连 Nginx，对比响应是否正常。若直连无问题，基本可定位为代理层干扰
区分静态 .br 文件服务与动态压缩的代理交互
当启用 brotli_static on 时，Nginx 会尝试返回磁盘上的 .br 文件，并设置 Content-Encoding: br。但如果代理在转发时做了重写（如 path rewrite、host 替换），可能导致 Nginx 查找的物理路径错误，返回 404 或原始文件，但头部仍带 br，造成头体不一致。
- 确认代理未修改
request_uri或host，导致 Nginx 中root或alias解析出错 - 在 Nginx 中开启调试日志：
error_log /var/log/nginx/debug.log debug_http;，搜索brotli static file关键字，看是否真实命中了.br文件 - 更稳妥做法：在代理层统一关闭
brotli_static，只由 Nginx 做动态压缩（brotli_static off），避免路径依赖和权限问题
