Nginx upstream prematurely closed connection 错误本质是上游连接被过早关闭，主因是upstream块中keepalive_requests值过小（如默认100），导致连接在处理少量请求后即被强制关闭；需在upstream块内显式设置keepalive_requests（建议500～2000），并确保其不超过后端服务（如Tomcat的maxKeepAliveRequests）限制，同时配套配置keepalive、proxy_http_version 1.1和proxy_set_header Connection ''。
这个问题本质是 Nginx 与上游服务器（源站）之间的长连接被过早关闭，不是客户端报错，而是 Nginx 在转发请求时发现上游连接已断，从而返回 502 Bad Gateway 或日志中出现 upstream prematurely closed connection 类错误。根本原因在于 upstream 块中 keepalive_requests 设置太小，导致连接在处理少量请求后就被强制关闭。
确认是否是 keepalive_requests 触发的问题
先检查 Nginx error log，典型线索包括：
upstream prematurely closed connection while reading response header from upstreamrecv() failed (104: Connection reset by peer) while reading response header from upstream- 同一 worker 进程频繁复用/新建上游连接，且
netstat -an | grep :端口 | wc -l显示 ESTABLISHED 连接数波动剧烈
再核对 upstream 配置中是否设置了 keepalive_requests，且值明显偏低（如默认 100 或更小）。
调整 upstream 中的 keepalive_requests
该参数控制「单个长连接最多转发多少次请求给同一个 upstream server」。它和 HTTP 块里的同名参数互不影响，专用于反向代理链路。
- 在
upstream块内显式设置，例如：upstream backend {<br> server 192.168.1.10:8080;<br> keepalive 32;<br> keepalive_requests 1000;<br>} - 建议值：若源站 QPS 稳定在 500，平均每个连接每秒处理 5 个请求，则设为 1000 可支撑约 200 秒连接寿命；高并发场景建议 ≥500～2000
- 注意：该值不能超过源站自身连接处理能力，比如 Tomcat 的
maxKeepAliveRequests（默认 100），否则 upstream 会主动断连
同步检查并匹配源站的 Keepalive 配置
Nginx 的 keepalive_requests 再大，也受限于后端服务的配合：
- Tomcat：检查
conf/server.xml中 Connector 的maxKeepAliveRequests（默认 100）和keepAliveTimeout - Node.js（HTTP Server）：需确保未禁用
keepAlive，且server.maxHeadersCount、server.timeout合理 - Spring Boot 内嵌 Tomcat：可通过
server.tomcat.max-keep-alive-requests配置项调整 - 务必让 Nginx 的
keepalive_requests≤ 源站对应限制，否则源站先关连接，Nginx 就会报错
补充关键配套配置
仅调大 keepalive_requests 不够，还需保证连接池真正启用并稳定：
-
keepalive N必须存在（如keepalive 32），它定义每个 worker 进程可缓存的空闲连接数，没有它，keepalive_requests不生效 -
keepalive_timeout（upstream 级）建议设为 60～300 秒，避免连接空闲过久被中间设备（防火墙、LB）中断 - 确保 proxy_http_version 设为 1.1，且传了
Connection: keep-alive头：proxy_http_version 1.1;<br>proxy_set_header Connection '';
（清空 Connection 头，由 Nginx 自动管理）
