Connection reset by peer本质是TCP层RST包触发的强制断连，非HTTP错误，表明连接已建立但对端异常终止；常见原因包括后端fd耗尽、backlog溢出、进程崩溃、keepalive超时及防火墙中断。
Connection reset by peer 的本质是 TCP RST 包触发的连接中断
这个错误不是 HTTP 层面的返回码，而是操作系统内核在 TCP 层收到对端发来的 RST（Reset）标志位后，向应用层（这里是 Nginx）抛出的 ECONNRESET 系统错误。它表明：连接已建立（三次握手完成），但某一方在数据传输阶段主动、异常地终止了连接。
关键点在于——RST 是“强制断连”，不走四次挥手流程，无法携带应用层语义。因此 Nginx 日志中出现 connection reset by peer while reading response header from upstream，说明它正尝试从后端读取响应头时，后端突然发来 RST，连接瞬间失效。
后端主动发送 RST 的常见底层原因
绝大多数情况下，RST 来自上游服务（upstream），而非客户端或中间设备。根本原因通常落在系统资源、连接管理或程序逻辑层面：
-
文件描述符（fd）耗尽：后端进程打开的 socket 句柄数达到 ulimit 限制（如 10240），新 accept() 失败，内核直接回 RST 而非 SYN-ACK 后排队；可通过
lsof -p $PID | wc -l和ulimit -n验证 -
已完成连接队列溢出：Linux 内核 listen() 的
backlog参数设得太小，高并发下客户端完成三次握手后被丢弃，内核回 RST；golang net/http 默认 backlog 为 128，Java Tomcat 可调acceptCount - 后端进程崩溃或异常退出：进程在处理请求中途 panic、OOM Killer 杀死、或未正确关闭 socket 就退出，残留连接由内核清理并可能触发 RST
-
Keepalive 连接被后端单方面关闭：Nginx 开启了 upstream keepalive（如
keepalive 32;），但后端服务空闲超时后主动 close() 连接，而 Nginx 下次复用该连接时，首次 write/read 即收到 RST - 防火墙/NAT 设备超时踢除连接：云厂商 SLB、企业防火墙等对空闲长连接有 60–300 秒会话超时，超时后设备不再转发后续包，后端发 FIN 或 RST 时 Nginx 收不到，但下次发包时对方回 RST
Nginx 侧如何暴露和加剧该问题
Nginx 本身不生成 RST，但它对上游连接的复用策略和超时设置，会放大后端不稳定的影响：
- 默认不启用 upstream keepalive：每个请求新建 TCP 连接，若后端连接池小或响应慢，易触发 TIME_WAIT 堆积与端口耗尽，间接导致新连接被 RST
-
proxy_*_timeout 设置过短：如
proxy_read_timeout 5;，后端处理稍慢（如 DB 查询卡顿），Nginx 主动 close 连接，但后端可能仍在写响应，此时后端继续写入已关闭 socket，触发 SIGPIPE 或内核回 RST -
健康检查缺失或粒度粗：仅靠
max_fails=1 fail_timeout=10s无法感知后端连接级异常（如 fd 满但进程仍存活），故障节点持续接收流量 -
日志中 upstream_status 为空或为 “–”：这往往对应 RST 场景——Nginx 还没读到任何响应数据就断连，无法记录状态码，只留下
reset by peer错误
定位与验证的关键方法
不能只看 Nginx 日志，必须分层抓取证据链：
-
在 Nginx 机器上 tcpdump 抓包：过滤 upstream IP 和端口，观察是否出现
[R.]或[R]标志；重点看 RST 出现在三次握手后、还是在 HTTP 请求发出后、还是在等待响应时 -
检查后端机器的连接状态：用
ss -s看 total、tcp established、TIME-WAIT 数量；用netstat -tnp | grep :$PORT | awk '{print $6}' | sort | uniq -c统计连接状态分布 -
比对时间窗口内的指标：将错误日志时间戳与后端
dmesg | tail（OOM）、top -b -n1（CPU/内存尖刺）、cat /proc/$PID/status | grep -i 'fd'（句柄使用率）对齐 - 复现最小场景：用 curl 或 go client 直连后端服务，模拟相同请求头与 body，观察是否稳定复现 RST；再对比通过 Nginx 代理后的表现差异
