Connection reset by peer本质是TCP层RST包触发的强制断连，需先通过日志关键词（如upstream prematurely closed）定位RST来自上游，再抓包确认源IP，最后排查后端崩溃、超时配置不匹配或连接复用异常。
排查 Nginx 轮询（round-robin）转发时因连接重置（Connection reset）导致的请求丢失，核心是确认失败是否发生在 Nginx 与上游（upstream）之间，并定位重置源头——是上游服务主动断连、网络中间件干预，还是 Nginx 自身配置不当。
检查 Nginx 错误日志中的关键线索
Nginx 在 upstream 连接被重置时通常记录 connection reset by peer 或 upstream prematurely closed connection 等错误。重点关注：
- 错误行中是否含
upstream: "http://upstream_name"，确认问题出在代理环节而非客户端侧 - 时间戳是否集中出现，是否与上游服务发布、扩容缩容、GC 高峰或健康检查失败时段吻合
- 是否有大量
connect() failed (111: Connection refused)（说明上游进程未监听）或(104: Connection reset by peer)（说明连接建立后被对方强制关闭）
验证上游服务的连接行为和存活状态
连接重置几乎总是由上游服务发起（如进程崩溃、主动 close、超时 kill、负载均衡器拦截）。需确认：
- 上游应用是否在处理完响应后立即关闭连接（尤其 HTTP/1.0 或未设置
Connection: keep-alive） - 上游是否启用了连接空闲超时（如 Tomcat 的
connectionTimeout、Spring Boot 的server.tomcat.connection-timeout），且该值小于 Nginx 的proxy_read_timeout - 用
curl -v http://upstream_ip:port/path直连测试，观察 TCP 层是否在响应后立刻 RST；也可用tcpdump抓包确认 FIN/RST 包来源
调整 Nginx 代理层的关键超时与重试策略
默认配置易在上下游超时不匹配时丢请求。建议显式设置：
-
proxy_connect_timeout 5s;：建立 TCP 连接上限，避免卡在 SYN 阶段 -
proxy_send_timeout 30s;：发请求体到上游的超时（适用于大文件上传） -
proxy_read_timeout 60s;：从上游读响应头+体的总时限，应 ≥ 上游最长业务响应时间 -
proxy_next_upstream error timeout http_502 http_503 http_504;：允许在连接重置（error）、超时（timeout）等场景下自动重试其他节点 -
proxy_next_upstream_tries 3;和proxy_next_upstream_timeout 10s;：限制重试次数与时长，防雪崩
启用连接复用并确认协议一致性
频繁建连会放大重置风险。确保：
- 上游支持并开启了 HTTP Keep-Alive（如 Nginx upstream 中配置
keepalive 32;，并在 location 内加proxy_http_version 1.1;和proxy_set_header Connection '';） - 避免上游使用 HTTP/1.0 响应且无
Connection: keep-alive头，否则 Nginx 默认复用连接会失败 - 若上游为 gRPC，需改用
grpc_pass并启用http2，不可混用 HTTP/1.x 代理指令
不复杂但容易忽略的是：连接重置不是随机事件，它背后一定有上游的明确动作。从 Nginx 日志出发，逆向追踪 TCP 包和上游服务日志，比盲目调参更高效。
