节点旁边那个延迟数字,其实在骗你 ⏱️

每个代理客户端都会在服务器旁边显示一个数字。数字越小看起来越好, 于是你点了最小的那个,然后就不管了。

那个数字是往返时间(RTT)—— 一个很小的测试请求发出去再回来花了多久。 它确实能回答一个问题:这个节点还活着吗,大概有多远?

但它几乎不能告诉你,你的下载会有多快。

---

📊 实测数据长什么样

下面是在同一份订阅、同一台设备、同一个时段里测出来的真实数据 —— 延迟是客户端报告的,吞吐是真的去拉数据测出来的:

再看一眼第一行。延迟最好的那个节点,实际只跑出了不到 1 Mbps。 一个延迟更差的节点,吞吐是它的六十倍。而节点 C 看起来 651 ms 完全正常, 它能完成握手,却几乎传不动任何数据。

如果你按屏幕上的数字挑,你恰好会挑中这个列表里表现最差的那个。

---

🤔 为什么两者没有关系

延迟量的是一个很小的请求跑一个来回。吞吐量的是这条链路能持续扛多少数据。 这是两种不同的物理属性。

一个节点可以几乎瞬间回应一个小探测包,同时却:

• 和一大堆用户共享一条已经跑满的上行,
• 对每条连接单独限速,
• 用着一种「小请求处理得好、大流量传输很糟」的传输方式。

反过来也成立:一个地理上很远、延迟平平的节点,可能正好走在一条优质且不拥塞的路径上, 数据跑得非常漂亮。

回应快,不等于管子粗。

---

🎲 第二个问题:有些节点拿到了它不该拿到的流量

大多数客户端都提供自动分组。而这个分组用什么方式挑节点,比应用里大多数设置项都更重要。

有些策略按轮次、按哈希、或者按会话来分配连接。它们把负载摊得很均匀 —— 但不按健康状况排序。如果你的订阅里含有从你的网络根本连不通的节点, 那些节点照样会分到它们那一份真实流量。

这种故障有个很典型的特征:能用,然后突然不能用,毫无规律。 有的页面打得开,有的一直转圈。它感觉像是「网络不稳定」,而不像某个节点挂了 —— 于是人们往往找错方向。

在同一份订阅上实测:走一个不看健康状况的策略,连续三次请求得到 69.9 Mbps、然后 0.0、然后 0.6。换成按健康状况排序的策略,同一份订阅、同一个时段: 42.7 / 29.4 / 26.0 / 59.4 / 39.2 Mbps —— 五次全中,零失败。

同样的服务器,同样的网络。 差别完全在于分组把每条连接交给了谁。

---

🕰️ 第三个问题:健康数据过期了

延迟数据是按固定周期刷新的,而在很多客户端里,隧道空闲时这个刷新会停掉。

于是你早上连上,选择逻辑拿来做判断的,是几个小时前测的那批数据 —— 那时候某个现在已经挂了的节点恰好是最快的。客户端显示已连接。什么都打不开。 其实什么都没坏,只是这个决定是基于过期数据做出的。

这也是为什么 AI Booster 会在隧道一连上就立刻重测一遍节点健康度, 而不是干等下一次周期性扫描。

---

✅ 应该怎么做

1. 别只看 ms 数字挑节点。 用它来排除掉「已经死了」和「特别远」的 —— 而不是用来选优胜者。
2. 去测你真正关心的那种传输。 打开网页主要受往返次数影响,反映不出带宽上限。拉一个真实文件试试。
3. 优先用按健康状况排序的选择策略,让连不通的成员被排除在外,而不是照样分到你的流量。
4. 闲置之后重新测一次。 几小时前的数字描述的是另一个时刻的网络。
5. 先确认隧道真的在承载你的流量。 连接前后各查一次公网 IP —— 如果地址没变, 那就是有东西绕过了隧道,再怎么换节点都没用。

---

🧭 AI Booster 在这件事上怎么做

AI Booster 会显示由核心实测的 per-node 延迟,默认使用按健康状况排序的 选择策略(让连不通的节点留在候选之外),并且在你连上的那一刻就重新测量, 而不是信任一份过期的扫描结果。

它仍然会把 ms 数字显示给你 —— 那个数字是有用的。 只不过现在你知道它代表什么、以及不代表什么了。

---

延伸阅读:节点选择与延迟数字的含义 · 故障排除