Expert guidance for diagnosing…

# "Connection reset by peer" 排查指南

该错误表示TCP连接被对端（服务器或中间设备）强制关闭。每日20多次的低频出现，需从以下维度排查。

一、先明确排查方向

• 重点怀疑对象：连接池空闲连接超时、防火墙/NAT设备空闲回收、服务端主动断开
• 注意：此错误不一定是keepalive问题，keepalive只是排查项之一

二、确认是否为空闲连接被中间设备断开

• 查看报错时间分布：若错误集中在请求前间隔较长的场景（如定时任务、低峰期），大概率是空闲连接被回收
• 确认链路中间是否有防火墙、云负载均衡（如SLB、NAT网关），查询其空闲连接超时阈值（常见为几分钟到1小时不等）
• 抓包验证：tcpdump -i any host 目标IP port 目标端口 -w dump.pcap，观察RST包由谁发出

三、检查TCP keepalive配置

系统级（Linux默认参数通常不适合业务场景）：

```

cat /proc/sys/net/ipv4/tcp_keepalive_time # 默认7200秒，过长

cat /proc/sys/net/ipv4/tcp_keepalive_intvl

cat /proc/sys/net/ipv4/tcp_keepalive_probes

```

建议调优方向：

• tcp_keepalive_time 设为小于中间设备空闲超时的值（如600秒以内）
• Java应用可通过JVM参数 -Dtcp.keepalive=true 或代码中 socket.setKeepAlive(true) 启用（注意：时间参数仍取决于OS）

四、检查连接池配置（更常见的原因）

• Druid/HikariCP：确认 maxIdleTime / idleTimeout 是否小于服务端或中间设备超时
• 建议配置：
• 启用连接池的 testWhileIdle / keepaliveTime，定期验证连接
• 空闲超时设置小于链路上最短的超时阈值
• 检查数据库端 wait_timeout（若连接的是MySQL）

五、快速验证方法

1. 抓包确认RST来源（客户端还是服务端发出）

2. 复现后对比：调小keepalive_time或连接池保活间隔后，观察报错频率是否下降

3. 检查服务端是否有连接超时主动断开策略（如nginx keepalive_timeout、网关配置）

六、兜底措施

• 应用侧对 "Connection reset" 做重试机制（幂等接口）
• 记录错误发生时的连接空闲时长日志，加速定位

优先级建议：先查连接池空闲超时 → 再查中间设备超时 → 最后调OS keepalive参数。