这两件事其实并不矛盾。测速测的是节点在当时那个时间段能跑多快，日常使用考验的则是客户端能不能一直把核心、系统代理、TUN 和路由维持在正常状态。节点可以很快，客户端也可以隔一会儿就抽风。
我当时连续两天使用了龙猫云、肥猫云、全球云、唯兔云等机场的官方客户端，也把几个安装包和相关代码丢给 Codex 做了分析。最近又买了奶昔，发现他们也在用订阅阅后即焚。刚好把这两件事放在一起聊一下。
**2026/7/17 更新：** 这篇文章发布后，我发现当时关于“机场客户端容易断连”的测试并不严谨。
我的电脑装过很多代理客户端。有些客户端退出界面后，后台 Core 仍然可能继续运行，端口和系统代理也不一定清理干净。我没有每次都先把旧客户端完整退出，再测试另一个客户端，所以当时遇到的全节点超时，不能全部算到机场客户端头上。
7 月 14 日到 16 日，我又用两台电脑重新测了几天。至少从这次记录看，没有观察到龙猫云持续性故障，也没有足够证据支持“大范围故障”这个判断。具体的复测过程和客户端冲突记录，我单独写在了《再聊机场客户端 – 多代理客户端会打架》里。
这篇文章里关于机场客户端断连的判断，我也相应修正一下。至于官方客户端和订阅阅后即焚值不值得做，还是可以继续聊。
机场搞客户端本来是好事
我并不反对机场做自己的客户端。
对熟悉 Clash 的人来说，复制订阅、导入配置、选择节点、打开系统代理或者 TUN 都很简单。但对新人来说，这里面每个词都可能是问题。
机场客户端把流程改成登录账号、选择节点、点击连接，套餐、流量、到期时间、公告和工单也都放在一起。新人拿来看看网页、刷视频、追剧，确实方便，机场也能少回答很多“订阅怎么导入”的问题。
问题是，方便的前提应该是稳定，退出和切换时也应该把自己的 Core、端口、系统代理和 TUN 处理干净。不然用户看到的虽然是一键连接，出了问题还是得自己排查。
关于客户端断连，我收回原来的判断
我原来在这里列了几条测试结果，包括 Lite 系列使用十几分钟后全节点超时、全球云使用几个小时后断连，以及 Codex 长连接经常失败。
现在看，这些现象确实发生过，但当时的测试环境不够干净，不能直接证明问题来自某一个机场客户端。
后来的复测确认，代理客户端至少有几个相互独立的状态：软件界面、后台 Core、本地监听端口、Windows 系统代理、TUN，以及代理线路本身。只要其中一层没有退出干净，切换到另一个客户端后就可能出现全节点超时、浏览器直连，或者浏览器和 Codex 走不同客户端的情况。
而 Codex 等 AI 客户端连接失败的原因是写死了环境变量为 127.0.0.1:7890。而 Lite 系列的端口可能是7892 等，结果就断连了。（他们这些客户端做了端口检测，如果发现当前端口被占用，会让你修改，这个体验还是不错的）
我之前还把龙猫云同一份订阅里的 67 个节点导入原版 FlClash，连续做了三轮批量测速，没有遇到全节点超时。这个对照只能说明节点配置可以在 FlClash 中工作，不能单独证明官方客户端就是断连原因，因为当时仍然没有把电脑上的其他代理残留完全排除。
所以更准确的说法是：
1. 测速很好，只能证明节点在测试窗口里的速度不错；
2. 界面出现全节点超时，也只能证明当时的代理链路出了问题。
仅凭这两个现象，都不能直接判断是机场线路、官方客户端还是本机代理冲突。
Codex 从客户端里看出了什么
我把这些 Lite 结尾的客户端，还有几个
windows-amd64-setup.exe 丢给 Codex 分析。从代码血缘和程序结构看，它们大多是基于 FlClash 和 Mihomo 做的定制版本，再加上登录、套餐、支付、公告和客服等机场功能。
二次开发本身没什么问题。从程序结构里可以看到一些需要特别处理的地方：
- 客户端内部的开关状态，和 Windows 里真实的系统代理、监听端口、虚拟网卡及路由并不是同一个状态；
- 打开系统代理前，需要确认代理 Core 和本地端口已经准备好；
- TUN 首次授权可能触发核心重启，授权、Helper、Core 和界面之间存在时间差；
- 操作失败后如果没有完整回滚，可能出现界面状态和真实网卡、路由不一致；
- 系统代理和 TUN 可以同时存在，不同程序也可能通过环境变量走另一条代理路径；
- 龙猫云 Lite 在核心退出超时后存在直接结束进程的处理，如果清理没有完成，理论上可能留下系统代理或 TUN 路由。
这些分析可以解释为什么客户端切换后容易出现状态不一致，但它们只是风险点，不是每一次断连的原因证明。
真正出问题的那一刻，还要把操作时间、后台 Core、端口归属、系统代理、TUN、直连和代理探测记录对到一起。没有抓到这些证据，就不能把某一次全节点超时直接钉死为客户端 Bug。
最好不要同时运行一堆客户端
如果只是偶尔使用机场官方客户端，我建议尽量只让一个软件负责接管网络。
不要同时开着几家机场客户端，再加上 Clash Verge、FlClash 等通用客户端来回切。它们都可能修改 Windows 系统代理、创建 TUN 网卡、安装 Helper 服务或者调整路由。前一个软件没有清理干净，后一个又接手，很容易出现代理状态残留。
我自己就遇到过 Clash Verge 界面退出后，
verge-mihomo.exe 仍在后台占用 7890 的情况。所以这不完全是机场客户端独有的问题。客户端越多，谁在接管网络就越难判断。因为端口不同，你甚至可以同时连接多个客户端。但这样最后就可能变成了浏览器走一个代理客户端，app 等桌面端走另一个。
切换客户端时，最好先在旧客户端里断开连接，再从托盘完整退出，确认普通网络恢复后，再打开另一个客户端。
机场为什么还要推自己的客户端
聊到这里就会有一个问题：既然官方客户端的体验还不如成熟的通用客户端，为什么越来越多机场还是要推自己的客户端，甚至配合订阅阅后即焚？
因为机场考虑的不只是“用户连得快不快”，还要考虑订阅和节点配置会不会被长期、低成本地拿走。
封闭客户端和阅后即焚看起来是两件事，实际目的很接近：**把以前长期暴露在外面的订阅和节点配置，尽量收回到机场自己可控制、可撤销的流程里。**
阅后即焚用起来确实不方便
现在不少机场的订阅链接只在几分钟到十几分钟内有效。用户需要登录后台复制，导入客户端后链接很快就失效。
正常情况下，节点主要依赖域名，配置也不会天天变化，所以旧节点通常还能继续使用。但缺点同样明显：
- 不能再用同一个订阅链接更新节点和查看已用流量；
- 入口域名被污染后，只能重新登录官网获取订阅；
- 如果官网恰好也需要代理才能访问，就容易形成死循环；
- 像我这种习惯每天刷新订阅信息的人，会非常不适应。
从用户角度看，这就是实打实的体验倒退。但站在机场角度，特别是那些名气大、规模大的机场，也不是完全不能理解。
它们真正防的是什么
阅后即焚和封闭客户端，防不住真正下决心研究某个机场的人。
如果对方愿意花钱买号、研究客户端、抓包甚至逆向，只要客户端最终要连上节点，连接信息就一定会在本地某个环节出现。这些措施只能提高门槛，不能把配置变成永远看不见的秘密。
它们真正减少的，可能是几类更常见的低成本泄露：
- 用户把订阅链接转发给别人，或者截图时没有打码；
- 用户把订阅丢进在线订阅转换器、Sub-Store 或测速工具；
- 某些程序拿到固定链接后，定时拉取最新节点；
- 旧订阅链接已经在网上流传，仍然可以持续获取新配置；
- 批量采集程序用很低的成本扫一堆机场。
以前的固定订阅链接就像一张长期饭卡。别人捡到了，不仅今天能吃，明天也能吃，下个月机场换了菜，他还能继续吃。
阅后即焚就是让这张饭卡很快过期。封闭客户端则是尽量不发饭卡，只让你刷官方 App 进食堂。
它们不完美，但确实能减少很多无意识泄露，也能让机场在出问题时更快撤销链接、锁定账号或者更换配置。代价就是正常用户更新订阅更麻烦，也更依赖机场自己的客户端和官网。
能理解，但代价是用户体验下降
我的看法很简单：机场做官方客户端是好事，阅后即焚也有现实作用。特别是规模大的机场，完全不做保护，别人长期采集最新配置的成本确实太低了。
但把官方客户端做成唯一入口，会让用户在客户端出现问题或者本机代理状态混乱时缺少排障选择。对新人，可以默认推荐官方客户端；对熟悉 Clash、Surge、Loon、Shadowrocket 的用户，最好保留短期生成、限制设备、限制更新频率并且可以随时撤销的标准订阅。
这样机场仍然可以控制泄露风险，用户需要排障时，也还有一个能够对照和继续上网的选择。
我个人还是更喜欢把订阅放进自己熟悉的通用客户端里，主要是切换、查看日志和排查端口更方便。这是使用习惯，不代表已经证明官方客户端一定不稳定。
5/5 - (1 vote)