workerman本身不提供自动断线重连，重连必须由客户端主动发起；服务端只需做好强制响应ping帧、无条件更新最后活跃时间、设置合理超时并定时清理三件事，配合nginx/slb层正确配置，才能保障客户端可靠重连。
Workerman 5.2.3 本身不提供自动断线重连服务逻辑——重连必须由客户端主动发起，服务端只负责保活与连接清理。所谓“服务端实现断线重连”，本质是配合客户端完成可靠通信的闭环：服务端确保连接不被静默断开，客户端在断开后按策略重建连接。
服务端必须做好的三件事
这是客户端能成功重连的前提，缺一不可：
-
强制响应 Ping 帧：WebSocket 场景下，客户端发空消息（
''）即为标准 Ping 帧。服务端 onMessage 中第一件事就是判断$data === '' && $connection->isWebSocket()，满足则立刻调用$connection->pong()。不能用send('pong')，那只是普通文本，不是协议级响应。 -
无条件更新最后活跃时间：onMessage 回调开头第一行必须写
$connection->lastMessageTime = time()，无论 $data 是否能 JSON 解析、是否为业务消息、是否为空。否则心跳失败或解析异常时时间戳不更新，服务端会误判连接离线。 -
设置合理超时并定时清理：服务端需启动一个全局定时器（如每 45 秒执行一次），遍历所有连接，对
time() - $connection->lastMessageTime > 90的连接调用$connection->close()。90 秒阈值需严控在主流 NAT/SLB 最短空闲超时（通常 60–90 秒）之内，留出一次心跳丢失余量。
Nginx 或 SLB 层关键配置
很多断连问题实际卡在反向代理层，服务端逻辑再完善也无效：
- proxy_read_timeout 至少设为 300（单位：秒），避免 Nginx 在 60 秒后主动断开空闲连接；
- 禁用 proxy_buffering 或调大 buffer，防止代理缓存未完整帧导致 pong 响应延迟或丢失；
- 若用阿里云 SLB，确认其 WebSocket 超时已手动改为 ≥300 秒（控制台默认可能为 900，但实测常被中间设备截断）。
客户端重连不能靠固定延时
服务端不参与重连决策，但客户端策略直接影响体验和稳定性：
- 首次断开（如 onclose 触发）立即重试；
- 连续失败 2 次后，退避到 3–5 秒，并加 ±1 秒随机抖动；
- 连续失败 5 次后，升至 15–30 秒，并检查
navigator.onLine和网络类型（如 4G 模组需监听+CGATT: 1等 AT 响应后再建连）； - 禁止使用 1–2 秒固定重连，易引发雪崩请求或模组固件卡死。
纯 TCP 连接要另起心跳机制
注意：$worker->pingInterval 和 $worker->pingNotResponseClose 仅对 WebSocket 协议生效，对 tcp:// 协议完全无效。纯 TCP 场景下必须自行设计：
- 客户端每 ≤25 秒发送
{"type":"ping"}字符串； - 服务端 onMessage 中识别该结构并更新时间戳（非心跳消息才更新业务活跃时间）；
- 另起定时器每 45 秒扫描，对超时连接主动 close，并禁用 Nagle 算法（
$connection->setTcpNoDelay(true)）减少小包延迟。
