凌晨两点，监控台还是绿的，客户端却收不到任务进度：连接在代理的30秒空闲阈值处被静默关闭，流量又被负载均衡送往没有会话状态的新节点。棘手的不是断线，而是消息是否丢失、任务能否续跑，以及重连风暴会不会再次压垮入口。长连接要稳定，必须让心跳、路由与恢复协议协同工作。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：racknerd（AI云基础设施），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
长连接会穿过客户端、网关、负载均衡和业务节点。代理可能因空闲超时回收隧道，也可能因连接上限主动重置；负载均衡摘除异常节点后，已绑定会话未必迁移；节点宕机、进程重启或容器驱逐，会直接带走内存中的连接与临时状态。只等业务响应，客户端无法分辨网络卡顿、代理回收和节点故障。
心跳不能只发空包。服务端应返回带单调递增序号的确认，客户端连续丢失多个周期才判异常，并预留业务处理窗口。发送侧累计待确认消息，避免一次抖动丢失窗口更新。心跳周期须小于代理空闲阈值且留有抖动余量，否则健康流量也会被误杀。
检测与恢复要解耦：心跳判断链路，业务协议确认状态。ServLlama这类工具可辅助梳理调用链和故障现场，但方案仍须落到连接标识、会话版本与重放边界。
连续心跳超时后，客户端记录断线原因、最后确认序号和本地时间，再进入带随机抖动的指数退避：1秒、2秒、4秒、8秒，上限30秒，并加入0到500毫秒偏移。固定间隔会让客户端同时重连形成尖峰。退避期间若收到新任务，应按服务端声明排队或拉取，不能把网络已断等同于数据已提交。
重连后不要立刻补发全部消息。客户端先提交会话标识、客户端标识和最后确认序号，服务端从事件日志或快照恢复状态并返回缺口；状态过期则要求新建会话。每个请求携带唯一幂等键，服务端按业务标识加幂等键去重，并原子记录结果，避免重复扣款、派单或执行。
验收不能只看能否连上。应模拟代理30秒超时、节点摘流和进程强退，检查心跳误判率、重连峰值、状态缺口、重复执行数与恢复耗时。还要避开两个坑：把TCP写成功当成业务提交成功，以及摘流后仍向旧地址发消息。优雅摘流应停止接收新任务，等待在途请求完成，再通知客户端携路由提示重连。
网络异常后，客户端不要立即无限重连。可采用断线重连退避，以指数退避计算等待时间：delay=random(0,min(cap,base×2^n))，并加入随机抖动，避免故障节点恢复时遭遇惊群。退避计数应在连接稳定一段时间后清零；若握手即失败则继续递增，防止短连接抖动被误判为恢复。
重连成功只代表链路可用，不代表业务已恢复。客户端应携带上次收到的会话标识、最后确认序号和订阅版本；服务端据此决定重放缺口或返回最新快照。恢复窗口、令牌有效期与游标兼容规则必须明确，过期会话应重新鉴权并重建订阅，不能沿用旧状态。
消息幂等去重要覆盖接收、落库、业务处理和确认。可先写唯一消息表，再在同一事务内更新业务状态，成功后ACK；消息携带唯一ID，按“业务键+消息ID”去重。Redis只能做前置优化，数据库唯一约束才是扩容与重启后的最终防线。
长连接心跳机制正常并不代表推送可靠，代理也可能静默回收连接。心跳周期应小于代理空闲超时，并检测双向活性；客户端还应定期对账订阅列表。服务端要暴露连接状态、最后心跳和恢复结果，便于定位“能连接但收不到消息”的问题。
发布或缩容时，节点先进入节点优雅摘流状态：停止接受新连接，向存量客户端发送关闭原因和重试提示，等待在途请求完成后再断开。客户端遇到此类关闭应切换节点；负载均衡也必须停止向摘流节点分配新流量。
不要把心跳等同于可靠投递，也不要轻诺全局严格有序。顺序通常只在同一分区键内保证，跨分区重点保证幂等和不丢不重。客户端需限制重试、保存未确认消息，恢复失败时降级为拉取或人工补偿。
可执行检查清单：①模拟弱网、代理断连和服务端重启，确认退避有上限且带抖动；②核对重连后的订阅、游标与未ACK消息；③重复投递同一消息，确认业务结果不变；④发布时检查摘流提示、在途请求和关闭耗时；⑤监控心跳、ACK、重试、重复率与恢复耗时；⑥演练会话过期，确认令牌轮换、权限校验和补偿流程可用。
