Connection reset by peer本质是TCP层RST包导致的强制断连，需先通过日志上下文（如upstream/client关键词）定位方向，再抓包确认源IP，最后排查后端崩溃、超时配置不匹配、资源耗尽或协议违规等根因。
遇到 Nginx 代理后端服务时大量出现 Connection reset by peer，本质是 TCP 层收到对端发来的 RST 包——连接已建好，但对方“突然挂断”，不是连不上，而是被强行中断。排查关键在于快速锁定 RST 来源（客户端？后端？中间设备？），再聚焦真实根因。
看日志，先分清 RST 大致来自哪一端
错误日志本身不写明谁发的 RST，但上下文线索很明确：
- 日志含 while reading response header from upstream 或 upstream prematurely closed connection → RST 极大概率来自后端服务（如 Java、Node.js、Go 应用）
- 错误集中在同一 upstream 地址（如 upstream: "http://10.0.0.5:8080"），且 upstream_status 字段为空或为 “–” → 后端未返回任何响应就断连
- 错误分散在大量不同客户端 IP、不同 URL、时间点不集中 → 更可能是客户端侧异常（浏览器关闭、移动端切网、脚本未 abort）
- 错误集中爆发在压测开始后几分钟，而 CPU/内存无压力 → 需检查 Nginx 自身配置是否触发了防御性断连（如超时过短、连接队列满）
抓包确认 RST 真实发送方
仅靠日志易误判，tcpdump 是最直接证据：
- 在 Nginx 服务器执行：
tcpdump -i any 'tcp[tcpflags] & (tcp-rst) != 0' -nn -c 20 - 观察输出中 RST 包的源 IP：是后端地址（如 10.0.0.5:8080）→ 后端应用层主动 close；是客户端 IP → 问题出在调用方或中间网络设备（WAF、防火墙、云 SLB）
- 配合 Wireshark 查看 RST 前的交互：是否刚完成 TLS 握手就 RST？那可能是 SSL 协议不兼容或证书问题
重点查后端服务是否主动断连
绝大多数 RST 来自后端，常见原因有：
- 后端进程崩溃或被 OOM Killer 杀掉：运行
dmesg | grep -i "killed process"查系统级终止记录 - 后端 keepalive 超时比 Nginx 短：例如 Tomcat
connectionTimeout=30s，而 Nginx 使用 HTTP/1.1 复用连接，后端空闲先关，Nginx 下次复用即收 RST - 后端资源耗尽：检查文件描述符（
lsof -p $PID | wc -l对比ulimit -n）、已完成连接队列溢出（如 Go 默认 backlog 仅 128） - 响应协议违规：HTTP 状态行缺失、
Content-Length与实际体长不符、响应头过大（如 Tomcat 需调maxHttpHeaderSize）
检查 Nginx 关键配置是否匹配后端能力
配置不合理会放大 RST 概率，尤其注意四类超时与缓冲区：
-
proxy_read_timeout：必须 ≥ 后端最长响应时间；它是两次读之间的空闲等待，不是整个响应耗时 -
keepalive_timeout（Nginx 与 client）和 upstream 的keepalive数值，需大于后端空闲超时 -
client_max_body_size/client_header_buffer_size：请求体或头过大时，可能不报 413 而是直接 RST - 系统级限制：
net.core.somaxconn和 Nginxlisten ... backlog=需同步调大，否则高并发下内核直接丢连接并回 RST
