13日我写了篇文章，说现在机场的客户端存在一些问题，容易出现全节点超时的情况。但之后我认为当时的测试并不严谨：我电脑上装过不少代理客户端，切换之前只关了界面，没有确认后台 Core、端口和系统代理是否已经清理干净。换句话说，我以为自己在测试另一个客户端，实际流量可能还在走上一个客户端留下的核心。

所以 7 月 14 日到 16 日，我用两台电脑重新测了3天。

先说结论

至少从这三天、这两台电脑的记录看，没有观察到龙猫云持续性故障，也没有足够证据支持我之前关于“大范围故障”的判断。

这不等于龙猫云和其他机场客户端完全没有问题，只能说明之前那组没有清理干净的测试，不能支持原来的结论。

7 月 14 日，在没有切换客户端、也没有主动折腾电脑环境的观察时段，出现过一次需要更新节点处理的断连。大约中午 12 点，龙猫 Core 和本地代理端口都还在，但通过代理访问外网失败。后来按当时的公告提示更新节点，连接恢复。

同一天还记录到两次很短的探测失败，持续时间都在 10.7 秒左右，之后自行恢复。这两次更适合叫“短暂波动”，不宜直接写成完整断连。

15 日到 16 日，我在电脑 A 上进行了大量客户端启动、退出、换端口和清场测试。这期间出现的异常，很多都能找到本机客户端冲突的证据，所以不能全部算到龙猫云线路头上。

测试环境

这次用了两台 Windows 电脑，位于不同城市，但都是湖南联通 1000M 宽带。

• 电脑 A：主测试机。 平时安装和使用过很多代理客户端，这次主要用它切换龙猫云、全球云、Clash Verge、Clash Party 、FlClash等客户端，观察系统代理、端口和后台进程怎样变化。
• 电脑 B：辅助对照机。 以前主要用 Clash Verge，这次才安装龙猫云和唯兔云。它主要负责持续监控，帮助判断相近时间内另一台电脑是否也发生了同样的问题。

虽然两台电脑使用相同运营商和相同带宽，减少了运营商差异，但它们并不是严格意义上的对照组。两台电脑所在城市、软件安装历史、当时操作都不完全相同，所以电脑 B 只能帮助排除一部分解释，不能单独证明故障原因。

真正麻烦的是多个客户端互相打架

重新测试后，我发现很多看起来像“机场断了”的情况，实际是多个代理客户端同时修改 Windows 的公共代理状态。

这几天观察到的现象包括：

• 退出全球云后，紧接着观察到龙猫的某个后台进程退出。两件事时间上直接相连，但当时没有完整记录是谁发出了停止请求，所以不能直接写成全球云确定关闭了龙猫；
• 龙猫正在运行时打开 Clash Verge，Windows 系统代理发生变化，浏览器转为直连；
• Clash Verge 的界面退出后，verge-mihomo.exe 仍可能在后台占用 7890；
• Clash Party 即使不开系统代理，也会启动 Core 并监听端口。退出 Clash Party 后，龙猫 Core 仍然运行，但 Windows 系统代理可能已经被关闭；
• 启动部分具有 FlClash 同源特征的客户端时，原来的 Clash 系统代理可能被改写；
• 龙猫与唯兔云同时存在时，发生过龙猫本地控制端口失效、7890 消失和 Helper 服务异常停止；
• 龙猫使用 7892、另一个 Core 仍占着 7890 时，浏览器和 Codex 可能分别走两个不同的客户端。

这些现象可以归纳成几条规律。

1. 代理客户端不会互相礼让

启动、退出或开关任何一个代理客户端，都可能重写 Windows 系统代理。多数跟随系统代理的软件，会听最后一次修改的结果。

2. 关闭窗口不等于代理已经退出

一个代理客户端至少可能包含界面、Core、Helper 服务、系统代理、监听端口和 TUN。窗口消失了，后台 Core 仍可能继续运行；系统代理关了，Core 也可能还在监听端口。

3. 相同端口是最直接的冲突源

多个客户端都想使用 7890 时，先启动的 Core 可能已经占住端口。后打开的客户端即使界面显示正常，也不代表它真的接管了流量。

4. “正在运行”和“网络正常”不是同一件事

“软件界面存在”“Core 正在运行”“端口正在监听”“系统代理已经开启”“代理线路可以访问外网”，这是五个不同的状态。只看其中一个，很容易判断错。

可以把系统代理想成一块路牌。最后一个修改路牌的人，会决定大部分软件往哪里走。某个客户端退出时如果顺手把路牌撤了，其他代理即使还在运行，浏览器也可能已经不再经过它。

正确切换代理客户端的顺序

说到底，正常使用时不要在电脑上同时运行太多代理客户端，能只留一个最好。

如果确实需要切换，建议按这个顺序：

1. 先在旧客户端里断开连接；
2. 从托盘菜单完整退出旧客户端，不要只关窗口；
3. 确认旧 Core 和 7890/7892 已经释放，普通网络能够直连；
4. 再打开新的客户端，选择节点并连接；
5. Codex、终端等如果写死了本地代理端口，切换后还要同步修改，或者直接重启这些应用。

如果已经分不清当前是谁在代理，最省事的办法仍然是重启电脑。重启通常能释放临时残留的进程和端口，但系统代理、开机自启和持久化环境变量不一定都会自动恢复。重启后还有问题，可以再用我做的“断网急救”检查。

我是怎么测试的

这次不是只看“网页能不能打开”。我在 Codex 的帮助下，先写了一个龙猫云断连监控脚本，后来又做了“断网急救”。

龙猫云监控脚本专门观察龙猫这条代理路径。当前版本设定为每 5 秒检查一次：

• lmclientCore 是否仍在运行；
• 当前使用的 7890 或 7892 是否确实由龙猫 Core 监听；
• 通过这个端口访问三个外网探测目标时，是否至少有两个成功。

连续失败 3 次才确认断连，连续成功 2 次才确认恢复。脚本会记录第一次失败时间、恢复时间、持续多久、当时使用的端口、监听进程和 PID，避免把一次网络抖动直接写成完整故障。

这里也有一个边界：这个脚本每一轮只观察龙猫代理路径，不会同时单独测试普通直连。普通网络、系统代理和应用代理之间的对照，主要由“断网急救”的路径检查完成。

把两套记录放在一起后，才能进一步区分：

• 普通网络和代理都失败，可能是宽带、路由器、运营商或本机整体网络问题；
• 普通网络正常，但龙猫 Core 或本地端口消失，更像本机 Core 异常或客户端冲突；
• 普通网络正常，龙猫也在监听端口，但只有代理外网失败，更像节点、上游线路或代理核心内部异常；
• 龙猫 Core 仍在，但端口被其他程序占用，可以直接确认是本机端口冲突。

这里的“端口”可以理解为本机代理的门牌号。127.0.0.1:7890 和 127.0.0.1:7892 是两个不同的门牌号。Windows 只记得应该把流量送到哪个门牌号，并不知道门后面究竟是龙猫云还是 Clash Verge。

每次出现问题后，我再把操作时间、断连记录、Windows 系统代理、7890/7892 的监听 PID、Core 命令行、本地控制端口和能取得的服务记录对到同一条时间线上。能被多项记录互相印证的，才写成实机确认；只有时间关联、没有抓到具体执行者的，就保留为推断。

我做了一个“断网急救”

“断网急救”最初就是为了配合这次测试做的。它主要解决 Windows 上多个代理客户端互相打架、退出后还有 Core 或 TUN 残留、系统代理指向错误端口等问题。

目前主要有三个功能：

• 查看当前网络状态，告诉你系统代理、端口和后台 Core 分别属于哪个已识别的客户端；
• 一键退出已识别的代理组件、清理已知残留并恢复普通网络；
• 在证据充分、风险较低时自动修复系统代理异常。

自动急救的范围比较克制。例如系统代理仍指向一个连续无人监听的本地端口，而且普通直连正常时，它可以关闭这个失效的系统代理；如果退出非主客户端时误关了系统代理，而原来的代理 Core、PID、端口和联网状态都能重新确认，它也可以把系统代理重新打开。

自动模式不会结束进程、停止服务、清理 TUN、重置 DNS，也不会把节点超时当成本机故障处理。手动执行完整清场前，也会先显示准备处理的已知组件。未知进程、未知网卡和未知路由不会盲目清理。

感兴趣的话可以自行下载测试：

• 项目地址：Kerrynotes/network-rescue
• 下载地址：v0.4.0-beta

解压完整压缩包后，双击 安装断网急救.bat 即可。

这次重新测完，我最大的修正不是“龙猫云一定稳定”，而是：之前那种没有清理代理残留就连续切换客户端的测试，不能用来判断机场线路是否稳定。

后面再测机场客户端，我会先清场、确认直连，再从一个干净状态开始。这样得出的结果才有参考价值。