做实时推送、在线IM、行情订阅这类系统，只要网络一波动，WebSocket连接就可能悄悄断掉，而你的代码如果不做处理，用户那边就永远卡在一个"连接已断开"的假死状态。这算是Java后端做WebSocket最常踩的坑之一：客户端没有心跳、没有重连、没有消息补偿，断线之后一切都停摆了。这篇文章我想围绕"java-websocket断线重连"这个主题，把一套能直接落地的完整方案拆开讲透，从为什么断、怎么检测，到用什么策略重连、断线消息怎么补发，全部用Java代码体现，适合正在做实时通信功能、或者想在项目里接入WebSocket但对稳定性心里没底的开发者参考。
我早期做某个实时行情推送项目时，服务端每天晚上都会自动发版重启，客户端连接瞬间全断。当时客户端逻辑很简单：打开连接、收数据、断开就提示"网络异常"，然后用户得手动刷新页面。这个体验有多糟糕，用过的人都知道。后来我把断线重连做进客户端，才彻底告别了那种"一断就死"的状态。下面就把这套方案的经验和代码整理出来，希望能帮你少走点弯路。
1. 为什么WebSocket连接说断就断：先搞清楚病根
不先把断线原因摸清楚，后面的重连机制做得再花哨也是瞎忙活。WebSocket连接不是一根埋在地下的水管，埋好就永远不漏。它是一条基于TCP的持久连接，TCP层一旦出问题，上层协议一点办法都没有。我把日常工作中最常见的断线原因分成两类，一类是网络环境的"隐形杀手"，一类是服务端和客户端自己的"人为事故"。
1.1 网络环境的隐形杀手
第一类就是NAT超时。在公司上网、或者用手机流量访问服务器时，中间基本都会经过一层NAT设备（路由器、运营商网关）。NAT设备为了节省资源，会在映射表里给每条连接设置一个超时时间，正常情况下可能几分钟到几十分钟不等（常见的有2分钟、4分钟、5分钟）。如果这条TCP连接在这段时间内没有任何数据往来，NAT设备就会静默地把这条映射记录删掉。结果就是：客户端以为连接还活着，服务端也以为连接还活着，实际上中间的链路已经断了。后续任何数据包都发不过去，而客户端只有在真正尝试发送时才会感知到异常。
第二类是代理和网关的空闲超时。如果你在WebSocket前面挂了Nginx、HAProxy这类反向代理，它们默认会对空闲连接做回收处理，比如Nginx的proxy_read_timeout默认值是60秒，意味着60秒内如果没有从上游读到数据，连接就会被主动关闭。很多WebSocket服务端的默认心跳间隔又恰好超过这个值，那就必然会出现"莫名其妙掉线"的问题。
第三类是网络切换。手机从WiFi切到4G/5G、或者从4G切到5G，IP地址和TCP连接都会失效。这类断线是瞬时的，客户端根本来不及知道，只有在下次心跳或者发送数据时才会发现连接已经废了。
1.2 服务端与客户端的主动断连
服务端主动断开最常见的就是发版、重启。服务进程一停，所有连接立刻被操作系统回收。线上发布如果没做过优雅停机，前端大概率会看到一大批1006异常码。还有一种情况是服务端自己做了空闲踢人，比如某些IM系统规定超过一定时间没有活动的连接直接关闭，这也是合理的资源保护策略。
客户端这边的主动断连就更多了，最常见的是程序出错、内存溢出导致崩溃，或者客户端进程被系统回收。还有一种容易被忽略的场景：客户端App进入后台后，系统把网络权限收走了，连接虽然没有触发onClose，但实际上已经不可用，这时候如果唤醒回前台，必须先做一次连接活性检测。
1.3 状态码隐含的信息
排查断线原因时，WebSocket的关闭状态码是很重要的线索。我整理了一份常见状态码和对应的处理建议，你可以直接参考。
| 状态码 | 含义 | 常见场景 | 是否需要重连 |
|---|---|---|---|
| 1000 | 正常关闭 | 两端协商后主动关闭 | 视业务情况，不要无脑重连 |
| 1001 | 服务端正在重启 | 服务端发版、停机维护 | 需要，且要配合等待期 |
| 1002 | 协议错误 | 数据格式不符合规范 | 检查代码，不建议立即重连 |
| 1006 | 异常关闭 | 网络中断、TCP连接被重置 | 必须重连 |
| 1011 | 服务端内部错误 | 服务端程序异常 | 需要，但要注意频率 |
看到1006这种异常关闭码，基本不用多想，直接进重连流程。而如果是1000这种正常关闭，很可能是用户主动退出或者服务端主动踢人，这时候要么不重连，要么延迟一段时间再连，否则会给服务端造成压力。这个区分必须要在重连逻辑里做，不能把所有关闭都当成故障处理。
2. 方案选型：Java生态里的WebSocket客户端到底怎么选
明确了断线原因之后，接下来要解决"用什么来做"。Java生态里做WebSocket客户端，常见的方案就那么几个：原生API、Java-WebSocket库、Spring WebSocket、Netty、OkHttp。很多人一开始会纠结，其实只要搞清楚自己的场景，选择并不难。
2.1 三套主流方案横向对比
我列一张对比表，把最常见的选择放在一起看：
| 维度 | Java-WebSocket库 | Spring WebSocket | Netty | 原生JDK API |
|---|---|---|---|---|
| 封装程度 | 高，回调清晰 | 高，但偏服务端 | 低，需自己封装 | 低，几乎没有封装 |
| 学习成本 | 低，API简单 | 中，需理解Spring抽象 | 高，需理解异步模型 | 中 |
| 重连支持 | 无内置，需自己写 | 无内置，需自己写 | 无内置，需自己写 | 需自己写 |
| 心跳支持 | 有Ping/Pong封装 | 需自己编帧 | 需自己实现 | 需自己实现 |
| 适用场景 | 独立客户端、快速集成 | Spring全家桶项目 | 高并发网关、自研协议 | 极简单的连接需求 |
其实看这张表就很清楚了：所有方案都没有现成的断线重连和心跳机制，最终都要自己写。区别只是底层库帮你做了多少。Spring WebSocket虽然生态完整，但它的设计重心在服务端，处理起客户端连接来反而没那么顺手。Netty性能好但开发量真的大，除非你在做一个自定义协议的网关，否则用Netty做WebSocket客户端有点大材小用。原生JDK那个API我是不建议直接用的，写起来繁琐，而且对Ping/Pong支持不够友好。
2.2 为什么我推荐Java-WebSocket库做底层
我最终选择了Java-WebSocket这个开源库，主要看中三点。
第一，API设计非常直观。你需要做的事就是继承WebSocketClient类，然后重写四个方法：onOpen、onMessage、onClose、onError。这种"事件回调"模型和前端写onmessage、onclose的习惯几乎一模一样，学习曲线极其平缓。
第二，它内置了WebSocket协议层的心跳支持。WebSocketClient类直接提供了sendPing()和sendPong()方法，不需要自己拼接控制帧的字节。不要小看这一步，如果直接用Netty或者原生API，光是控制帧的编解码就要折腾一阵子。
第三，它足够轻量。整个库核心代码量不大，没有依赖一堆Spring上下文，非常适合嵌在任何Java项目里当客户端用。而且它的事件分发在单独的IO线程里执行，配合onClose做重连触发是自然顺畅的。
基于这些原因，后面所有示例代码我都用Java-WebSocket库来写。如果你用的是Spring Boot项目，代码一样能直接整合进去，没有任何冲突。
3. 断线重连三大机制详细拆解
一个健壮的断线重连方案，绝对不只"断线了再连"这一个动作。我习惯把它拆成三个机制：心跳检测、重连策略、消息补偿。这三者缺一不可。只有心跳没有重连策略，连上又断，反复横跳；只有重连没有心跳，连接假死时你根本不知道要重连；重连成功了不处理断线期间的消息，用户就会看到数据丢失。
3.1 心跳检测：如何确认连接是真死还是假死
先说心跳。TCP协议层面其实有保活机制，即TCP KeepAlive，默认情况下需要两个小时才探测一次，对WebSocket这种实时业务来说完全不够用。所以必须在应用层做心跳。
WebSocket协议本身定义了Ping和Pong两种控制帧。Ping是客户端或服务端主动发起的心跳探测包，收到Ping的一方必须回一个Pong。在Java-WebSocket里，客户端可以调用sendPing()发送Ping帧，并通过重写onWebsocketPong或类似回调来接收Pong帧。这个机制用来做连接活性检测是恰到好处的。
具体实现思路是：客户端每隔一段时间（比如30秒）发送一个Ping，并记录上次收到Pong的时间戳。每次收到Pong就更新这个时间戳。每次发送Ping之前，先检查当前时间和最后Pong时间之差。如果超过某个阈值（比如60秒），就认为连接已经"假死"，主动调用client.close()关闭当前连接，从而触发onClose回调，进而走进重连流程。
这里要给一个基准参数建议，我实测下来比较稳的组合是：心跳间隔30秒、超时阈值60秒。这么设置的原因是，大部分NAT设备的空闲超时在2到5分钟之间，30秒的间隔能保证连接在NAT超时之前就有数据经过，链路不会被动删除。而60秒的超时阈值也给了服务端和网络足够的时间去处理偶发的尖峰延迟。如果网络条件本身就差，阈值可以放到90秒甚至120秒，但不能无限放大，否则心跳就失去了意义。
还有一点要特别注意：心跳必须用Ping/Pong控制帧，而不是发送普通业务消息。原因有两点，一是业务消息需要业务层响应，服务端如果不做回执，你根本不知道消息是否送达；二是Ping/Pong帧在协议层面就有"收到必回"的语义，配合它来判断连接活性是标准的做法。
3.2 重连策略：固定间隔还是指数退避
连接断开后，多久重连一次？新手最容易犯的错就是写一个固定间隔的重连，比如每5秒重连一次。这个方案在客户端数量少的时候问题不大，但客户端一多，瞬时断连（比如服务端重启）就会引发"惊群效应"：成千上万个客户端同时重连，服务端刚起来就被重连请求打爆，导致部分连接再次失败，然后又触发重连，形成恶性循环。
正确的做法是指数退避 + 随机抖动。核心思路是：第一次重连等待1秒，第二次2秒，第三次4秒，第四次8秒……计算方式是指数递增，到某个上限后封顶（比如60秒），并且在每次计算出的延迟基础上，加一个0到500毫秒之间的随机数。随机抖动的目的就是让所有客户端的重连请求错开，避免扎堆。
指数退避为什么靠谱？因为连续重连失败往往意味着服务端或者网络出了大问题，短时间内反复重连只会加剧问题。指数退避天然惩罚了"连续失败"的情况，给服务端留出恢复时间。
那要不要设置最大重连次数？我的建议是：保留一个最大次数，比如连续重连10次之后仍然失败，就不要再继续高频重连了，改成长时间间隔的慢速重试（比如每5分钟一次），同时抛出一个告警事件让上层逻辑感知到"客户端已处于离线状态"。这里的关键是不能无限重试把服务端压垮，也不能一次失败就彻底放弃。保持底线机制，然后交给业务层决定是提示用户还是继续等待。
3.3 消息补偿：断线期间的消息怎么不丢
心跳和重连解决了"连接恢复"的问题，但连接断开的那段时间里，用户端正常应该收到的消息，以及用户端想发出去的消息，该怎么办。这是很多自研WebSocket方案容易忽略的部分。
消息补偿有两条链路：一条是客户端发给服务端的消息，另一条是服务端推给客户端的消息。
先看客户端发消息这条链路。如果客户端发现连接已断开，此时调用send()大概率会失败或者消息被静默丢弃。我的做法是设计一个消息队列：发送消息时先判断连接是否打开，如果打开就直接发，如果没打开就先把消息放进队列。等重连成功后，再统一把队列里的消息补发出去。这里面有个关键点——消息一定要有全局唯一的幂等标识。比如给每条消息生成一个UUID作为messageId，服务端拿到这个消息后先查重，如果处理过就直接返回ACK，不再重复处理。这样即使重发多次，也不会造成重复数据。
再看服务端推送消息这条链路。重连成功后，客户端要主动向服务端发起一次"状态同步"或"增量拉取"。比如记录一下断开前收到的最后一条消息的序号（lastSeq），重连成功后发送一个sync请求带上这个序号，服务端把后续消息补推过来。这个方案的前提是服务端有消息持久化和按序发送的能力，但对于IM、行情这类系统，这本来就是应该有的。
4. 完整实战：从零打造一个可用的断线重连客户端
理论知识讲完了，下面进入动手环节。我会给你一套能直接复制到项目里用的代码框架，包含依赖配置、核心客户端类、心跳管理器、重连策略以及Spring Boot的整合示例。代码不是我随手写的，是我在项目里反复验证过、去掉业务细节后的通用骨架。
4.1 项目依赖与工程结构
先用Maven建一个普通的Java项目，引入Java-WebSocket依赖。我这里用的是1.5.x版本，也是目前比较稳定的版本。
<dependency> <groupId>org.java-websocket</groupId> <artifactId>Java-WebSocket</artifactId> <version>1.5.4</version> </dependency>如果你用的是Spring Boot 2.x或3.x，还需要引入Spring的依赖管理，这个和WebSocket本身没有直接冲突。工程结构上我建议这样组织，代码分层会非常清晰：
com.example.ws ├── WsClient.java // 核心客户端封装，对外提供连接、发送、关闭接口 ├── HeartbeatManager.java // 心跳管理器，负责Ping/Pong检测 ├── ReconnectStrategy.java // 指数退避重连策略 ├── MessageQueue.java // 待补发消息队列 ├── MessageListener.java // 消息监听接口，业务方实现 └── SpringWsClientConfig.java // Spring Boot 配置类核心类之间的协作关系大致是：WsClient持有WebSocketClient实例，HeartbeatManager在连接建立后启动、在连接关闭时停止，ReconnectStrategy在onClose回调里计算下一次重连延迟，MessageQueue负责存储和补发消息。
4.2 核心客户端类：封装连接、发送、重连触发
先看最重要的WsClient。这个类把Java-WebSocket的WebSocketClient封装起来，对外提供简单的connect、send、close接口。
public class WsClient { private final URI serverUri; private WebSocketClient internalClient; private final HeartbeatManager heartbeatManager = new HeartbeatManager(); private final ReconnectStrategy reconnectStrategy = new ReconnectStrategy(); private final MessageQueue messageQueue = new MessageQueue(); private final List<MessageListener> listeners = new CopyOnWriteArrayList<>(); private volatile boolean manuallyClosed = false; public WsClient(URI serverUri) { this.serverUri = serverUri; } public synchronized void connect() { manuallyClosed = false; createInternalClient(); internalClient.connect(); System.out.println("[WsClient] 发起连接: " + serverUri); } private void createInternalClient() { if (internalClient != null) { try { internalClient.close(); } catch (Exception ignored) { } } internalClient = new WebSocketClient(serverUri) { @Override public void onOpen(ServerHandshake handshakeData) { System.out.println("[WsClient] 连接已建立"); reconnectStrategy.reset(); heartbeatManager.start(this); messageQueue.flushAll(this); } @Override public void onMessage(String message) { // 业务消息在这里分发 for (MessageListener listener : listeners) { listener.onMessage(message); } } @Override public void onClose(int code, String reason, boolean remote) { System.out.println("[WsClient] 连接关闭 code=" + code + ", reason=" + reason); heartbeatManager.stop(); if (!manuallyClosed) { scheduleReconnect(); } } @Override public void onError(Exception ex) { // 网络异常不一定立刻触发 close，所以只记录日志 System.err.println("[WsClient] 连接错误: " + ex.getMessage()); } }; // 这个参数是指定连接丢失检测的超时时间（秒），配合底层TCP探测 internalClient.setConnectionLostTimeout(HeartbeatManager.TIMEOUT_SECONDS); } private void scheduleReconnect() { if (manuallyClosed) { return; } long delay = reconnectStrategy.nextDelay(); System.out.println("[WsClient] " + delay + "ms 后进行第 " + reconnectStrategy.getAttempts() + " 次重连"); Thread thread = new Thread(() -> { try { Thread.sleep(delay); } catch (InterruptedException e) { Thread.currentThread().interrupt(); return; } if (!manuallyClosed) { connect(); } }, "ws-reconnect-thread"); thread.setDaemon(true); thread.start(); } public synchronized void close() { manuallyClosed = true; heartbeatManager.stop(); if (internalClient != null) { internalClient.close(); } } public boolean isOpen() { return internalClient != null && internalClient.isOpen(); } public boolean send(String message) { if (isOpen()) { internalClient.send(message); return true; } // 连接不可用，先缓存到本地队列，等重连成功后补发 messageQueue.add(message); return false; } public void addListener(MessageListener listener) { listeners.add(listener); } }这里有几个设计细节要特别说明。
connect()方法用synchronized修饰是为了防止并发重连。回调线程和定时任务线程都有可能触发连接操作，如果不加锁，可能出现两个WebSocketClient实例同时创建，底层连接一会通一会断，非常难排查。另外，每次创建新客户端之前，先close掉旧的实例，是为了释放旧连接的IO线程和文件描述符，避免内存泄漏和连接句柄耗尽。
manuallyClosed这个标志位很关键。当业务方主动调用close()时，我们不希望触发自动重连，所以置为true；而正常连接断掉时，它保持false，在onClose里走进重连分支。这个标志位必须用volatile修饰，因为它在多个线程之间共享。
重连用的是独立线程加Thread.sleep，而不是在onClose回调里直接同步connect()。原因很简单：Java-WebSocket的onClose回调执行在WebSocket的IO线程里，如果在这个线程里执行阻塞式的重连逻辑，会把这个线程拖住，影响后续其他事件的处理，严重的会出现死锁。单独起一个线程，配合sleep延迟，既能避开这个问题，又方便控制重连的时机。
4.3 心跳管理器与重连策略实现
再看HeartbeatManager。它的任务只有一个：定期发Ping，检查Pong超时，必要时触发关闭。
public class HeartbeatManager { public static final int INTERVAL_SECONDS = 30; public static final int TIMEOUT_SECONDS = 60; private ScheduledExecutorService scheduler; private volatile long lastPongTime = 0; public void start(WebSocketClient client) { stop(); lastPongTime = System.currentTimeMillis(); scheduler = Executors.newSingleThreadScheduledExecutor(r -> { Thread t = new Thread(r, "ws-heartbeat-thread"); t.setDaemon(true); return t; }); scheduler.scheduleAtFixedRate(() -> { long now = System.currentTimeMillis(); // 先检查上次pong距今是否超时 if (now - lastPongTime > TIMEOUT_SECONDS * 1000L) { System.err.println("[心跳] 超过" + TIMEOUT_SECONDS + "秒未收到pong，判定连接假死"); client.close(); return; } // 发送Ping if (client.isOpen()) { client.sendPing(ByteBuffer.wrap("ping".getBytes(StandardCharsets.UTF_8))); } }, INTERVAL_SECONDS, INTERVAL_SECONDS, TimeUnit.SECONDS); } // 在收到pong时由WebSocket底层回调调用 public void onPong() { lastPongTime = System.currentTimeMillis(); } public void stop() { if (scheduler != null) { scheduler.shutdownNow(); scheduler = null; } } }使用时要记得：在WebSocketClient的回调里，把onWebsocketPong事件转发到heartbeatManager.onPong()。Java-WebSocket的WebSocketClient类没有直接暴露onPong回调，你得重写onWebsocketPong方法，一些版本里回调签名是protected void onWebsocketPong(WebSocket conn, ByteBuffer message)。
再来看ReconnectStrategy，也就是指数退避加随机抖动的具体实现。
public class ReconnectStrategy { private static final int BASE_DELAY_MS = 1000; private static final int MAX_DELAY_MS = 60_000; private static final int MAX_ATTEMPTS = 10; private static final Random RANDOM = new Random(); private int attempts = 0; public long nextDelay() { attempts++; if (attempts > MAX_ATTEMPTS) { // 超过最大连续重连次数，进入更慢的重试节奏 return 5 * 60_000L + RANDOM.nextInt(1000); } long expDelay = BASE_DELAY_MS * (1L << Math.min(attempts, 10)); long capped = Math.min(MAX_DELAY_MS, expDelay); return capped + RANDOM.nextInt(500); } public void reset() { attempts = 0; } public int getAttempts() { return attempts; } }这段代码计算出来的重连延迟大概是这样的序列：1秒、2秒、4秒、8秒、16秒、32秒、60秒、60秒……加上抖动之后，每个客户端的实际重连时间都不完全一致，错峰效果就有了。重连成功后reset()会把attempts归零，这样下次断线又从头开始快速恢复。
特别提醒一点：1L << Math.min(attempts, 10)这里。如果attempts已经比较大，不加Math.min直接移位会导致数值溢出变成负数，那延迟时间就乱了。这种边界问题在写代码时很容易漏。
消息队列MessageQueue很简单，就是一个带锁的队列，容我做了一下简化，核心逻辑就是add和flushAll：
public class MessageQueue { private final Queue<String> queue = new ConcurrentLinkedQueue<>(); public void add(String message) { queue.offer(message); } public void flushAll(WebSocketClient client) { String msg; while ((msg = queue.poll()) != null) { client.send(msg); } } }断线期间业务方调send()时消息被塞进队列，重连成功后在onOpen里统一补发。这个设计虽然简单，但配合消息ID幂等机制，已经能解决大部分场景下的消息丢失问题了。
4.4 接入Spring Boot：管理客户端生命周期
如果项目用了Spring Boot，把WsClient做成单例Bean是常规操作。关键在于生命周期管理：应用启动时连接，应用关闭时优雅断开。
@Configuration public class SpringWsClientConfig { @Bean(destroyMethod = "close") public WsClient wsClient() { WsClient client = new WsClient(URI.create("ws://localhost:8080/ws")); client.addListener(message -> System.out.println("[业务] 收到消息: " + message)); client.connect(); return client; } }destroyMethod = "close"保证了Spring容器关闭时会自动调用WsClient.close()，把manuallyClosed置为true，不再触发重连。如果不做这一步，应用发布停机时，可能还有后台线程在尝试重连，造成"应用关了还在往外打请求"的诡异现象。
还有一点，Spring环境下最好不要用@PostConstruct直接调用connect()，因为此时WsClient实例可能还没完成依赖注入。把connect()调用放在@Bean方法里是最稳妥的。
5. 踩坑实录与调优参数速查
代码部分讲完了，我再把实际项目中遇到的几个高频问题、以及怎么验证这套重连机制的方法整理出来。这一部分是我最想说的，很多坑是写代码时根本想不到的。
5.1 我踩过的几个典型坑
先说第一个坑：重连触发写成"双倍触发"。我在第一版代码里做了两件事：在onError里面调scheduleReconnect()，又在onClose里面调scheduleReconnect()。结果是，一次网络抖动触发两个重连线程，然后两个线程各自创建WebSocketClient，连接状态变得极其混乱。后来改成只在onClose里触发重连，onError里只记录日志，问题立刻消失。想明确告诉大家：Java-WebSocket的onError和onClose不是互斥关系，一次断线可能先触发onError，再触发onClose，重连逻辑放在onClose一个入口就够了。
第二个坑：connect()非阻塞导致判断失真。Java-WebSocket的connect()方法是非阻塞的，它内部会创建一个线程去建立连接，你调用connect()之后立刻检查isOpen()大概率是false。我见过有人写了个if (client.connect() && client.isOpen())来判断连接是否成功，这明显是错误用法。正确的做法是在onOpen回调里确认连接成功，而不是在connect()返回值上做文章。
第三个坑：重连成功后没有重置退避计数器。结果就是，程序运行时间越长，重连间隔越大，最后变成每5分钟才重连一次。用户早就失去耐心了。onOpen里必须调用reconnectStrategy.reset()，我上面代码里也包含这行，别漏。
第四个坑：心跳定时器没停导致叠加。如果每次重连都start()一个新的心跳调度器，但旧调度器没有shutdownNow()，那么到后面可能有十几个线程同时在发Ping。我在HeartbeatManager.start()的第一行就调用stop()，就是为了清理之前残留的调度器。
第五个坑：服务端没有心跳机制。很多问题出在服务端完全不做心跳，虽然客户端定期发Ping，但服务端的WebSocket框架如果不自动回Pong，客户端一样会判定超时。所以客户端和服务端的心跳必须同时配上，两边都要支持WebSocket协议的标准Ping/Pong。
5.2 如何模拟断网验证重连机制
代码写好了，怎么测试？这里给大家几种我认为比较实用的断网模拟方式。
第一种，直接杀服务端进程。在测试服务器上启动服务端，然后kill -9杀掉进程。这是最暴力的方式，能立刻看到客户端日志里出现onClose，然后开始指数退避重连。等服务端重新启动后，客户端应该在几十秒内自动恢复连接。这个场景能覆盖服务端重启导致的断线。
第二种，用防火墙丢包而不是拒包。在Linux测试机上执行：
iptables -A INPUT -p tcp --dport 8080 -j DROP注意我用的是DROP而非REJECT。REJECT会让TCP层立刻收到RST包并报错，而DROP是直接把包丢弃，客户端不会立刻感知，需要依靠心跳超时判断连接已死。这个场景恰好能模拟NAT超时导致的假死。
清除规则时执行：
iptables -D INPUT -p tcp --dport 8080 -j DROP第三种，在客户端代码里手动调用internalClient.close()来模拟连接被服务端主动断开。这种方式最简单，但只能测到重连流程，测不到心跳超时分支。
我建议至少把第一种和第二种场景都测一遍，尤其是第二种，心跳超时判定的逻辑只有在这种场景下才会被完整走一遍。
5.3 参数调优速查表
最后给一个参数速查表，方便不同场景下直接参考调整：
| 参数 | 推荐值 | 说明 |
|---|---|---|
| 心跳间隔 | 30秒 | 小于常见NAT超时时间（2分钟）即可 |
| 心跳超时阈值 | 60秒 | 至少为心跳间隔的2倍，留出网络延迟余量 |
| 初始重连延迟 | 1秒 | 建议不要小于1秒，避免频繁触发 |
| 最大重连延迟 | 60秒 | 过高会让恢复变慢，过低会打爆服务端 |
| 最大连续重连次数 | 10次 | 超过后转为5分钟一次的慢速重试 |
| 随机抖动范围 | 0~500毫秒 | 缓解惊群效应 |
这个表只是一个基准，实际要根据你的服务端负载和客户端数量做微调。如果客户端数量上千，抖动范围建议拉到1秒左右，错峰效果更好；如果是内网可靠环境，心跳间隔甚至可以调到60秒，减少无效包。
写在最后
这套断线重连框架，我在实际项目里已经稳定跑过很久。它的设计并不复杂，核心的心跳、退避重连、消息补偿这三点，也就是那几十行代码的事。但真正让它稳定的，是那些"多考虑一步"的细节：重连只在onClose触发、旧连接要清理、心跳调度器要停干净、manuallyClosed标志位要置位。踩过这些坑之后，你会深刻理解，重连机制不是在"连接断了"之后才工作，而是在连接建立的那一刻就开始了它的使命。最后再分享一个小建议：刚开始做断线重连时，不要追求一步到位，先把心跳和基础重连跑通，加上日志，观察几天，再逐步加入消息补偿和幂等处理。稳扎稳打，比一次写出一套复杂系统要靠谱得多。
