2026 年 10 月 24 日，海鸥加速器 5.4.2 完成内核换代，客户端由单协议连接改为 WireGuard 与自研隧道双活。两条连接同时保持，按业务类型分别承载流量，任一条断开后 1.2 秒内完成切换。测试组用网络故障注入的方式模拟了 600 次断线，其中 599 次在 1.2 秒内恢复，成功率 99.8%。
换代的起因是一次典型的会议中断：用户在 45 分钟的会议里遇到 2 次重连，画面黑屏各约 3 秒。排查发现，单协议连接在出口链路抖动时会整体重建握手，重建期间所有连接一起断。改成双活之后，握手不再需要重建，切换只是在两条已建立的连接之间改出口，会话层察觉不到中断。
双活如何工作
客户端启动后先建立两条连接：一条是基于 WireGuard 的轻量连接，握手开销小，适合小包与实时对战；另一条是自研隧道，带前向纠错与可调窗口，适合大文件与视频。默认分流规则是实时类走前者、吞吐类走后者，规则文件与游戏模式共用一份，改动一处两边生效。
健康检查每 500ms 发一次探测包，连续 2 次超时就判定该连接不可用，随即把流量切到另一条并尝试重建。切换动作在本地完成，不需要服务器下发指令，因此不受控制面延迟影响。为避免两条连接同时失效，客户端还会在切换失败后 3 秒内换一个备用端口重试，这条路径同样记录在日志里。
「判断双活有没有做好，不看它能不能切，而看切换后那 1 秒里有没有丢包。测试标准定成切换期间丢包不超过 3 个，600 次里有 597 次达标。」唐若舒，海鸥加速器测试负责人
切换与开销数据
测试在 18 台设备上进行，覆盖 Windows 11、macOS 14、Android 14 与 iOS 17，每组 100 次故障注入，注入方式包括直接断网、端口封锁与 30% 丢包三种。600 次有效样本中，切换耗时中位数 0.9 秒，90 分位 1.2 秒，最长一次 2.6 秒；切换期间丢包中位数 1 个包，最差 5 个包。按每分钟 1500 个小包的实时游戏流量折算，1 个包的影响约 40ms。
关键数据
- 故障注入总次数：600 次，有效样本 600 次
- 切换耗时中位数：0.9 秒，90 分位 1.2 秒
- 1.2 秒内恢复比例：99.8%（599 / 600）
- 切换期间丢包：中位 1 个包，最差 5 个包
- 资源开销：CPU 增加 4%，内存增加 18MB
- 日志容量：保留最近 50 次切换记录
开销是可接受的。双连接让客户端常驻内存从 78MB 增加到 96MB，空闲 CPU 占用从 1.2% 升到 1.7%，满速下载时从 6.4% 升到 6.8%。笔记本端的续航影响集中在待机场景，实测 8 小时待机多耗电 2.1%，因此客户端提供「仅单协议」开关，外出用电池时可以关掉双活，切换能力随之关闭。
日志解读与回退
日志里每次切换都会留下四条记录：触发原因（超时、端口封锁或用户手动）、原出口、新出口与耗时。看到「超时→切换」连续出现三次以上，通常说明该线路所在出口不稳定，可以在节点列表里换一条；看到「端口封锁→换端口」说明当前网络对特定端口有限制，客户端换端口后一般可以恢复，不需要手动处理。
需要回退时按四步操作：打开设置里的「连接模式」，选「仅自研隧道」或「仅 WireGuard」，保存后客户端会断开重连一次；确认日志里不再出现双活相关的切换记录；如需彻底关闭，再取消勾选「故障自动切换」，此时断线不会自动恢复，适合做对比测试。回退不会影响已有节点偏好与分流规则。
下一次迭代计划把健康检查间隔从 500ms 缩短到 300ms，并把切换耗时的 90 分位目标定在 1 秒以内。双活默认开启，装好客户端即生效，老用户升级后在日志里可以直接看到第一批切换记录。
读者评论
6 条评论
开会的时候确实没黑屏了，之前最怕讲到一半断掉。
内存涨了 18MB 感知不到，CPU 也就多一点，笔记本还行。
日志那四条记录挺实用，昨天看到端口封锁，换个端口就好了。
求把健康检查间隔改成可调，出差网络差的时候想更敏感些。
关掉双活待机确实省点电，通勤路上用这个设置。
双活加上游戏模式，两套分流规则共用一份，这个设计省事。