我电脑上装过不少代理客户端。Clash Verge、FlClash、龙猫云、全球云轮流开，单独用都没什么，切换多了以后就开始打架。

最典型的是关掉 Clash Verge 后，Windows 系统代理跟着被撤了。龙猫云界面还亮着“已连接”，浏览器却已经断网。更棘手的一次是龙猫云走系统代理时，Clash Verge 突然拉起 TUN，底层路由被直接接管，网络瞬间瘫痪，前台界面依然显示一切正常。

为了系统处理这种“开关看着都对，实际根本上不了网”的状态冲突，我把之前的“断网急救”重构成了“网络接管守卫”。

网络接管守卫 v0.6.8

• 解决痛点：多客户端争抢系统代理、TUN 在底层接管流量、客户端退出后残留失效代理。
• 运行平台：Windows 10 / 11 x64，主程序是单文件便携版，无需预装 .NET。
• 项目地址：Kerrynotes/network-rescue
• 直接下载：GitHub Releases 最新版

急着救急的朋友可以直接下载试用。如果你也遇到过类似的玄学断网，下面是我这次踩坑摸出来的逻辑和重构思路。

客户端里的开关，不等于系统的真实状态

这次重构最重要的认知是：绝对不能迷信单个客户端界面的“已开启”。

从用户点击开关到流量真正走通，中间隔着好几层独立状态：

• UI 界面是否存活；
• Core 核心进程是否在运行；
• 本地代理端口是否正常监听；
• Windows 系统代理到底指向谁；
• TUN 虚拟网卡与活动路由是否生效；
• 经由这条链路能否真实访问外网。

其中任何一层断档，都会演变成“看起来开着，实际不能用”。

系统代理本质上只是 Windows 给应用程序立的一块“路牌”。后退出的客户端顺手把路牌拔了，还在运行的客户端并不会自动把它插回去。

TUN 则在更底层通过虚拟网卡和路由接管流量。它并不是一个简单的“数字优先级”，但对被活动 TUN 路由覆盖的流量来说，实际路径应该优先按 TUN 判断。一个客户端使用系统代理、另一个客户端建立 TUN 时，还可能形成跨客户端的混合链路。这个时候界面继续显示“系统代理客户端正在接管”，就很可能已经是误报。

解耦状态：引入“三个接管者”

为了准确还原链路，新版界面废弃了笼统的“当前客户端”，拆分成三个概念：

• 首选接管者：用户明确指定、希望默认保持的主力客户端；
• 临时接管者：首选客户端退出时，用于兜底维持联网的健康客户端；
• 实际接管者：综合系统代理、活动 TUN、网卡、路由表及监听端口，判定出的真实流量出口。

例如日常以龙猫云为主。龙猫云退出后，守卫检测到后台的 Clash Verge 链路健康，可以由 Clash Verge 临时接管网络，但不会擅自改掉原来的首选设置。等龙猫云重新启动并连续两次被识别到后，再自动尝试切回。

如果同时出现多个健康候选，又缺乏明确的仲裁依据，软件不会自作聪明，而是直接提醒用户手动选择。我的目标不是让界面看起来干净，而是尽量保持联网，同时尊重用户已经做出的选择。

系统代理守卫：验证健康，拒绝盲目硬写

当系统代理被其他客户端篡改或关闭时，守卫不会立刻强写注册表。它会先核验首选客户端的监听端口与进程归属，再通过这个代理访问多个外网目标。只有多数目标验证成功，才恢复 Windows 系统代理指向，避免把流量引向一个已经失效的端口。

针对两个客户端同时开启 Proxy Guard 导致的循环争抢，新版也去掉了之前容易被误解为卡死的“静默暂停”逻辑。现在 60 秒内连续纠正 3 次，就会进入“需要用户处理”并弹窗，直接提示用户关闭另一个客户端的系统代理或 Proxy Guard。

告警后软件继续观察网络状态，不会不声不响地罢工。网络稳定 90 秒后，争抢告警会自动解除。

双 TUN 仲裁：不能靠杀进程解决

双 TUN 是最棘手的部分。

早期版本用了一个很直接的方案：发现非目标 TUN 后，清理对应的 Core 进程或系统服务。真实测试很快就翻车了，龙猫云会被直接终止，甚至后续重新打开都受到影响。

这个方向明显不对。网络守卫只是一个仲裁工具，没有权力替用户结束另一个正常软件，更不能为了维持自己的“独占状态”，直接阻止其他客户端启动。

所以 Helper 服务在 v2 中彻底重做，只保留两类操作：

• 精准隔离：只有现有证据能够唯一确认网卡归属时，才按精确网卡索引执行可恢复隔离；
• 无损复原：用户切回对应客户端时，按照隔离记录重新核对网卡身份并恢复。

结束客户端进程、停止客户端服务和旧的通用 TUN 清理能力，都已经从新版 Helper 服务与高权限脚本中移除。

一旦遇到网卡名称重叠、Core 归属不唯一或者未知 TUN，软件只报警，不动系统网络。我宁愿它少自动处理一步，也不能为了修一个问题，又顺手制造一个更大的问题。

目前的能力与适配边界

现在这套机制主要能处理这些场景：

• 实时识别系统代理、活动 TUN、端口、Core 和实际连通性；
• 系统代理被改、被关时，先验证目标链路再自动写回；
• 识别“界面显示系统代理，实际流量已经被另一个 TUN 接管”；
• 首选客户端退出时临时使用健康代理，恢复后再尝试切回；
• 持续争抢、双 TUN、未知 TUN、混合链路和连续恢复失败时主动报警；
• 对能够唯一确认归属的非目标 TUN 执行可恢复隔离；
• 自动仲裁期间不结束任何客户端 UI、Core 或服务。

目前通过 client_adapters.json 配置了 10 个客户端的识别规则：Clash Verge、Clash Party、FlClash、肥猫云 Lite、龙猫云 Lite、全球云、玖壹 officeXNB、青云梯 Lite、SpeedCat Lite 和 V2Cloud。

这里说的是“识别规则已经适配”，不是保证这些客户端未来每一个版本都不会变化。如果客户端更新后改了进程名、配置字段、监听端口或者虚拟网卡名称，规则仍然需要跟着更新。

运行与使用注意

• 权限需求：普通系统代理监控与恢复不需要管理员权限；如果要自动仲裁已确认归属的非目标 TUN，需要在界面中安装 Helper v2 服务并放行一次 UAC。
• 交付与验证：正式版由 GitHub Actions 从 v0.6.8 标签重新构建，内置 27 项自检全部通过，Release 页面附带 SHA256SUMS.txt。
• 范围边界：软件负责把“到底是谁在接管网络”理清楚，不负责账号登录、订阅更新、节点切换或者线路质量判断。

双活动 TUN、睡眠恢复、Wi-Fi 重连和不同客户端版本，仍然需要继续积累真机样本。后面如果又碰到新的组合，我再根据日志补规则。