该错误本质是Nginx默认以HTTP/1.0代理后端，而上游服务按HTTP/1.1返回chunked响应，因协议不兼容导致解析失败；需同时配置proxy_http_version 1.1和proxy_set_header Connection ""方可解决。
这个错误本质是 Nginx 在代理请求时，从后端（upstream）收到的 HTTP 响应格式不符合预期，最常见、最典型的场景就是 HTTP/1.0 与 HTTP/1.1 协议不兼容引发的 chunked 编码解析失败。Nginx 默认用 HTTP/1.0 连接后端，但若后端（如 Spring Boot、Tomcat、Node.js 等）按 HTTP/1.1 返回分块响应（Transfer-Encoding: chunked），Nginx 就会因协议版本不匹配而拒绝该响应，日志中就出现 upstream sent invalid chunked response while reading upstream。
核心原因：HTTP 版本错配导致 chunked 解析失败
HTTP/1.0 不支持分块传输编码（chunked encoding），而 HTTP/1.1 支持。当后端服务明确声明使用 HTTP/1.1 并返回 chunked 响应时，Nginx 若仍以 HTTP/1.0 发起上游连接，就无法正确识别和拼接 chunked 数据流，最终丢弃响应并报错。此时客户端常表现为：
- 空响应（ERR_EMPTY_RESPONSE）
- 502 Bad Gateway
- 下载接口卡住或中断
- Postman 或 curl 收不到 body，但直接访问后端正常
关键配置：必须同时启用 HTTP/1.1 并清理 Connection 头
仅改协议版本还不够——HTTP/1.1 的持久连接（keep-alive）依赖 Connection 头控制，而 Nginx 默认会把客户端的 Connection: keep-alive 原样透传给后端，这可能干扰后端对连接生命周期的判断，尤其在反向代理链路中容易触发异常关闭。因此需两条配置协同生效：
-
proxy_http_version 1.1;—— 显式要求 Nginx 与后端使用 HTTP/1.1 协议通信 -
proxy_set_header Connection "";—— 清空该 header，避免透传干扰
这两条必须同时出现在 location 或 server 块中，缺一不可。例如：
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
排查路径：从日志到协议确认
不要跳过验证环节，按顺序确认可快速定位是否为协议问题：
- 查 Nginx
error.log：确认报错完整信息是否含invalid chunked response - 查 Nginx
access.log：看对应请求的$request字段，确认客户端发起的是 HTTP/1.1（如"GET /xxx HTTP/1.1"） - 抓包或后端日志：检查后端实际返回的响应头，是否存在
Transfer-Encoding: chunked或HTTP/1.1 200 OK - 绕过 Nginx 直连后端测试：用 curl -v http://内部IP:端口/xxx，观察响应是否完整、是否有 chunked 头
延伸注意：其他“invalid response”类错误的区分
类似报错名但成因不同，需结合上下文区分：
-
upstream sent invalid header：后端响应头含非法字符（如空格、控制符），常见于Cache-Control: public, max-age = 3600中多出空格，Nginx 1.21+ 会严格拒绝 -
upstream sent no valid HTTP/1.0 header：后端未返回符合 HTTP 规范的首行（如缺失HTTP/1.1 200 OK）或响应头严重损坏 -
upstream prematurely closed connection：后端提前断连，常因超时、OOM、主动 kill 连接，与协议无关
协议冲突类问题解决起来不复杂，但容易忽略版本协商细节。加两行配置、重载一次，基本就能闭环。
