Nginx反向代理导致“缓冲区失真”的根本原因是其默认缓冲chunked响应并改写为Content-Length，破坏流式传输语义；修复需三步：启用HTTP/1.1、禁用proxy_buffering、清除Connection头，并确保后端不同时设置Content-Length与Transfer-Encoding。
后端返回 Chunked 编码本身没有问题，真正导致“缓冲区失真”的，是反向代理（尤其是 Nginx）在处理该编码时的中间行为——它把流式、不定长的数据强行收全、缓存、再改写为定长响应，从而破坏了原始 chunk 结构和实时性。这不是数据损坏，而是传输语义被覆盖。
确认是否真由 Nginx 缓冲引发
先排除误判：用 curl -v 直连后端服务（绕过 Nginx），观察响应头是否含 Transfer-Encoding: chunked，且响应体中可见十六进制长度行（如 1a\r\n...、0\r\n\r\n）。再用同样命令访问 Nginx 地址，对比响应头是否变成 Content-Length、是否丢失 chunk 分隔符。若后者成立，就是缓冲区失真。
核心修复：禁用缓冲 + 强制 HTTP/1.1
在对应 location 块中添加以下三行（缺一不可）：
- proxy_http_version 1.1; —— 让 Nginx 用 HTTP/1.1 连接后端，否则无法识别 chunked
- proxy_buffering off; —— 关键！禁用响应缓冲，避免 Nginx 收全再发
- proxy_set_header Connection ''; —— 清除上游可能带入的 Connection 头，防止干扰连接复用
规避 Content-Length 冲突
如果后端代码或框架（如某些 Spring Boot 配置、PHP SAPI 模式）在返回 chunked 的同时又写了 Content-Length，Nginx 会优先信任后者并丢弃 chunked。需检查后端逻辑，确保二者不共存：
- Spring Boot：确认未手动设置
Content-Length，且server.tomcat.use-relative-redirects等配置不触发隐式头写入 - PHP：避免在输出前调用
header('Content-Length: ...')；使用 CLI 或 FPM 模式时注意 SAPI 层是否自动补头 - Node.js/Express：禁用
res.flushHeaders()之外的显式 length 设置
验证与兜底建议
部署后，用 tcpdump 或 Wireshark 抓包，查看 Nginx 到客户端的 TCP 流中是否真实出现分块长度行；同时检查 Nginx error log，确认无 upstream sent invalid chunked response 类报错。若仍不稳定，可临时加 proxy_buffer_size 4k; 控制单次读取上限，减少粘包风险。
