nginx出现“connection reset by peer”错误，本质是tcp连接被对端主动重置，需通过日志定位rst来源（客户端/上游/网络设备），重点排查上游服务超时、崩溃、配置不匹配及中间防火墙或负载均衡器空闲断连。
排查 Nginx 错误日志中出现的“网络连接重置”（如 connection reset by peer、Connection refused、Broken pipe、recv() failed (104: Connection reset by peer) 等）问题，核心是确认 TCP 连接在哪个环节被主动关闭。这类错误通常不是 Nginx 自身崩溃，而是上游服务、中间网络或客户端提前终止了连接。
定位具体错误类型和时间点
先从 error.log 中精准提取线索：
- 用
grep -i "reset\|refused\|broken\|pipe" /var/log/nginx/error.log筛出相关报错 - 重点关注报错前后的 时间戳 和 请求 URI，判断是否集中于特定接口或时段
- 区分是
upstream prematurely closed connection（上游关了）还是client prematurely closed connection（客户端关了）——前者带upstream字样，后者常含client或while reading response header from upstream
检查上游服务是否异常断连
绝大多数 “connection reset by peer” 来自上游（PHP-FPM、Node.js、Java 应用等）主动 reset socket，常见原因包括：
- 上游进程崩溃或被 OOM killer 终止（查
dmesg | grep -i "killed process"） - 上游设置了比 Nginx 更短的 keepalive timeout，连接空闲时先关闭（例如 Tomcat 的
connectionTimeout或 Node.js 的server.timeout） - 上游应用代码中未正确处理长连接，或在响应生成中途抛出未捕获异常导致进程退出
- 使用 Unix socket 时权限不匹配（Nginx worker 用户无法写入 socket）或 socket 文件被意外删除
验证网络与防火墙层是否干预
即使服务在运行，中间链路也可能触发 RST：
- 用
telnet upstream_host port或nc -zv upstream_host port测试基础连通性 - 检查防火墙（iptables/ufw/firewalld）是否对长连接或空闲连接做了超时踢出（如 conntrack 超时策略）
- 云环境注意安全组、负载均衡器（如 AWS ALB/NLB）的空闲超时设置，默认常为 60–3600 秒，若短于 Nginx 的
keepalive_timeout，就会发 RST - TCP 层抓包辅助判断：
tcpdump -i any port upstream_port -w reset.pcap，用 Wireshark 查看谁发的 RST 包
核对 Nginx 与上游的 keepalive 配置一致性
不匹配的 keepalive 设置极易引发静默重置：
- Nginx upstream 块中启用长连接：
keepalive 32;（保持 32 个空闲连接） - 对应调整
proxy_http_version 1.1;和proxy_set_header Connection '';，避免 HTTP/1.0 强制关闭 - 确保
keepalive_timeout（Nginx 端） > 上游服务的连接空闲超时值，否则 Nginx 复用已失效连接 - 若上游用域名，确认 DNS 缓存未过期且解析稳定（
dig upstream.domain+ 对比upstream_addr字段）
