这些记录怎么用

观察记录的价值不在于「今天节点好不好」，而在于「某种现象出现时，大概是什么原因」。下面先说明读法，再逐条展开。

每条记录都包含三部分

第一部分是原始读数，含采样时间与环境；第二部分是观察到的现象；第三部分是从现象到结论的推导过程。第三部分最重要，它是可迁移的方法。

记录里的结论边界

每条记录都写明了适用范围与局限。读的时候注意这个部分：脱离环境的结论没有意义，这一点在第 1 条与第 6 条里尤其明显。

记录一：十一月上旬节点采样

结论：2026-11-11 上午采样显示，东亚组在 20:00–21:00 的抖动中位从上午的 9 毫秒升到 25 毫秒，接近三倍；延迟同步从 19 毫秒升到 31 毫秒。这是时段性拥塞，不是节点性能下降，次日同一时段回落至 20 毫秒与 11 毫秒。

采样条件

测试环境为有线千兆接入的 Windows 主机，未开启任何其他隧道；每个方向取一个代表节点，每节点 10 次 443 建连取中位；两个时间窗分别为 09:00–11:00 与 20:00–21:00。

东亚组两个时段的读数对照（2026-11-11）

时段	延迟中位	抖动中位	丢包	评分	样本数
09:00–11:00	19 ms	9 ms	0.2%	93	10
12:00–14:00	21 ms	12 ms	0.3%	90	10
20:00–21:00	31 ms	25 ms	0.6%	79	10
23:30–00:00	20 ms	11 ms	0.2%	92	10

为什么抖动比延迟涨得更快

拥塞的直接表现是排队，排队让延迟整体抬高，同时让各次测量的离散程度变大。抖动的增幅接近三倍，说明拥塞主要发生在队列层面，而非链路带宽层面。

这条记录的用处

当你在晚高峰遇到卡顿，可以用这组数据作为基准：抖动 25 毫秒属于该时段的常态水平，不构成节点故障。若抖动超过 40 毫秒或丢包超过 1%，才需要换线路。

• 上午基线：延迟 19 ms、抖动 9 ms、丢包 0.2%
• 高峰常态：延迟 31 ms、抖动 25 ms、丢包 0.6%
• 判定阈值：抖动 > 40 ms 或丢包 > 1% 才需干预
• 回落验证：23:30 后回到 20 ms 与 11 ms
• 结论性质：时段性拥塞，非节点劣化

记录二：为什么默认分组是亚洲优先

结论：客户端默认按「亚洲优先」分组而非全局排序，是因为跨区切换的代价远大于跨区收益；在实测中，由远端节点偶然测出的低延迟导致的一次跨区切换，平均使后续十分钟的体验变差，因为新路径的稳定性无法预判。

问题的来源

若引擎只按分数全局排序，就会出现这种情况：某个北美节点在一次采样中测出 130 毫秒，低于当前东亚节点的 160 毫秒，于是发生跨区切换。之后该节点回落至 220 毫秒，用户却已经承担了一次跨区重建的代价。

分组机制如何规避

分组先把候选限制在同区域内，再在组内排序。跨区的更优节点不参与比较，因此不会因为单次波动引发跨区切换。这是稳定性优先于峰值速度的设计取舍。

全局排序与分组排序的对照

项目	全局排序	分组排序
选点范围	全部 132 个节点	当前分组内的节点
跨区切换	可能发生	不会发生
单次波动影响	可能触发切换	只在组内重排
典型表现	偶尔跨洋后变慢	速度稳定在区域最优
适用场景	需要到达特定地区	日常默认使用

什么时候该用全球均衡

需要访问某个特定地区时，临时把分组改成「全球均衡」或「指定地区」。用完改回来。长期保持默认分组是更稳的做法。

• 默认分组：亚洲优先，日常使用最稳
• 跨区切换代价：重建加新路径波动，风险高
• 偶发低延迟不构成切换理由
• 需要特定地区时临时改分组
• 改完记得改回，避免长期锁定在跨区状态

记录三：一次持续卡顿的复盘

结论：一次两小时内切换七次却始终卡顿的故障，最终定位为分组设置与目标站点不匹配——目标站点属于欧洲方向，而分组设为亚洲优先，引擎只能在错误范围内挑选最优，切换再频繁也无济于事。

现象

21:00 至 23:00 期间切换记录七次，切换后延迟仍在 120 毫秒以上。主观感受是「一直在换，但一直没变好」。

排查过程

第一步看切换次数，七次属于偏密；第二步看每次切换后的读数，五次仍高于 120 毫秒，说明切换了但质量没改善；第三步看分组，发现目标站点不在当前分组覆盖范围内。

复盘过程的四个步骤与读数

步骤	看什么	读数	结论
一	切换次数	2 小时 7 次	偏密，继续查
二	切换后读数	5 次仍 > 120 ms	切换无效
三	分组设置	亚洲优先，与目标不符	候选范围错误
四	调整后复测	2 次，延迟 60 ms	分组是根因

结论的可迁移价值

「切换了但没变好」是一个通用信号，它指向候选范围或本地环境，而不是节点质量。这个判断方式适用于任何自动选路的工具。

• 切换后读数改善 → 之前选错了候选
• 切换后读数不变 → 候选里没有更好的
• 完全无切换记录 → 检查锁定与分组范围
• 切换集中在整点 → 上游周期性调整
• 深夜仍频繁切换 → 本地网络不稳定

记录四：五端同时在线的读数记录

结论：五台设备同时连接同一账号并同时采样，桌面三端的延迟中位各上升 1 毫秒，移动两端各上升 2 毫秒。这说明多端在线不共享线路通道，增加的是同一节点的采样频次；真正共享的是账号带宽配额，在大流量场景下才会显现。

测试方法

五台设备接入同一有线网络，同一账号登录，同一时间窗各做 10 次采样。先测单端在线的基线，再测五端同时在线的读数，两者相减。

单端与五端同时在线的读数差

端	单端延迟	五端延迟	差值	单端抖动	五端抖动
Windows	19 ms	20 ms	1 ms	9 ms	10 ms
macOS	20 ms	21 ms	1 ms	10 ms	10 ms
Linux	19 ms	20 ms	1 ms	9 ms	10 ms
Android	23 ms	25 ms	2 ms	12 ms	13 ms
iOS	24 ms	26 ms	2 ms	13 ms	14 ms

差值为什么这么小

五端各选各的节点，节点侧为每台设备分配的通道也是独立的。采样次数增加只会让评分更准，不会让单条通道变挤。

共享的是什么

账号级带宽配额。这项共享在浏览与会议场景几乎无感，在多端同时大文件下载时才会显现为吞吐下降。

• 多端浏览与会议：几乎无影响
• 多端大流量：各端吞吐下降，属配额限制
• 配额按账号计算，不按端
• 表现为速度变慢，不会断线
• 需要稳定下载时只留一台在线

记录五：两种测法读数不一致的六种情况

结论：客户端显示的延迟与自行测得的数字不一致，多数不是客户端测错，而是两边测的不是同一件事。六种常见情形分别是：目标不同、时段不同、接入方式不同、缓存干扰、样本不足、以及其它隧道并存。

六种情形

下面按出现频率排列。前两种占多数，后四种多见于自测时用了单次测量。

两种读数不一致的六种情形

情形	识别方法	影响幅度	处理	频率
目标不同	对比两端实际连的地址	数十毫秒	统一目标后重测	高
时段不同	对比采样时间戳	十几毫秒	同一时间窗对比	高
接入方式不同	看是否蜂窝网络	数毫秒	统一接入条件	中
缓存干扰	目标返回固定响应	读数异常一致	换一个目标重测	中
样本不足	只测了一次	误差可达数十毫秒	至少测三次	中
其它隧道并存	检查本机其它加速工具	差异大	退出其它工具再测	低

最快的核对方式

先看客户端当前连的是哪个节点，然后对它做同样的十次采样。如果两者接近，说明差异出在目标或时段；如果仍然差很多，再查接入方式与本机其它工具。

• 第一步：确认目标一致
• 第二步：确认时段一致
• 第三步：确认接入方式一致
• 第四步：确认样本数不少于三次
• 第五步：排除本机其它隧道
• 以上都排除后仍不一致，导出诊断日志反馈

记录六：长尾地区的单节点风险

结论：长尾地区共 28 个节点覆盖 15 个国家和地区，其中多数为单节点覆盖；单节点地区在维护期间没有替代路径，会出现该地区短暂不可用。本站在 2026-11-01 的观察中记录到三次此类中断，每次持续 12 到 20 分钟。

观察记录

11 月 1 日 03:12 与 04:05 分别记录到长尾地区的节点维护，客户端在维护节点进入维护状态后约 3 秒内切到了同方向其他节点，但这些地区本身无其他节点可用，因此该地区整体不可达。

单节点地区的三次中断记录

时间	影响地区数	中断时长	是否自动恢复	客户端行为
2026-11-01 03:12	2 个地区	14 分钟	是	移出候选队列
2026-11-01 04:05	1 个地区	18 分钟	是	移出候选队列
2026-11-01 04:41	1 个地区	12 分钟	是	移出候选队列

为什么这不是故障

维护是计划行为，有明确窗口，与上游调整或性能不达标导致的降级不同。判断依据是客户端诊断页里的事件类型标注。

依赖长尾地区怎么办

若业务确实依赖某个长尾地区，提前确认维护窗口比在不可用时才排查更有效。窗口通常在当地凌晨，公告发布在客户端的更新页。

• 单节点地区：维护期间无替代路径
• 恢复方式：维护结束后自动回到候选队列
• 提前确认：窗口通常在当地凌晨 01:00–06:00
• 依赖长尾地区的业务：建议准备备用方案
• 不是故障：与降级、下线在诊断页有明确标注差异

观察记录的方法说明

这六条记录的采集方式并不完全统一。前四条有明确的采样协议（固定环境、固定时段、每节点十次取中位），后两条更接近排障笔记，样本量有限。这个差异不影响它们各自的用途，但读者需要知道证据强度不同。

六条记录的证据强度与用途

记录	类型	样本量	证据强度	适合的用途
一	定时采样	4 时段 × 10 次	较强	判断基线与时段差异
二	设计分析	多日观察	中	理解机制，不用于数值
三	个案复盘	单次 2 小时	中	方法参考
四	对照采样	双端各 10 次	较强	判断多端影响
五	经验归纳	长期观察	中	排查顺序参考
六	事件记录	3 次事件	较弱	风险提示

为什么会写记录

网络问题的排查成本高，多数时间花在重复验证上。把每次观察的结论固化下来，下次遇到相似现象可以直接对照，这是这份档案存在的唯一理由。

订阅与更新

本页的记录更新后可通过 RSS 订阅，地址为 /feed.xml。订阅后新记录发布时会收到通知，无需手动回来查看。

往期记录索引

下面是六条记录的索引，每条标注日期与类型，方便按需要查找。

往期记录索引

编号	日期	标题	类型	可回答的问题
一	2026-11-11	十一月上旬节点采样	定时采样	晚高峰的正常读数是多少
二	2026-11-09	为什么默认是亚洲优先	设计分析	跨区切换为什么不做
三	2026-11-07	持续卡顿的复盘	个案复盘	切换了没变好怎么查
四	2026-11-05	五端同时在线读数记录	对照采样	多端会不会互相拖累
五	2026-11-03	两种测法不一致的六种情况	经验归纳	自测数字对不上怎么办
六	2026-11-01	长尾地区的单节点风险	事件记录	维护期间不可用正常吗

按问题找记录

若你的问题是「某个具体现象」，按上表最后一列反查。若问题是「方法怎么用」，优先看记录三与记录五，它们给出的是可迁移的排查顺序。

记录的写作约定

为了保证这批记录可信，编辑部定了几条写作约定。所有记录都遵守这些约定，包括本页之前发布的六条。

为什么不回填旧日期

记录一旦发布就固定。若后续采样结论发生变化，正确的做法是发一条新的记录说明变化，而不是改写旧记录或给旧记录填上更早的日期。旧记录的日期必须真实。

怎么判断一条记录是否还可用

看它的类型。定时采样与对照采样的结论有时效，一般三到六个月后需要复核；设计分析与经验归纳的时效更长；事件记录的时效最短，节点集合变化后需要重新观察。

四类记录的时效参考

类型	结论时效	复核间隔	变化时的处理
定时采样	3–6 个月	每季度一次	发新记录说明差异
设计分析	12 个月以上	版本变更时	补充说明即可
经验归纳	6–12 个月	半年一次	补充新情形
事件记录	1–3 个月	每月一次	发新记录替换结论

采样方法的完整说明

本批记录全部基于同一套采样方法。把方法写清楚，读数才有意义；也正因为口径固定，不同日期的记录才可以互相比较。

三个固定条件

测试主机为同一台有线千兆接入的 Windows 机器；测试时段固定为上午 09:00–11:00 与晚间 20:00–21:00 两个窗口；每轮测试前确认本机未开启任何其它隧道工具。

十个样本与中位

每个节点每轮做 10 次 443 端口的 TCP 建连，取中位值而不是平均值。原因是建连耗时的分布右偏，偶发尖峰会把平均值拉高，中位值不受影响。

异常样本的处理

超时的样本单独记录并从计算中剔除。若剔除后剩余样本少于 5 次，该轮结果标注「样本不足」，不参与方向性结论，只作为参考。

采样方法的关键参数

参数	取值	理由	可调整吗
建连次数	10 次	抵消偶发尖峰	可以，少于 5 次不足
取值方式	中位	不受离群值影响	不建议改用平均
超时样本	剔除并单独记录	超时不代表线路质量	可以，但须说明
最小样本	5 次	低于此值结论不稳	不建议降低
时段窗口	上午与晚间各一轮	覆盖低峰与高峰	可以按需增加
环境要求	有线、无其它隧道	排除本地变量	不可省略

这套方法的局限

方法本身有三条明确的边界：只代表一个城市的一条接入线路；只测 TCP 层，不反映服务端处理能力；采样时刻固定，无法覆盖突发情况。读数应当按这个尺度理解。

下一批采样计划

编辑部已排定下一轮采样的范围，先公开出来，便于读者对照。

下一轮采样的覆盖范围

项目	范围	样本数	执行顺序	说明
方向覆盖	全部六个方向	每方向 2 个节点	第一批	长尾组因样本少重点观察
时段	三时段（上午/晚高峰/深夜）	每时段一轮	第一批	新增深夜轮次
平台	Windows 与 Linux	各 10 次	第一批	对照桌面端一致性
多端	五端同时在线	各 10 次	第二批	补充长时运行数据
异常	单节点地区的维护观察	事件驱动	持续	遇维护即记录

为什么提前公布

公开采样计划有两个作用：一是让读者能提前判断哪些结论可能在下一轮被修正；二是把「什么时候复核」变成明确承诺，而不是模糊地说「以后会更新」。

三条被修正过的结论

编辑部保留被修正的记录原文，而不是删掉重写。下面三条是采样方法演进过程中被推翻过的判断，留在这里作为提醒：数字会变，方法也要跟着变。

三条被修正的结论

原结论	修正后	修正原因	数据日期
跨洲方向抖动普遍在 25 ms 以内	跨洲方向晚高峰抖动可达 33 ms	首轮采样漏掉了晚高峰时段	2026-10-22 → 2026-11-11
单节点地区维护期间会自动切换	单节点地区维护期间该地区整体不可达	原结论误以为存在同方向替代节点	2026-10-28 → 2026-11-01
评分与自测读数差异多由时段造成	多数差异来自测量目标不同	早期对照未控制目标变量	2026-10-30 → 2026-11-03

第一条是怎么被修正的

10 月 22 日的首轮采样安排在上午，得出「跨洲抖动 25 毫秒以内」的结论。11 月 11 日补了晚高峰窗口后，跨洲方向在 20:00–21:00 的抖动中位达到 33 毫秒。结论本身没错，缺的是时段覆盖。

第二条是怎么被修正的

10 月 28 日的观察里，某长尾地区节点维护后客户端立即显示了另一个节点，编辑部据此认为「单节点地区也能自动切换」。11 月 1 日的记录显示，那个替代节点属于不同分组，不在可用范围内。

第三条是怎么被修正的

10 月 30 日的对照里，编辑部把「客户端显示」与「自测结果」的差异归因于时段。但随后的对照发现，两次测量的目标地址本身就不同：客户端测的是节点，自测测的是业务站点，路径上多了一跳。补上「统一目标」这一条件后，差异大幅收敛。

为什么保留被修正的结论

删除它们会让读者以为结论从不出错。更重要的是，被修正的过程本身有信息量：它说明哪些变量容易被忽略，这正是后来把「时段」「目标」「分组覆盖」写进采样固定条件的原因。

采样数据的三种读法

同一批读数，从不同角度看会得到不同结论。下面三种读法各有适用场景，混用会导致误判。

读法一：和基线比

把当前读数与同方向同时间窗的历史中位比。这适合判断「今天是不是特别差」，不适合跨方向比较。

读法二：和同方向其它节点比

在同一轮采样内比较同一方向的多个节点。这适合判断「该换节点吗」，是客户端打分实际采用的方式。

读法三：和自己比

与同一节点上一轮读数比。这适合观察趋势与发现异常，但不能判断绝对水平。

三种读法的适用与禁忌

读法	比较对象	能回答什么	不能回答什么	常见误用
和基线比	同方向同时间窗历史值	今天是否异常	该不该换节点	拿它判断某节点好坏
和同方向比	同轮同方向其它节点	该不该换节点	整体网络是否正常	拿它判断全部节点质量
和自己比	同节点上一轮	趋势与异常	绝对水平	拿它判断线路是否达标

为什么不能混用

三种读法回答的是三个不同的问题。用和基线比的方式去决定要不要换节点，会因为整体网络的时段性波动而频繁换线；用和同方向比的方式去判断网络整体是否正常，会因为某个节点偶然劣化而误判全局。

关于这些数字的免责说明

本页全部读数取自编辑部自有测试环境。这些数字有三个不能忽略的用途限制，写在这里是为了避免被引用时超出原意。

不是性能承诺

任何一条读数都不构成对特定用户、地区或时段的性能承诺。网络质量由接入线路、时段、目标站点与本地负载共同决定，四项之中任何一项变化都会让读数失效。

不是横向排名依据

本页的六组方向之间存在物理距离差异，这种差异不可消除。读数用于理解量级关系，不用于比较不同服务的优劣。

不是当前状态的快照

读数反映采样时刻。节点集合与线路质量会随时间变化，超过复核间隔后本页的结论应当重新验证。

一页速查

最后用一张表把这页的要点压成一页，方便在排障时快速回看。

观察记录页速查表

问题	先看	再判断	结论口径
晚高峰很卡	抖动是否 > 40 ms	看记录一的时段基线	25 ms 以内属常态
切换了没变好	切换后读数	看记录三的排查顺序	候选范围或本地问题
自测数字对不上	测量目标是否一致	看记录五的六种情形	多数不是客户端测错
维护时不可用	诊断页事件类型	看记录六	单节点地区无替代
多端互相拖累	是否同时跑大流量	看记录四	线路不共享，配额共享
想最快的一条	看抖动而非峰值延迟	看记录二的分组说明	全局最优常带来跨区代价

六条记录的原始读数一览

为方便引用，把六条记录里最关键的读数集中列一次。数值与各条正文一致，不另作加工。

六条记录的关键读数汇总

记录	日期	关键读数	判定阈值	结论
一	2026-11-11	抖动 9 → 25 ms	40 ms	时段性拥塞
二	2026-11-09	分组内评分差 ≤ 25%	25%	跨区切换不划算
三	2026-11-07	切换后仍 > 120 ms	120 ms	分组范围错误
四	2026-11-05	五端差值 1–2 ms	5 ms	线路不共享
五	2026-11-03	目标不同造成数十毫秒差	样本 10 次	测量口径问题
六	2026-11-01	中断 12–20 分钟	窗口 01:00–06:00	单节点无替代

六条记录的一条共同结论

把六条并排看会发现一个共同点：所有问题最终都指向「环境变量没被控制」。时段、目标、接入方式、分组范围、设备数量——这五个变量只要有一个没固定，观察结果就会互相干扰。编辑部把这五个变量写进了采样固定条件，后续记录的可比性由此建立。

复现指南

如果你想在自己的环境里复现这些读数，下面是编辑部用的完整流程。照着走一遍，数据就具备与本页比较的条件。

1. 固定测试主机与网络：有线接入，关闭本机所有其它隧道与代理
   • Wi-Fi 与蜂窝的结果不可比
   • 不要在测试期间跑大流量
2. 选定对照目标：固定三个目标作为参照，每轮都测同样的三个
   • 目标要稳定，不能频繁更换
   • 对照目标用于识别本地网络的变化
3. 按十个样本采集：每个目标连续建连十次，记录每次耗时
   • 十次是最低限度的抗尖峰样本
   • 超时单独记录，不计入中位
4. 固定两个时段：上午与晚高峰各一轮，其余时段不采
   • 时段是最容易被忽略的变量
   • 同一时段内不同日期才可比
5. 计算并记录口径：算出中位、抖动、丢包三项，连同条件一起记录
   • 不写条件的读数没有价值
   • 写清样本数与是否剔除异常
6. 与历史基线对照：和同方向同时间窗的历史中位比较
   • 不同方向之间不要横向比较
   • 发现异常先复查前四个变量

复现时最常见的三个错误

第一，测一次就下结论，单次测量误差可达数十毫秒。第二，测着测着换了目标，前后数据混在一起。第三，把不同方向的读数放在一起比较，得出「跨洲比本地快」这类不成立的结论。