“connection reset by peer”本质是tcp rst报文强制断连，需先用tcpdump定位rst源ip（本机→服务端问题，对端→下游或中间设备），再验证监听状态、排查连接队列溢出/孤儿连接超限、检查slb/nat空闲超时及应用层close()或so_linger=0等主动rst行为。
遇到“Connection reset by peer”日志，说明对端已主动发送 TCP RST 报文终止连接。这不是随机错误，而是内核或应用层明确发出的拒绝信号。排查关键在于分清 RST 是谁发的、为什么发、在哪个环节发的。
一、先确认 RST 来源方向
用 tcpdump 快速定位 RST 发出方：
- 执行
tcpdump -i any 'tcp[tcpflags] & (tcp-rst) != 0' -nn -c 5，抓到 RST 包后看源 IP 和源端口 - 若源 IP 是本机（如 192.168.1.100:8080），说明是本地服务或内核主动重置，需查服务状态和系统参数
- 若源 IP 是对端（如 10.20.30.40:5432），说明问题在下游服务、中间设备（LB/网关/防火墙）或对方进程异常
- 注意 RST 是否带 ACK：带 ACK 表示是对某个具体报文的响应（如乱序包）；不带 ACK 多为拒连（如端口无监听）
二、检查服务端是否真在监听且能响应
别只信 netstat 显示“LISTEN”，要验证连接能否真正建立：
- 运行
ss -tlnp | grep :端口号，确认进程 PID 和监听地址（0.0.0.0 还是 127.0.0.1） - 用
telnet 目标IP 端口或nc -zv 目标IP 端口测试基础连通性 - 若 telnet 能连上但很快断开，再抓包看是否 SYN-ACK 后紧跟着 RST+ACK —— 这往往指向半连接队列溢出或孤儿连接数超限
- 查内核指标：
netstat -s | grep -i "listen\|orphan"，重点关注 “times the listen queue overflowed” 和 “orphaned sockets” 计数
三、排查中间网络设备干扰
云环境或企业网中，RST 常由非终端设备发起：
- 检查负载均衡器（SLB/ALB）健康检查失败策略：后端实例未通过探测时，LB 可能直接 RST 新建连接
- 查看安全组/NACL 规则：是否限制了连接空闲时间（如 AWS ALB 默认 60 秒 idle timeout），超时后新数据包会触发 RST
- 确认 API 网关或服务网格（如 Istio）是否启用了连接驱逐、熔断或协议校验（如 HTTP/2 帧格式错误导致代理回 RST）
- 若使用 NAT 网关，检查其连接跟踪表是否耗尽（
conntrack -S查 count 和 max）
四、验证应用与 socket 行为是否合规
很多 RST 是代码逻辑直接触发的：
- 检查服务端是否在读完请求后立即 close() socket，而没等客户端发 FIN —— 特别是短连接场景下易引发客户端收到 RST
- 确认是否设置了
SO_LINGER且 linger time=0：调用 close() 会跳过四次挥手，直接发 RST - 观察是否有大量 TIME_WAIT 或 CLOSE_WAIT：前者说明服务端主动关闭频繁；后者说明服务端未正确 close，连接卡在等待对方关闭
- 查应用日志是否伴随 panic、OOM kill、core dump 或 SIGTERM —— 进程崩溃时内核会清理 socket 并对后续数据回 RST
