清单怎么读

这张清单不是节点名列表，而是按「你能用它做什么」组织的。每一组给出节点数、覆盖范围、延迟量级与适合用途，你可以直接对着自己的需求找组，不必逐个记节点名。

三个字段的含义

节点数是当前可参与选路的数量，不含维护中的。覆盖范围指该组节点所在的国家与地区数量。延迟量级取白天时段的中位值，夜间高峰会上升，但组间排序基本不变。

为什么不列出全部 132 个节点名

节点名会随维护变化，列出来很快就会过期。对使用者有用的信息是「这个方向有多少可选、量级如何」，而不是某个具体节点的编号。需要看实时节点时，客户端列表永远比网页准。

六个方向的总览（2026-11-11 采样）

方向	节点数	覆盖数	延迟中位	抖动中位	首选用途
东亚	11	3	19 ms	9 ms	视频、游戏、会议
东南亚	9	3	46 ms	14 ms	长连接、下载
南亚与中东	7	5	118 ms	24 ms	区域站点浏览
欧洲	29	21	168 ms	16 ms	学术资源、欧洲区服务
北美	34	2	152 ms	20 ms	海外站点、协作
长尾地区	28	15	196 ms	22 ms	特定地区访问
合计	118	47	—	—	另有 14 个节点处于维护或降权

为什么合计不等于 132

表里的 118 是采样时刻处于正常状态的节点，另有 14 个处于维护或降权状态，不参与当轮打分。这个数字随时段变化，维护窗口多在凌晨。

东亚组：延迟最低的一档

东亚组共 11 个节点，分布在东京、大阪、首尔三地，其中 4 个为双上游节点。这一组的延迟中位 19 毫秒，抖动中位 9 毫秒，是六组里唯一能同时满足视频、游戏与会议三类用途的。

双上游与单上游的差别

双上游节点接入两条不同的上游运营商，一条拥塞时可切到另一条。单上游节点只有一条路径，拥塞时只能等。抗拥塞能力的差别在夜间高峰最明显。

夜间高峰的实际表现

20:00 到 23:00 是东亚组的压力时段。抖动中位会从 9 毫秒升到 25 毫秒左右，个别单上游节点会超过 50 毫秒并短暂降权。双上游节点在这段时间的抖动通常仍在 20 毫秒以内。

东南亚组：吞吐稳定但抖动偏大

东南亚组 9 个节点，覆盖新加坡、曼谷、吉隆坡。这一组的特点是绕行少、吞吐稳，但上游带宽波动大，抖动中位 14 毫秒，夜间可达 35 毫秒。

适合什么，不适合什么

适合长连接下载、备份、以及访问区域内站点。不适合对战类游戏，因为抖动超过 20 毫秒时，游戏内的位置同步会出现明显偏差。

东南亚组三个地点的用途判断

地点	节点数	延迟中位	抖动中位	适合	不建议
新加坡	4	46 ms	11 ms	下载、长连接、网页	对战游戏
曼谷	3	52 ms	16 ms	视频、浏览	会议
吉隆坡	2	58 ms	18 ms	备份、同步	实时音视频

维护窗口

东南亚组的维护多安排在凌晨 03:00 到 05:00，单次维护时长 10 到 20 分钟。维护期间该节点从候选队列移除，其他节点接管。

南亚与中东组：跳跃多，离群值常见

这一组 7 个节点覆盖 5 个国家，延迟中位 118 毫秒。跨境跳跃次数多，因此偶发 200 毫秒以上的离群值，属于路由抖动而非节点故障。

遇到离群值怎么判断

单次超过 200 毫秒不必立刻换节点。观察两分钟，若三次采样都偏高，才是真的劣化。引擎本身也是按连续三次判定的，手动干预反而更容易误判。

欧洲组：节点最多的两档之一

欧洲组 29 个节点覆盖 21 个国家和地区，是节点数第二多的一组。同城多节点普遍，替换余地大，是这一组最实用的特征。

同城多节点意味着什么

以法兰克福与阿姆斯特丹为例，各有 3 个以上节点。当一个节点拥塞时，同城另一个节点通常仍可用，客户端会在两者间重新打分，表现为「欧洲方向一直有可用线路」。

欧洲组主要城市节点分布

城市	节点数	延迟中位	抖动中位	备注
法兰克福	4	168 ms	16 ms	欧洲区游戏首选
阿姆斯特丹	3	175 ms	18 ms	学术资源访问稳定
伦敦	3	182 ms	19 ms	英区服务
巴黎	2	178 ms	17 ms	西欧覆盖
其他城市	17	190 ms	21 ms	单节点覆盖为主

跨欧内部跳转

欧洲内部的站点互访，延迟可能低于跨洲值。因为节点之间可能走区域内直连，不必回到国内再出去。这一点在访问欧洲本地服务时尤其明显。

北美组：节点最多，东西两岸差 60 毫秒

北美组 34 个节点，是六组里最多的。节点集中在西海岸与东海岸两带，两岸延迟差约 60 毫秒，选择时要看目标站点在哪一侧。

西海岸与东海岸怎么选

访问亚太中转或西海岸服务选西海岸节点，访问美东服务选东海岸。选错方向会多出一次跨洲跳跃，延迟增加 60 毫秒以上。

长尾组：覆盖优先，性能其次

长尾组 28 个节点覆盖 15 个国家和地区，多为单节点覆盖。这一组的意义是「能到达」，不是「很快」。仅在需要访问特定地区站点时使用。

单节点地区的风险

只有一个节点的地区，节点维护时该地区会短暂不可用。如果某个业务依赖该地区，建议提前确认维护窗口，而不是在不可用时才发现。

节点状态与维护

节点状态分四档：正常、降权、维护、下线。四档在客户端列表里的表现不同，理解这四档能省掉很多「节点怎么不见了」的困惑。

四档节点状态的含义

状态	是否参与选路	客户端表现	持续时长	使用者该做什么
正常	参与	正常显示与打分	—	无需处理
降权	参与但排后	排序靠后，评分偏低	数小时至一天	不必手动干预
维护	不参与	列表不显示或灰显	10–20 分钟	等待或换方向
下线	不参与	列表移除	数天至长期	换用同方向其他节点

降权与维护的区别

降权是评分策略，节点仍可用，只是排在后面；维护是主动移除，节点不可用。降权通常由拥塞引起，会自行恢复；维护是计划行为，有明确窗口。

为什么节点会突然消失

最常见的原因是进入维护。其次是所在地区网络策略调整，导致该节点无法提供服务。两种情况都不需要使用者处理，引擎会自动用其他节点填补。

怎么挑：按用途的四条建议

挑节点不必看全部 132 个，按用途走四条建议即可。每条建议都对应一个明确的判据，不需要试错。

1. 日常浏览与视频：选东亚组：延迟低、抖动小，且双上游节点多
   • 不必手动锁定，交给自动选路
   • 夜间卡顿时先看抖动是否超过 40 ms
2. 对战游戏：选东亚双上游：双上游抗拥塞，抖动更稳
   • 锁定节点避免中途切换
   • 抖动超过 10 ms 时换同城另一节点
3. 大文件下载：选东南亚或北美：吞吐稳定，长连接不易断
   • 避开本地高峰时段
   • 不要频繁换节点，重传代价高
4. 访问特定地区：选对应组并锁定：目标优先于速度
   • 锁定后不自动切换
   • 用完及时解除锁定

节点数量与体验的关系

节点多不等于更快，但节点多意味着替换余地大。这一节解释为什么「132」这个数字本身不是卖点，真正有用的是同一方向内的可选数量。

可替换性才是关键指标

单个方向的节点数决定拥塞时的腾挪空间。东亚 11 个、北美 34 个、欧洲 29 个，这三个方向在任何时段都有替代选项；长尾地区多为单节点，没有腾挪空间。

各方向的可替换性评估

方向	节点数	同城多节点	拥塞时可腾挪	评估
东亚	11	有	是	强
东南亚	9	有	是	较强
南亚与中东	7	少	有限	一般
欧洲	29	普遍	是	强
北美	34	普遍	是	强
长尾	28	极少	否	弱

节点数与延迟无关

节点数增加不会降低延迟，延迟由物理距离与路由决定。增加节点只提高可用性，不提高速度上限。把这两件事分开看，能避免对「节点多」的过度期待。

采样方法与局限

本页所有读数来自同一套采样流程：对每个方向的代表节点做 10 次 443 建连，取中位值，剔除超时样本。采样环境是有线千兆接入的 Windows 主机，未开启其他隧道。

为什么取中位而不是平均

建连耗时的分布是右偏的，偶发尖峰会明显拉高平均值。中位值不受离群值影响，更能代表「多数情况下」的体验。

这些数字不该怎么用

不要把它当作你所在地区的绝对预期，也不要用它来判断某个具体节点此刻的状态。它的正确用法是对比方向之间的相对关系，以及理解量级。

节点命名怎么读

客户端列表里的节点名由三段组成：地区标识、序号、上游标记。看懂这三段，不用点开详情就能判断这个节点是不是你想要的。

三段各代表什么

第一段是地区标识，用两个字母缩写表示接入点所在城市。第二段是序号，同城多节点按接入顺序编号。第三段是上游标记，标注该节点接入了几个上游运营商。

为什么同城要编序号

同城多节点分属不同上游，性能差别不小。编序号是为了让使用者能区分「同一个城市的不同线路」，而不是把它们当成一个整体。

节点命名的三段结构与示例说明

段位	含义	取值范围	用途	注意
地区标识	接入点所在城市	按城市缩写	判断方向	不等同于出口地区
同城序号	同城第几个节点	从 1 起	区分同城不同线路	序号与性能无关
上游标记	接入的上游数量	单或无	判断抗拥塞能力	双上游更抗拥塞
状态标记	当前是否降权	有或无	判断是否排后	降权仍可用
分组归属	所属方向组	六组之一	决定是否参与打分	可手动切换分组

各地区维护窗口对照

维护窗口决定了你什么时候可能遇到「节点不见了」。下表按方向列出常见窗口与典型时长，便于安排依赖特定地区的工作。

六个方向的常见维护窗口（按当地凌晨时段）

方向	常见窗口	典型时长	影响范围	对使用者的建议
东亚	02:00–04:00	10–15 分钟	单节点，双上游自动接管	无需处理
东南亚	03:00–05:00	10–20 分钟	单节点	换同方向其他节点
南亚与中东	01:00–03:00	15–25 分钟	可能整组短暂降权	避免在该时段依赖
欧洲	02:00–05:00	10–20 分钟	同城多节点轮流	通常无感
北美	03:00–06:00	15–25 分钟	单节点或同城轮流	换另一侧节点
长尾	01:00–06:00	20–40 分钟	单节点地区直接不可用	提前确认或备方案

为什么维护都在凌晨

凌晨是流量低谷，影响面最小。维护内容包括上游切换、内核升级与链路复测，多数不影响正在连接的会话，因为引擎会先把流量迁到其他节点再动手。

维护期间的体验

如果自动选路生效，维护基本无感：客户端在采样发现节点不可用后，会在下一轮切换到同方向其他节点，中断通常在 3 秒内。手动锁定该节点的使用者则会遇到断线。

按用途的节点适配表

同样是「访问海外站点」，视频、游戏、会议、下载对节点的要求完全不同。下表把六组与五类用途交叉对照，给出推荐与不推荐。

六组节点与五类用途的适配关系

方向	视频	对战游戏	语音会议	大文件下载	网页浏览
东亚	推荐	推荐	推荐	可用	推荐
东南亚	推荐	不推荐	可用	推荐	推荐
南亚与中东	可用	不推荐	不推荐	可用	可用
欧洲	推荐	可用	可用	推荐	推荐
北美	推荐	可用	可用	推荐	推荐
长尾	可用	不推荐	不推荐	可用	可用

为什么东南亚不推荐对战游戏

不是延迟问题，是抖动问题。东南亚组夜间抖动可达 35 毫秒，对战游戏的位置同步对抖动比对延迟敏感得多，抖动大的时候会出现「打不中」的体感。

为什么南亚与中东不推荐会议

该方向跨境跳跃多，偶发离群值。会议对连续性要求高，一次 200 毫秒以上的尖峰就会造成语音断续。相比之下网页浏览对尖峰不敏感。

实测对比：三个方向的同一时段读数

为了让「量级差异」更具体，这里给出同一时段三个方向的完整读数。采样方法与全站一致，每节点十次建连取中位。

东亚、东南亚、北美三方向的同轮采样（2026-11-11 10:00）

读数	东亚（东京）	东南亚（新加坡）	北美（洛杉矶）	差值说明
延迟中位	19 ms	46 ms	152 ms	东亚与北美差 133 ms
延迟最小	14 ms	38 ms	141 ms	最小值反映最优路径
延迟最大	32 ms	61 ms	188 ms	最大值反映拥塞时刻
抖动	9 ms	14 ms	20 ms	跨洲抖动更大
丢包	0.2%	0.4%	0.3%	三方向均达标
评分	93	86	81	评分综合四项
样本数	10	10	10	均满足最小样本

怎么读这张表的差值列

差值列不是算出来的，而是用来提醒你注意量级。跨洲差 133 毫秒意味着任何实时交互都会被感知，而 27 毫秒的差距在日常浏览里几乎察觉不到。

节点状态的四个观察维度

判断一个节点好不好，不只看延迟。下面四个维度合起来才能说明它是否值得用，缺一项都可能误判。

维度一：当前延迟

反映此刻的往返时间。单次读数参考价值有限，应看连续几轮的走势，而不是某一时刻的数字。

维度二：抖动

反映延迟的波动幅度。抖动大的节点即使延迟低，体验也会不稳，尤其影响语音与游戏。

维度三：丢包

反映报文丢失比例。丢包超过 1% 时，长连接应用会出现重传与卡顿，会议语音开始断续。

维度四：历史稳定性

反映该节点过去七天的达标率。这一项权重只有 10%，但作用是压住「一时快、长期差」的节点。

四个维度的权重与判断阈值

维度	权重	正常阈值	警戒阈值	影响的应用
当前延迟	45%	东亚 ≤ 60 ms	80 ms 以上	所有交互类应用
抖动	15%	≤ 20 ms	40 ms 以上	语音、游戏、视频
丢包	30%	≤ 0.5%	1% 以上	语音、长连接、下载
历史稳定性	10%	≥ 90% 达标率	70% 以下	长期连接的可靠性

节点选择的六个常见错误

下面六条是编辑部在读者反馈里归纳出来的高频错误。每一条都对应一个具体的判断偏差，改掉之后选节点的命中率会明显提高。

错误一：只看延迟，不看抖动

延迟 40 毫秒、抖动 45 毫秒的节点，体验通常差于延迟 60 毫秒、抖动 8 毫秒的节点。语音与游戏对抖动更敏感，只看延迟会选到「看起来快但一直在卡」的线路。

错误二：认为节点序号靠前更快

序号只代表接入顺序，不代表性能。同城序号 3 的节点可能比序号 1 的节点快得多，因为它们的上游不同。判断依据只能是实时评分。

错误三：频繁手动换节点

每次切换都会重建连接，正在进行的下载与上传需要重新协商。频繁切换的净效果通常是变慢，因为重传与握手的开销大于换来的收益。

错误四：把维护当成故障

节点在维护窗口内消失属于计划行为。此时引擎会自动接管，使用者不需要做任何事。把它当作故障去反馈，反而会错过正常的替代路径。

错误五：跨洲替换求「更快」

跨洲延迟由物理距离决定，替换节点不会突破下限。为了快几毫秒换到另一个洲，代价往往是抖动与丢包同时变差。

错误六：忽略本地出口

本地宽带上行拥塞时，任何节点都会变慢。此时正确动作是查本地占用，而不是在节点列表里反复试。

六个错误的识别信号与纠正动作

错误	识别信号	纠正动作	预期改善
只看延迟	延迟低但语音断续	同时看抖动与丢包	语音连续性提升
迷信序号	换了序号反而更慢	按评分排序选	命中率提升
频繁换节点	下载速度反复归零	一段时间内固定节点	吞吐稳定
把维护当故障	凌晨节点消失	等待或用自动选路	减少无效操作
跨洲求快	换洲后更卡	按目标站点所在洲选	延迟与抖动同时改善
忽略本地出口	所有节点都慢	检查本地带宽占用	定位真实瓶颈

不同地区的可访问范围说明

节点所在地区与可访问范围不是一回事。一个地区的节点可能能访问多个区域的站点，也可能因当地策略限制只能访问部分。本节把常见组合列清楚。

接入点地区与出口地区

接入点是客户端连上的位置，出口是流量最终出去的位置。多数情况下两者一致，但部分节点因上游路由安排会不一致。判断依据是客户端首页显示的出口地区字段。

哪些情况会出现不一致

常见于跨区域中转节点。这类节点的接入点在 A 地，出口在 B 地，目的是用 B 地的出口访问 B 地站点。遇到不一致时不必担心，看出口地区是否符合需求即可。

节点集合的变化规律

132 这个数字不是固定的。节点会新增、下线、合并，这些变化发生在服务端，客户端不升级也能看到。理解变化规律，能避免把正常调整当成异常。

新增节点的规律

新增多发生在需求增长的方向，通常是同城增加第二个上游。新增后该方向的评分分布会变，表现为「原来排第一的节点排到了第二」。

下线节点的规律

下线通常因为上游合约到期或性能长期不达标。下线前会先经历一段降权期，评分持续偏低，然后才从列表移除。

节点集合变化的四种情形与使用者的应对

情形	前置信号	对使用者的影响	应对
同城新增节点	该方向节点数增加	排序可能变化	无需处理
节点降权	评分持续偏低	自动排到后面	无需处理
节点下线	降权一段时间后消失	该地区少一个选项	用同方向其他节点
整组调整	同组多个节点同时变化	该方向短期波动	换方向或错峰

为什么不要盯着单节点

单节点的状态变化很快，盯着它没有意义。对使用者有价值的是方向级的可用性：这个方向现在有几个可用节点、评分分布如何。这也是本页按方向组织的原因。

编辑部实测记录：一天里的三段变化

为了让「时段影响」这件事具体一些，编辑部在同一天的三段时间对东亚与北美两个方向各做了一轮采样。三段分别是上午、傍晚与深夜，每段仍按每节点十次建连取中位。

同日三段采样的对比（2026-11-11）

时段	东亚延迟	东亚抖动	北美延迟	北美抖动	观察
10:00（上午）	19 ms	9 ms	152 ms	20 ms	两个方向均处于常态
19:00（傍晚）	24 ms	16 ms	161 ms	23 ms	东亚抖动上升明显
21:00（高峰）	31 ms	25 ms	178 ms	26 ms	东亚延迟与抖动同时上升
23:30（深夜）	20 ms	11 ms	154 ms	21 ms	回落至接近上午水平

傍晚为什么比高峰还稳一点

傍晚的流量是渐进的，高峰是集中的。渐进上升时引擎有时间逐步迁移，集中上升时多个节点同时劣化，可迁移的余地变小。这就是高峰时段体感更差的原因。

深夜回落说明什么

说明拥塞是时段性的，不是节点性能问题。同一个节点在深夜能回到接近上午的读数，因此判断节点好坏不能只看一次采样。

节点数量的横向对照

把本站的节点分布与常见规模放在一起对照，可以看出「132 个节点」在数量上处于什么位置。这不是排名，只是量级参照。

不同规模的节点集合与可替换性的关系

规模区间	典型节点数	单方向可选数	拥塞时的腾挪空间	适用判断
小规模	20 个以下	2–4 个	很小	单一用途尚可
中规模	20–60 个	5–10 个	有限	日常够用
本站规模	132 个	7–34 个	较大	多用途并行可用
大规模	200 个以上	20 个以上	大	边际收益递减

规模不是越大越好

节点数到一定程度后，边际收益递减。真正决定体验的是「你常用方向的节点数」与「这些节点的抖动水平」，而不是总数。132 个里如果你只用东亚，实际相关的只有 11 个。

编辑器说明：本页的组织逻辑

本页不按「节点编号」组织，而按「方向 + 用途」组织。原因很直接：节点编号对使用者没有决策价值，方向与用途才是。同一份数据换一种组织方式，可用性差别很大。

具体做法是把 132 个节点先按地理位置归成六组，再给每组标注延迟量级、抖动量级与适配用途。使用者只需要先确定自己要做什么，再找到对应的组，不必逐个比节点。

这套组织方式有一个明确的代价：看不到单个节点的实时状态。这是刻意的取舍。单个节点的状态变化以分钟计，网页永远滞后于客户端；而方向级的量级差异以季度计，网页反而更可靠。

常见问题

下一步

看完清单，建议接着看评分算法，理解客户端为什么把某个节点排在前面。