Tomcat(Jersey)流式API直连正常，经NGINX无响应且报上游无效分块响应错误

嘿，这个问题我之前帮好几个开发者排查过——你遇到的upstream sent invalid chunked response while reading upstream错误，本质是NGINX认为Tomcat（Jersey）返回的分块编码响应不符合HTTP规范，或者两者在分块处理的逻辑上有冲突。咱们一步步来解决：

1. 先排查Jersey的流式响应实现 #

这是最常见的问题根源：

• 如果你手动构建流式响应，不要自己添加Transfer-Encoding: chunked头。Jersey和Tomcat会自动处理分块编码，手动添加会导致重复或格式错误的响应头，让NGINX识别失败。
• 检查StreamingOutput的实现逻辑，确保分块的格式完全符合HTTP规范：每个分块开头是十六进制的长度（不带前缀），然后是CRLF，接着是分块内容，再CRLF；最后必须是一个长度为0的分块（0\r\n\r\n）来结束响应。比如如果你的流式输出里漏掉了结束块，NGINX就会判定为无效分块。

2. 调整NGINX的反向代理配置 #

针对分块响应的冲突，有几个实用的配置调整：

• 强制使用HTTP/1.1通信：在对应的location块里添加以下配置，因为HTTP/1.1对分块编码的支持更稳定，避免HTTP/1.0的兼容性问题：

  proxy_http_version 1.1;
  proxy_set_header Connection "";
  

• 启用NGINX响应缓冲：让NGINX先把Tomcat的响应完整缓冲下来，再统一发给客户端，跳过实时分块转发。添加配置：

  proxy_buffering on;
  proxy_buffer_size 4k;
  proxy_buffers 8 4k;
  

  可以根据你的响应大小调整缓冲区参数，比如如果响应很大，就把proxy_buffers的数值调大。
• 忽略分块编码头（谨慎使用）：如果确认Tomcat的分块响应没问题，但NGINX还是报错，可以让NGINX直接转发响应，不处理分块头：

  proxy_ignore_headers Transfer-Encoding;
  

  这个方法要谨慎，因为可能会影响其他类型的响应。

3. 检查Tomcat的Connector配置 #

• 确认Tomcat的server.xml里的Connector配置没有禁用分块相关的功能，比如不要设置disableUploadTimeout="true"（这个虽然是上传超时，但可能间接影响长连接的流式响应）；同时确保connectionTimeout的设置足够长，避免流式响应还没完成就被Tomcat断开连接。
• 查看Tomcat的catalina.out日志，看看Jersey在处理流式请求时有没有抛出异常，比如IO异常导致响应中途中断，这也会让NGINX收到不完整的分块。

4. 抓包验证响应格式 #

如果上面的方法都没解决，建议用tcpdump或Wireshark抓取NGINX和Tomcat之间的流量，直接查看Tomcat返回的响应内容：

• 检查响应头里的Transfer-Encoding是不是chunked，有没有重复的头。
• 检查分块的格式：每个分块的长度是不是正确的十六进制，有没有正确的CRLF分隔，最后有没有结束块。

一般来说，先从Jersey的流式实现入手排查，再调整NGINX配置，大部分情况都能解决这个问题。

内容的提问来源于stack exchange，提问作者galusben