会议怎么选时段
固定会议尽量避开 20:00–22:00；无法避开时，选负载低于 50% 的备用节点。
01TABLE
主力节点：城市、数量与线路
下表只列主力节点，不含备份与临时扩容节点。延迟是中国大陆主要城市到该城市的往返中位，丢包为同期采样中位。
| 城市 | 区域 | 节点数 | 延迟中位 | 丢包 | 线路 |
|---|---|---|---|---|---|
| 香港 | 东亚 | 11 | 26 ms | 0.2% | BGP 多线 |
| 东京 | 东亚 | 9 | 41 ms | 0.3% | 专线 + BGP |
| 首尔 | 东亚 | 6 | 47 ms | 0.4% | BGP |
| 新加坡 | 东南亚 | 8 | 54 ms | 0.3% | 专线 + BGP |
| 洛杉矶 | 北美 | 8 | 146 ms | 0.5% | 专线 |
| 圣何塞 | 北美 | 7 | 151 ms | 0.6% | BGP |
| 法兰克福 | 欧洲 | 6 | 176 ms | 0.4% | 专线 |
| 伦敦 | 欧洲 | 6 | 184 ms | 0.5% | BGP |
| 悉尼 | 大洋洲 | 5 | 139 ms | 0.7% | BGP |
| 迪拜 | 中东 | 4 | 152 ms | 0.6% | 专线 + BGP |
说明：同城多入口的延迟差异最大可达 18 ms，表内取该城市全部入口的中位数。
| 区域 | 主力节点 | 日均分配占比 | 备份节点 |
|---|---|---|---|
| 东亚 | 26 个 | 48% | 15 个 |
| 东南亚 | 8 个 | 11% | 19 个 |
| 北美 | 15 个 | 17% | 16 个 |
| 欧洲 | 12 个 | 14% | 21 个 |
| 其他 | 9 个 | 10% | 14 个 |
02LOGIC
选路的四个动作
从点下连接到隧道建立，中间发生四件事。理解顺序，你就知道为什么「手动选最快的」有时反而不如自动。
- 筛候选
- 按出口 IP 取同区域节点，最多 5 个。
- 维护中的节点与负载超阈值的节点先剔除。
- 并发探测
- 每节点 8 个探测包，取中位数。
- 探测结果同时记录抖动，不只看延迟。
- 加权排序
- 延迟 0.5、抖动 0.3、负载 0.2。
- 抖动超过 12 ms 直接降级到末位。
- 握手复核
- 比探测值高 40% 以上则重选。
- 稳定 60 秒后写入会话记录。
据 2026 年 10 月的调度记录，约 11% 的连接被改派到邻城节点，主要发生在 20:00 至 22:00；改派后抖动中位从 13 ms 降到 7 ms，代价是延迟增加 4 至 9 ms。这个取舍由加权排序自动完成，不需要手动干预。
03PEAK
高峰时段的真实代价
同一条线路，晚高峰与凌晨可能差 20 ms 以上。下表按五个时段给出三个节点的延迟与抖动，用来决定「什么时候做重活」。
| 时段 | 香港 | 东京 | 洛杉矶 | 适合做什么 |
|---|---|---|---|---|
| 00:00–08:00 | 21 / 2 ms | 34 / 3 ms | 128 / 4 ms | 大文件与系统更新 |
| 08:00–18:00 | 26 / 4 ms | 41 / 5 ms | 143 / 6 ms | 办公与视频会议 |
| 18:00–20:00 | 32 / 7 ms | 49 / 9 ms | 161 / 10 ms | 游戏开始受影响 |
| 20:00–22:00 | 40 / 11 ms | 60 / 13 ms | 178 / 14 ms | 改用低负载节点 |
| 22:00–24:00 | 29 / 5 ms | 45 / 6 ms | 150 / 7 ms | 逐步回落 |
读法：延迟上升 15 ms 以内属于正常波动；抖动翻倍才是需要换节点的信号。
同一批采样里，香港节点晚高峰的抖动中位为 11 ms，凌晨为 2 ms；东京从 3 ms 升到 13 ms。抖动放大的倍数比延迟更值得关注，因为它直接决定语音与游戏是否可感知。
下载怎么选时段
大文件放在 00:00–08:00，延迟最低且丢包接近 0，重传少。
游戏怎么选
优先看抖动与丢包；延迟 60 ms 但抖动 3 ms，比 40 ms 但抖动 20 ms 更稳。
04TEST
五步测出你自己的数字
页面上的数字只能当参考。想知道自己网络下的真实水平，按下面五步做一次，结果比任何榜单都可靠。
- 固定环境
- 关闭下载、网盘同步与系统更新。
- 用有线或 5 GHz Wi-Fi，避免 2.4 GHz 干扰。
- 先测本地基线
- 不连客户端，测一次到国内公共 DNS 的延迟。
- 基线高于 30 ms 时，先查路由器与宽带。
- 连续测三次
- 同一节点测 3 次，间隔 30 秒，取中位数。
- 三次差异超过 20 ms，换时段再测。
- 高峰复测
- 下午与晚高峰各测一次，比较抖动。
- 晚高峰抖动超过 12 ms 的节点不适合会议。
- 用真实任务验证
- 打开目标站点，看首屏与操作响应。
- 测速快但操作卡，通常是目标站点自身拥塞。
合格线
延迟 ≤ 80 ms、抖动 ≤ 12 ms、丢包 ≤ 1%。三条同时满足才叫「可用」。
优秀线
延迟 ≤ 40 ms、抖动 ≤ 5 ms、丢包 0%。游戏与会议按这个标准看。
别只看一次
单次测速的偶然性很大，中位数才代表常态水平。
05SCENES
六个区域，各自适合什么
选区域本质是选「离目标站点近的那一侧」。下面按常见用途给建议，最终仍以你实测为准。
东亚
延迟最低。香港覆盖华南、华东；东京覆盖日韩与北方城市。
东南亚
新加坡是区域枢纽，跨境电商后台与东南亚流媒体表现稳定。
北美
洛杉矶与圣何塞覆盖多数北美 SaaS 与学术数据库，延迟 140 ms 起。
欧洲
法兰克福与伦敦覆盖欧洲客户官网、邮件与协作工具，延迟 170 ms 起。
中东
迪拜节点服务中东项目协作，节点少但线路以专线为主。
大洋洲
悉尼与墨尔本覆盖澳洲站点，适合留学与澳洲客户沟通。
06WEAK
网络本身不好时，节点能帮到哪
节点优化的是跨境那一段，修不了你本地的丢包。分清责任边界，才不会把本地问题当成节点问题。
Wi-Fi 干扰
2.4 GHz 拥挤时本地丢包可达 3%。换 5 GHz 或网线，比换节点有效。
家宽拥塞
多人同时看视频会推高上行排队延迟。给客户端留 20% 余量更稳。
国际出口拥塞
所有节点同时变慢，说明是出口问题，换区域比换节点有用。
目标站点限速
站点按 IP 限速时，频繁换节点可能触发风控。降低并发更稳。
判断顺序：本地基线 → 是否所有节点同时慢 → 单个节点负载 → 目标站点自身。按这个顺序排查，通常一轮就能定位。
07FAQ
五个关于节点的问题
回答基于 2026 年 10 月巡检与客户端 3.3.0，节点调整后数字会变化。
节点越多越好吗？
不是。节点解决的是「就近」与「有备份」，不是无条件加速。150 个节点里日常真正被分配的只有 38 个主力节点，其余承担维护接管与区域分流。
为什么我在 A 城市，系统却选了邻城节点？
同城节点在高负载或抖动超标时会被降级。按 2026 年 10 月的调度记录，约 11% 的连接会改走邻城，换取更稳的抖动表现。
节点列表里的百分比是什么？
实时负载。超过 80% 会标灰，仍可手动选择，但高峰期不建议；低于 40% 的节点通常能拿到更稳的上行。
测速结果每次都不同，正常吗？
正常。跨境链路本身在波动，建议同一时段连续测 3 次取中位数；三次差异超过 20 ms 说明链路不稳，换个时段再测。
维护期间会断线吗？
多数不会。维护采用先迁移后下线，客户端会自动切到备份节点；你可能感知到一次重连与十几毫秒的延迟变化。
08LINES
四种线路类型，怎么选
同一座城市可能有多种线路。类型决定的是「稳不稳」，不是「快不快」，两者经常被混为一谈。
| 类型 | 特征 | 抖动中位 | 适合 |
|---|---|---|---|
| BGP 多线 | 多运营商接入，按来源选路 | 6–9 ms | 网页、办公、日常 |
| 专线 | 固定路径，绕行少 | 3–5 ms | 会议、游戏、长连接 |
| 专线 + BGP | 主备结合 | 5–7 ms | 跨境办公与流媒体 |
| 备份入口 | 平时不分配 | 8–12 ms | 维护接管 |
据 2026 年 10 月的采样，专线节点的抖动中位为 4 ms，BGP 节点为 8 ms；同城两种线路的延迟差通常在 3 ms 以内，但高峰期的抖动差可以到 9 ms。这就是为什么「延迟差不多」的两条线路，用起来差别明显。
会议优先专线
长连接对抖动敏感，专线的固定路径更稳。
下载优先 BGP
多线接入在白天更容易跑满带宽。
备份不要手动选
备份入口平时不分配，手动连上去反而更慢。
看抖动不看延迟
延迟差 3 ms 感知不到，抖动差 9 ms 会直接卡顿。
据 2026 年 10 月的台账，150 个节点里专线节点 46 个、BGP 节点 89 个、混合 15 个；专线集中在东亚与北美，BGP 覆盖更广。这个结构决定了「会议优先东亚、下载可走北美」的默认建议。
同一批台账还记录了节点扩容节奏：东亚在 10 月新增 3 个入口，北美更换 1 条上游链路，欧洲与东南亚各扩容 1 次。扩容后东亚晚高峰的抖动中位下降约 2 ms，感知不明显，但对会议场景有意义。
| 区域 | 新增入口 | 更换链路 |
|---|---|---|
| 东亚 | 3 | 0 |
| 北美 | 1 | 1 |
| 欧洲 | 1 | 0 |
维护记录与延迟数据要一起看：扩容当周的延迟可能因为迁移而短暂上升，下一周才回落到新水平。只取单周数据，容易把维护影响误判为线路变差。
如果你在维护窗口内遇到一次重连，先看客户端日志里的迁移记录，再决定是否换节点；多数情况下迁移完成后会回到原节点。
节点编号也不是随机的：前两位是区域代码，第三位是城市序号，后缀区分线路类型。看懂编号，手动选节点时能少走弯路。
同城两个入口的延迟往往只差 3 至 6 ms，但抖动的差距可能翻倍。会议场景优先看抖动，下载场景优先看丢包。
最后一条经验：不要长期固定在一个节点上。节点负载每周都在变，定期复测比「认准一个」更稳。
节点页的表格按城市给中位，不按单节点给极值。这样做的代价是看不到最好与最差，但能避免「拿一次尖峰当常态」的误判。
如果你需要更细的数据，客户端里的节点列表会显示每个入口的实时延迟与负载，那是最接近你本地情况的一份。
本页表格每月复核一次，节点增减会同步到数量列；如果你发现数量与客户端不一致，以客户端为准。
表格里的延迟是往返值（RTT），不是单向延迟；单向值约为往返的一半，但无法直接测出。
用自己的网络测一次
按五步测速做一遍，再决定长期用哪个区域。