前两天有朋友留言，说龙猫云总是断线，但看我测出来的速度又很不错，觉得这两个结果对不上。

这两件事其实并不矛盾。测速测的是节点在当时那个时间段能跑多快，日常使用考验的则是客户端能不能一直把核心、系统代理、TUN 和路由维持在正常状态。节点可以很快，客户端也可以隔一会儿就抽风。

为了确认这个问题，我连续两天使用了龙猫云、肥猫云、全球云、唯兔云等机场的官方客户端，也把几个安装包和相关代码丢给 Codex 做了分析。最近又买了奶昔，发现他们也在用订阅阅后即焚。刚好把这两件事放在一起聊一下。

机场搞客户端本来是好事

我并不反对机场做自己的客户端。

对熟悉 Clash 的人来说，复制订阅、导入配置、选择节点、打开系统代理或者 TUN 都很简单。但对新人来说，这里面每个词都可能是问题。

机场客户端把流程改成登录账号、选择节点、点击连接，套餐、流量、到期时间、公告和工单也都放在一起。新人拿来看看网页、刷视频、追剧，确实方便，机场也能少回答很多“订阅怎么导入”的问题。

问题是，方便的前提应该是稳定。如果客户端本身经常断线，一键连接就会变成一键排障。

我并不反对机场做自己的客户端。

对熟悉 Clash 的人来说，复制订阅、导入配置、选择节点、打开系统代理或者 TUN 都很简单。但对新人来说，这里面每个词都可能是问题。

机场客户端把流程改成登录账号、选择节点、点击连接，套餐、流量、到期时间、公告和工单也都放在一起。新人拿来看看网页、刷视频、追剧，确实方便，机场也能少回答很多“订阅怎么导入”的问题。

问题是，方便的前提应该是稳定。如果客户端本身经常断线，一键连接就会变成一键排障。

节点可以很快，客户端也可以一直断

这两天实际用下来，机场客户端和通用客户端的差距还是挺明显的。

• Lite 系列有时用十几分钟就会断连，界面里所有节点一起显示超时；
• 全球云这类客户端出现的概率低一些，我大概用了六个小时，遇到过一次；
• 点击快速连接后，Windows 系统代理会被强制打开，不管我是不是准备使用 TUN；
• 网络一下能上、一下不能上，只能反复开关系统代理和虚拟网卡，搞得我像个傻子一样；
• 看网页、刷视频可能暂时没感觉，但 Codex 这种依赖长连接的程序很容易超时，基本没法正常工作。

所以测速很好，只能证明节点在测试窗口里的带宽和延迟不错，不能证明官方客户端能稳定运行几个小时。

这次我还做了同订阅对照。龙猫云同一份订阅里的 67 个节点，导入原版 FlClash 后，节点字段能对上，连续三轮批量测速也没有出现全节点超时。反过来，在龙猫云客户端正常初始化的窗口里，它的 TUN 实际请求表现和 FlClash TUN 又比较接近。

这反而说明了问题：节点配置本身可以正常，客户端正常时速度也可以很好，但客户端的状态管理仍然可能间歇性出错。

Codex 从客户端里看出了什么

我把这些 Lite 结尾的，还有几个 windows-amd64-setup.exe 丢给了 Codex 进行分析。

这些客户端都是基于 Flclash 二次开发的，但问题主要出在连接流程没有完全收好。分析里比较关键的几项是：

• 龙猫云 Lite 在核心退出超时后存在直接强杀的逻辑，如果清理没有完成，可能留下系统代理或 TUN 路由。
• 客户端更相信软件内部的开关状态，没有每次核对 Windows 里真实的系统代理、监听端口、虚拟网卡和路由；
• 打开系统代理前，没有充分确认代理核心和本地端口已经准备好；
• TUN 首次授权需要重启核心，授权、Helper、核心和界面状态之间存在时间差；
• 操作失败后界面没有完整回滚，可能出现“TUN 显示已开启，但真实网卡和路由根本没建立”；
• 系统代理和 TUN 可以同时开启，但客户端没有告诉用户，不同程序的流量到底走了哪条路径。

节点测速也依赖同一个代理核心和共同入口。一旦核心状态异常，界面上看到的就会是“几十个节点同时超时”。这不一定代表几十台服务器在同一秒全部坏了，更可能是它们共用的那条本地链路出了问题。

当然，这些分析能解释目前观察到的现象，但不能把每一次断线都钉死为同一个原因。真正断线的那一刻，还要结合核心日志、端口、路由和 TUN 状态才能完全定因。

最好不要同时装一堆客户端

如果只是偶尔用机场官方客户端，我建议尽量只留一个负责接管网络的软件。

不要同时开着几家机场客户端，再加上 Clash Verge、FlClash 等通用客户端来回切。它们都可能修改 Windows 系统代理、创建 TUN 网卡、安装 Helper 服务或者调整路由。前一个软件没有清理干净，后一个又接手，很容易出现代理状态残留。

我自己就遇到过 Clash Verge 退出后还有代理状态残留的情况，所以这不完全是机场客户端独有的问题。只是客户端越多，谁在接管网络就越难判断。

客户端不够稳定，机场为什么还要推？

聊到这里就会有一个问题：既然官方客户端的体验还不如成熟的通用客户端，为什么越来越多机场还是要推自己的客户端，甚至配合订阅阅后即焚？

因为机场考虑的不只是“用户连得快不快”，还要考虑订阅和节点配置会不会被长期、低成本地拿走。

封闭客户端和阅后即焚看起来是两件事，实际目的很接近：把以前长期暴露在外面的订阅和节点配置，尽量收回到机场自己可控制、可撤销的流程里。

阅后即焚用起来确实不方便

现在不少机场的订阅链接只在几分钟到十几分钟内有效。用户需要登录后台复制，导入客户端后链接很快就失效。

正常情况下，节点主要依赖域名，配置也不会天天变化，所以旧节点通常还能继续使用。但缺点同样明显：

• 不能再用同一个订阅链接更新节点和查看已用流量；
• 入口域名被污染后，只能重新登录官网获取订阅；
• 如果官网恰好也需要代理才能访问，就容易形成死循环；
• 像我这种习惯每天刷新订阅信息的人，会非常不适应。

从用户角度看，这就是实打实的体验倒退。但站在机场角度，特别是那些名气大、规模大的机场，也不是完全不能理解。

它们真正防的是什么

阅后即焚和封闭客户端，防不住真正下决心想攻击某个机场的人。

如果对方愿意花钱买号、研究客户端、抓包甚至逆向，只要客户端最终要连上节点，连接信息就一定会在本地某个环节出现。这些措施只能提高门槛，不能把配置变成永远看不见的秘密。

它们真正减少的，可能是几类更常见的低成本泄露：

• 用户把订阅链接转发给别人，或者截图时没有打码；
• 用户把订阅丢进在线订阅转换器、Sub-Store 或测速工具；
• 某些程序拿到固定链接后，定时拉取最新节点；
• 旧订阅链接已经在网上流传，仍然可以持续获取新配置；
• 批量采集程序用很低的成本扫一堆机场。

以前的固定订阅链接就像一张长期饭卡。别人捡到了，不仅今天能吃，明天也能吃，下个月机场换了菜，他还能继续吃。

阅后即焚就是让这张饭卡很快过期。封闭客户端则是尽量不发饭卡，只让你刷官方 App 进食堂。

它们不完美，但确实能减少很多无意识泄露，也能让机场在出问题时更快撤销链接、锁定账号或者更换配置。代价就是正常用户更新订阅更麻烦，也更依赖机场自己的客户端和官网。

能理解，但代价是用户体验下降

我的看法很简单：机场做官方客户端是好事，阅后即焚也有现实作用。特别是规模大的机场，完全不做保护，别人长期采集最新配置的成本确实太低了。

但官方客户端如果还不够稳定，就不适合成为唯一入口。对新人，可以默认推荐官方客户端；对熟悉 Clash、Shadowrocket 的用户，最好保留短期生成、限制设备、限制更新频率并且可以随时撤销的标准订阅。

这样机场仍然可以控制泄露风险，用户在官方客户端出问题时，也还有一个能继续上网和排障的选择。

我个人认为：官方客户端适合只是看网页、刷视频的新人；需要长时间工作，尤其是要用 Codex 这类长连接工具，我还是更愿意把订阅放进自己熟悉的通用客户端里。