代理 WebSocket 重连之后，也要恢复会话

重连回调执行，新套接字打开。那只是传输层的恢复。它并不必然意味着你的订阅、消息确认或应用会话从上一个连接断开处继续了。

即使是同一个代理端点，也可能产生新的对外连接。出口 IP 变化也可能触发目标端自己的会话策略。把新套接字当作新连接处理，并遵循应用文档规定的恢复交换流程。重连时决定工作流是否应保留其代理路由。

多保留一点，而不只是最后一个 URL

有用的恢复状态可以包括已授权的会话身份、期望的订阅、最后确认的事件标识，以及仍在等待确认的操作。这些字段属于应用协议；WebSocket 并未定义通用的续接令牌。

决定是从游标续接、获取新快照，还是接受空挡。如果事件源不提供重放接口，那么更快的重连并不能证明没有消息被漏掉。

发送两次可能意味着执行两次

断连前在本地排队的消息可能从未离开客户端。另一条则可能在确认丢失的情况下到达了服务器。盲目重发每一条未确认的命令，会把这两种情况当成同一种。

在可用时使用服务的请求标识、幂等支持或对账机制。传输层重连无法让应用操作变得可逆，也不会自动去重。

让重连尝试保持有界，并按应用策略控制节奏。RFC 6455 建议在异常关闭后退避；大量客户端同时立即重试，可能加重故障期间的负载。

记录每次尝试选择了哪条代理路由，但要把路由恢复与应用恢复分开。“又连上了”是有用的证据。“已经补齐、可以提交更多工作了”则需要额外的应用交换来确立。