connection reset 错误是tcp对端（服务端或中间设备）主动发rst包导致，非java自身问题；常见原因包括服务端崩溃、代理超时、防火墙回收、客户端写入时对端已关闭读端。
Connection reset 错误到底是谁干的
这个异常不是 Java 本身出问题，而是对端（服务端或中间设备）主动关闭了连接，且未按 TCP 正常挥手流程来——直接发 RST 包。Java 的 SocketInputStream.read() 或 OutputStream.write() 在读写时撞上 RST，就抛 SocketException: Connection reset。
常见触发点：
- 服务端进程崩溃、被 kill 或 OOM 后立即退出
- Nginx / HAProxy 等代理设置了
proxy_read_timeout或timeout client，空闲连接超时后直接 RST（不是 FIN） - 防火墙、运营商 NAT 设备在连接空闲一段时间后静默回收连接
- 客户端发送数据时，对端 socket 已 close() 但未 shutdown(SHUT_WR)，底层 TCP 栈回 RST
怎么快速定位是哪一环断的
别急着改代码，先分层验证链路：
- 用
telnet host port或nc -zv host port测试基础连通性；能通说明网络层没问题 - 抓包看 RST 来源：
tcpdump -i any 'host target_ip and port target_port'，过滤出含[R.]标志的包，看是 client 还是 server 发的 - 检查服务端日志：是否在报错前有
java.io.IOException: Broken pipe或 JVM crash 日志 - 确认中间件配置：Nginx 的
proxy_next_upstream error timeout http_502;不会掩盖 RST，但会重试；真正要查的是proxy_timeout类参数
Java 客户端如何避免被 RST 打死
重点不是“捕获异常然后重试”，而是让连接行为更健壮：
立即学习“Java免费学习笔记（深入）”；
- 禁用 Nagle 算法：
socket.setTcpNoDelay(true)，减少小包合并延迟，降低因写入阻塞导致的超时风险 - 设置合理的 SO_TIMEOUT：
socket.setSoTimeout(5000)，防止 read() 卡死，但注意它不防 write() 时的 RST - 写之前先检查连接状态：
if (socket.isConnected() && !socket.isClosed() && socket.isInputShutdown() == false)，但这只是快照，不能替代重试逻辑 - 关键：所有 socket 操作必须包裹 try-catch，且对
SocketException做区分处理——getMessage().contains("Connection reset")视为可重试错误，其他如"Connection refused"则不可重试
服务端为什么突然发 RST
最常被忽略的是资源耗尽和配置错位：
- JVM 堆外内存不足（DirectByteBuffer 泄漏）或文件描述符打满（
ulimit -n默认常为 1024），新 accept 失败，旧连接可能被内核强制清理 - Netty 用户要注意：
ChannelConfig.setWriteBufferHighWaterMark()设置过低，write() 积压触发自动 close，下游收 RST - Spring Boot 内嵌 Tomcat 默认启用 keep-alive，但
server.tomcat.connection-timeout=20000是指 idle 超时，超时后发 FIN；若设为 -1（禁用超时），又没配连接池回收策略，容易堆积僵尸连接 - Linux 内核参数：
net.ipv4.tcp_fin_timeout影响 TIME_WAIT 回收，但net.ipv4.tcp_rmem/tcp_wmem配得太小会导致缓冲区溢出，触发 RST
真实环境里，RST 往往是最后一根稻草——前面已经积压了连接泄漏、线程卡死、GC 长停等一堆问题。只盯着 SocketException 改代码，大概率修了表象，漏了根子。
