排查 Nginx Brotli 压缩截断需聚焦传输完整性：先比对 curl 响应字节数与源站 .br 文件大小，不等即截断；再抓包查 TCP payload 是否在缓冲边界（如4096）突止；逐层绕过 CDN/WAF/前置代理定位故障点；检查 CDN 是否启用 Brotli、WAF 是否篡改请求头、HTTP/2 回源头大小限制、Nginx proxy_buffers 配置及 brotli_static/brotli 冲突。
排查 Nginx Brotli 压缩在特定代理链路中被截断，关键不是看“有没有 br”，而是确认压缩后的字节流是否完整抵达客户端。截断常无声无息——没有 5xx 错误、日志无异常、浏览器只显示白屏或解析失败。问题多发生在 CDN/WAF/前置 Nginx 多层转发时，Brotli 响应体在某一级缓冲区被硬切，导致 gzip 流不完整。
确认截断是否真实发生
先排除“没压缩”和“解压失败”的干扰，聚焦传输完整性：
- 用 curl -s https://yoursite.com/app.js | wc -c 获取实际响应字节数，再对比源站直连返回的 .br 文件大小（wc -c /path/to/app.js.br）。两者不等 → 已截断
- 抓包验证：运行 tcpdump -i lo port 80 -w brotli.pcap，用 Wireshark 打开，查看 TCP payload 是否在 4096、8192 或 32768 等典型缓冲边界处突然终止
- 检查响应头中的 Content-Length：若该值正确但 body 实际更短，说明 Nginx 写出异常；若 Content-Length 本身偏小，大概率是上游（如后端 Node.js）提前关闭了输出流
定位截断发生在哪一级代理
逐层绕过，缩小范围：
- 直连源站 Nginx（跳过所有 CDN/WAF/前置代理）：加 -H "Accept-Encoding: br"，确认能返回 Content-Encoding: br 且内容完整
- 仅走第一级代理（如前置 Nginx）：观察响应头是否有 Vary: Accept-Encoding，同时比对 Content-Length 和实际字节数
- 全链路访问（含 CDN）：用 curl -v 查看完整响应过程，重点关注是否出现 Transfer-Encoding: chunked 但 chunk 边界错乱，或响应中途断连
- 查 CDN/WAF 日志：部分服务会记录 “truncated response”、“buffer overflow” 或 “incomplete body” 类警告
检查代理层对 Brotli 的兼容性限制
很多中间代理默认不信任或不透传 Content-Encoding: br，甚至主动剥离或重写响应：
- 确认 CDN 控制台是否启用 “Brotli 支持” 开关（如 Cloudflare 需手动开启，阿里云 CDN 默认关闭）
- 某些老旧 WAF 会强制清除 Accept-Encoding: br 请求头，或把 br 响应降级为 gzip，可用 mitmproxy 抓包比对请求头是否被篡改
- 若使用 HTTP/2 回源，检查 http2_max_field_size（默认 4k）是否足够承载带 Brotli 的响应头；过大 Cookie 或自定义追踪头可能触发截断
- 前置 Nginx 若启用了 proxy_buffering off，又未配足 proxy_buffers，极易在流式返回 Brotli 时丢弃尾部
验证并加固 Nginx 自身配置
即使上游没问题，Nginx 作为最后一环也可能成为瓶颈：
- 确保 brotli_static on; 与 brotli on; 不共存于同一 location —— 否则 .br 文件存在时走静态路径，缺失时 fallback 到动态压缩，行为不一致易引发缓存错乱
- 添加 proxy_hide_header Content-Encoding; 防止上游错误设置该头（如后端误设 Content-Encoding: br 但 body 未压缩），避免 Nginx 二次压缩损坏流
- 启用 brotli_vary on;（需模块支持），让所有代理知道该响应依赖编码协商，避免缓存混用
- 在 log_format 中加入 $brotli_ratio 和 $upstream_http_content_encoding，批量分析截断请求是否集中在特定压缩比或上游编码类型
