实时应用切换代理 IP 出口后，如何检查连接重建与状态恢复

换出口后，“连上了”不等于“恢复了”。连接重建要验握手、鉴权、重新订阅三步，状态恢复要验补齐、补多、去重三件事。代理IP 切换时，旧连接不一定立刻断开，是否断开取决于切换方式，所以实验要拆成两类：一类保留旧连接、只改新连接配置，观察新请求走哪个出口；另一类主动关闭或注入故障，观察重建与补发。关闭码和补发区间是判断恢复质量的关键证据，但要结合两端日志一起看。

记录代理出口切换时的 WebSocket 关闭码和连接事件

关闭码 1000： 正常关闭；查是否为主动切换。

关闭码 1001： 端点离开；查服务端维护或客户端退出。

关闭码 1006： 客户端本地合成的异常关闭，不会出现在收到的 Close 帧；结合浏览器网络错误、TCP/代理日志和服务端记录定位。

关闭码 1011： 服务端内部错误；查服务端日志。

关闭码 4000+： 应用自定义；查业务定义。
只记录“连接断了”没有信息量。关闭码是线索，不是判决书：1006 只能说明客户端本地观察到了异常断开，无法单凭它区分网络层、代理还是服务端；1001、1000 也可能来自服务端部署或客户端主动退出。定位时要同时看浏览器网络事件、代理连接日志和服务端侧记录，并把切换时刻、旧连接 ID、新连接 ID 一起记下来。

开始切换实验前，可通过代理设置帮助核对出口和接入参数。

分别验证重连握手、身份认证和消息订阅

握手成功只说明 TCP 和 WebSocket 建立；鉴权成功说明身份恢复；重新订阅成功才说明消息流恢复。三步各自的观测点要分开记录，只看到连接建立就宣布恢复，是这类测试最常见的误判。

检查重连后快照同步或增量消息补发

快照对齐（适用于状态小、可整体拉取）： 检查重连后全量版本号是否与服务端一致；若出现状态回退或重复则未恢复完整。

增量补发（适用于消息流、按序追加）： 检查last_seq 之后是否连续、有无补多；若出现缺口、重复则未恢复完整。
两种都要验“补齐没有、补多没有”：补齐看序列连续性，补多看重复计数。重复消息通常来自三个地方：重新订阅导致双份推送、补发区间重叠、客户端重试重放。去重键要选业务键，不要用时间戳。判定前先按快照/增量契约写清版本号、游标、应恢复集合和恢复窗口；原始重放出现重复是协议允许的，真正要看的是去重后的业务效果，不能一律拿“重复数=0”当硬门槛。

对比切换前后的订阅、消息连续性和业务状态

比较切换前后的连接数、订阅数、消息序列和业务状态。连接数短暂变化不一定代表失败；判定标准是业务不变量，而不是“前后完全一致”：订阅最终恢复、缺口按协议补齐、没有重复副作用、状态版本达到基线预期，恢复耗时的上限由项目自己的 SLA 定义。

记录连接恢复过程并判断是否通过

记录切换时间和方式、关闭码、重连耗时、补发区间及重复消息数。上面列出的四项业务不变量全部满足后，才可判定恢复；耗时按项目 SLA 判断。切换影响到生产订阅者或补发量超出预算时，立即停止并回滚出口。

切换后若仍无法恢复连接，可按全球代理使用流程回查获取代理、设置参数和建立连接的步骤。

关闭码定义见：

• RFC 6455 第 7.4 节（状态码）

常见问题

连接重建成功就代表状态恢复了吗？

不代表。订阅和业务状态可能没恢复，要看补发与去重结果。

1006 和 1001 有什么区别？

1006 是客户端在本地合成的异常关闭状态，不会由服务端通过 Close 帧发来；1001 是端点主动离开。