只有一台设备连不上机场?用对照法三步锁定变量

故障的范围本身就是证据。同一份订阅,群里其他人用得好好的,或者你自己的手机毫无问题、只有这台电脑不行——这句话已经替你排除掉了三样东西:机场的服务端、订阅里的节点内容、以及账号的有效期。它们对所有设备是同一份,不可能只对一台设备失效。

剩下的嫌疑人不多,大致是系统代理设置、安全软件规则、端口占用、客户端版本与协议支持、账号的在线设备计数这五类。麻烦在于它们在界面上的长相高度雷同:要么是一片红色的超时,要么是绿色的延迟配上打不开的网页。光看现象分不出来,必须靠改变条件。

所以别急着卸载重装。下面这三组对照做完不到十分钟,能把范围压缩到一格,后面的动作才不至于全靠碰运气。

「别人能用」为什么是排查里最值钱的一条信息#

绝大多数排查的困难在于嫌疑人太多。而「同一份订阅在另一台设备上正常」这一条,一次性砍掉了链路上占比最大的一段。

把范围判断放在最前面,还能避免一类很常见的浪费:在单机故障上反复重导订阅、反复换节点。这两个动作作用的对象都是所有设备共享的那一份数据,对只发生在一台机器上的问题毫无影响。

如果你的现象其实落在第一行,那要走的是另一条路,节点全部超时的判据里有完整流程;落在第三行则应该转向换网络才失效的排查。本文只处理第二行。

三组对照怎么做,每一组分别砍掉什么#

对照实验的规矩只有一条:一次只动一个变量。很多人做无用功,是因为换设备的同时换了节点,或者换客户端的同时也换了协议,结果无论通不通都得不出结论。

1. 同一订阅,换一台设备。 把订阅链接原样导入另一台手机或电脑,选同一个地区的节点。这一组验证的是订阅与账号是否可用。别的设备正常,说明问题在这台机器上;别的设备也不行,说明你判断错了范围,应该回到上一节的第一行。
2. 同一设备,换一个客户端。 在出问题的这台机器上装另一个客户端,导入同一份订阅。这一组把客户端自身的配置、版本和协议支持单独摘出来。换个客户端就好,基本可以锁定是原客户端的版本或设置问题;换了还是不行,说明卡点在系统层面,与哪个客户端无关。
3. 同一客户端,换一个账号。 借用另一份可用订阅(哪怕是同一家机场的另一个账号)导入当前客户端。这一组专门验证账号侧的限制,尤其是在线设备数。别人的订阅在你机器上一切正常,那这台设备的环境是干净的,问题在你的账号状态。

三组结果的组合可以直接读出结论:

三组对照之间要留出间隔。有些面板对在线会话的清理有延迟,前一组测试留下的连接可能还挂着,紧接着做下一组容易读到假结果。每组之间等两三分钟,把上一组的客户端完全退出。

在线设备数被占满,客户端会是什么样子#

设备数上限是这类故障里最容易被忽略的一项,因为它的表现完全不像「超限」。多数机场把同时在线设备数写在套餐页上,常见区间大致在 3 到 10 台,具体数值和计数口径以各家页面的说明为准。

需要注意的是,它计的通常是同时在线的连接来源,而不是安装数量。一台开着虚拟网卡模式的电脑、一部后台没退干净的手机、一个家里的路由器,可能就已经把额度用掉大半。

自查动作很简单:把所有其他设备的客户端彻底退出(不是最小化),等三到五分钟,再单独连这一台。恢复正常就基本确认了。真要清理残留会话,只能在用户中心或通过工单请商家操作。

安全软件和系统策略拦截,会留下哪些指纹#

代理客户端要做的事情——监听本地端口、创建虚拟网卡、改写系统代理——恰好是安全软件重点盯防的几类行为。被拦时它未必弹窗,而是静默阻止,于是你只看到客户端「装了但不工作」。

日志里的措辞是最直接的线索。下面是一段结构示例,用来说明该找什么样的行,地址一律用 example.invalid,不是真实节点:

[warn] failed to bind 127.0.0.1:7890: permission denied
[info] connecting to node-hk-01.example.invalid:443
[error] dial tcp: connectex: 由于目标计算机积极拒绝,无法连接

第一行指向本地端口拿不到权限,第三行则是出站被挡。两者的处理方向完全不同,不看日志硬猜很容易反着做。

端口被别的程序占了,三十秒确认#

本地监听端口冲突的表现很有迷惑性:客户端界面一切正常,节点也能测出延迟,但浏览器的请求根本没进到客户端里,而是被另一个占着同一端口的程序吃掉了。

在 Windows 下用这两条命令确认(7890 只是常见的默认值,换成你客户端里实际写的那个):

netstat -ano | findstr ":7890"
tasklist | findstr "12345"

第一条列出占用该端口的进程号,第二条把进程号翻译成程序名。macOS 或 Linux 下用:

lsof -nP -iTCP:7890 -sTCP:LISTEN

看到的名字不是你的客户端,就说明端口被抢了。处理有两条路:关掉那个程序,或者在客户端设置里把本地端口改成一个没人用的值(比如 7891),改完记得同步修改系统代理或浏览器插件里填的端口号,否则两边对不上还是不通。

重装系统或换新设备之后失效,漏掉的往往是同一步#

换机之后连不上,几乎都不是「新设备不兼容」,而是旧环境里那些你早就忘了自己配过的东西没有跟过来。按这个顺序补齐,基本能覆盖绝大多数情况:

1. 开启系统的自动时间同步。 部分协议在握手阶段做时间校验,新装系统的时区或时间偏差过大时,所有节点都会连不上。这一步耗时最短、命中率最高,值得放在第一位。相关的证书与时间类报错在DNS、证书与时间错误的排查里有更完整的对照。
2. 确认虚拟网卡驱动装好了。 依赖虚拟网卡的模式在新系统上需要单独安装驱动,不装的话开关能打开、流量却不走。
3. 重新在用户中心复制订阅链接。 有些面板在检测到异常时会重置订阅密钥,旧链接看起来格式没变,拉到的却是空内容。
4. 把新设备加进安全软件的信任列表。 新装的安全软件默认策略往往比你旧机器上调过的严格。
5. 检查旧设备是否还占着在线额度。 换机不等于旧设备自动下线,尤其是那台已经被你放进抽屉的旧手机。

换设备时把订阅链接直接截图传过去是常见做法,但订阅地址等同于账号凭证。发到群里或让别人代扫,等于把套餐送出去,也会立刻把设备数吃满。

确认是协议兼容性问题,还剩哪些补救办法#

如果对照结果落在「换个客户端就好」这一格,那多半是协议支持跟不上。新协议的落地速度往往快于客户端的更新速度,老版本遇到不认识的节点类型,可能直接跳过、也可能解析成一条连不上的空配置。

升级客户端是首选,但不是每台设备都能升——老系统版本可能根本装不上新客户端。这时候现实的做法是回到订阅里挑一个兼容性更好的协议分组,多数机场会在同一批服务器上同时提供几种协议以覆盖不同环境,具体差异可以参考Reality 的伪装原理和几种协议的取舍。各客户端的配置细节则分别在 Clash 专题、Shadowrocket 专题和 v2rayN 专题里。

只有当同一台设备上多个客户端、多种协议都试过仍然只有你的账号不行,而别人的订阅一切正常时,才轮到考虑服务方的兼容性范围是否够用。

小结#

单机失效自带一个干净的实验条件:所有设备共享的东西都已经被证明是好的,剩下的只可能在这台机器上。三组对照的顺序不能乱,换设备确认范围、换客户端摘出软件层、换账号摘出账号层,每一组都只动一个变量。设备数超限的表现最不像超限,全部退出只留一台是最快的判据。安全软件拦截和端口占用要靠日志里的措辞和 netstat 的输出来区分,凭现象猜几乎必错。重装客户端应该排在对照之后,而不是之前。