评分从哪来

评分不是黑箱。四项指标各有明确的测量方法与归一化方式，加权之后映射到 0 到 100 的区间。理解这套算法，你就能解释客户端列表里任何一个数字。

四项指标各自的测量方式

延迟取十次建连的中位值；丢包取采样窗口内未收到响应的报文占比；抖动取同一轮内多次延迟测量的离散程度；历史稳定性取该节点过去七天的达标轮次比例。

为什么要归一化

四项指标量纲不同，毫秒与百分比不能直接相加。归一化的做法是把每项映射到 0 到 1 的分数，再按权重加权求和，最后乘 100。这样不同方向的节点才能放在一张表里比较。

四项指标的测量口径与归一化方式

指标	测量方法	原始单位	归一化方式	权重
延迟	10 次 443 建连取中位	毫秒	线性映射，60 ms 对应满分	45%
丢包	采样窗口未响应报文占比	百分比	线性映射，0% 对应满分	30%
抖动	同轮多次延迟的离散程度	毫秒	线性映射，5 ms 对应满分	15%
历史稳定性	近七天达标轮次比例	百分比	线性映射，100% 对应满分	10%

满分意味着什么

满分不代表零延迟，而是指四项都落在各自的最优区间内。例如延迟 60 毫秒的节点与延迟 19 毫秒的节点，延迟项都拿满分，区别体现在总分相近但抖动与丢包可能不同。

四个维度的权重为什么这样分配

权重不是拍脑袋定的。每一项的权重对应它在实际体验中的破坏力：延迟决定交互感受，丢包决定语音与视频是否可用，抖动决定是否稳定，稳定性决定是否可靠。

延迟占 45% 的理由

延迟是唯一在所有用途里都被感知的指标。网页加载、视频起播、点击响应、游戏操作都直接受它影响，因此权重最高。

丢包占 30% 的理由

丢包的破坏是断崖式的。丢包从 0.2% 升到 1.5%，语音就开始断续、视频开始缓冲。它不像延迟那样渐进恶化，所以必须给足权重。

抖动占 15% 的理由

抖动主要影响实时类应用。对网页浏览影响很小，对游戏与会议影响很大。15% 是一个折中：足以让高抖动节点排后，又不至于让纯浏览用途的节点被过度惩罚。

稳定性占 10% 的理由

它的作用是防「一时快、长期差」。权重不高，但能有效压住那些偶发满分、多数时间不达标的节点。

自己复现：三条命令

不需要特殊工具，用系统自带命令就能复现延迟与抖动两项。下面按 Windows、macOS、Linux 分别给出写法，每项都做十次取中位。

1. Windows：用 Test-NetConnection 或 curl：对目标 443 端口连续发起十次连接，记录每次耗时
   • Test-NetConnection 输出较详细但慢
   • curl -w 可以只输出耗时，适合批量
2. macOS / Linux：用 curl 的格式化输出：循环十次，取 time_connect 字段
   • time_connect 是 TCP 建连耗时
   • time_appconnect 是 TLS 完成耗时
3. 算中位与离散程度：十个数排序取中间值，最大值减最小值作为波动参考
   • 样本少于五次不要下结论
   • 剔除超时样本，单独记录

三项指标的自测命令对照

指标	Windows 写法	macOS / Linux 写法	输出字段	判断
TCP 建连	curl -o NUL -s -w "%{time_connect}" 地址	curl -o /dev/null -s -w "%{time_connect}" 地址	秒，带小数	×1000 得毫秒
TLS 完成	curl -o NUL -s -w "%{time_appconnect}" 地址	curl -o /dev/null -s -w "%{time_appconnect}" 地址	秒，带小数	反映握手开销
首字节	curl -o NUL -s -w "%{time_starttransfer}" 地址	curl -o /dev/null -s -w "%{time_starttransfer}" 地址	秒，带小数	含服务端处理
总耗时	curl -o NUL -s -w "%{time_total}" 地址	curl -o /dev/null -s -w "%{time_total}" 地址	秒，带小数	含传输

为什么要测三次以上

单次测量受系统调度与网络瞬时状态影响，误差可达数十毫秒。三次以上取中位，才能得到有参考价值的数字。本站在做全站读数时用的是十次。

自测结果与客户端不一致怎么办

先确认测的是同一个目标。客户端测的是节点本身，自测若测的是业务站点，中间还多了一跳。其次是确认时段一致，不同时段的读数不可比。

抖动怎么算

抖动不是简单的「最大减最小」。那样做会被单个离群值带偏。客户端的做法是取同轮多次测量的标准差，再结合极差做一个修正值。

标准差与极差的分工

标准差反映整体离散程度，对多数样本敏感；极差反映最坏情况，对离群值敏感。两者结合，既能抓住整体波动，也能识别偶发尖峰。

抖动的两种算法与适用场景

算法	计算方式	优点	缺点	适用
标准差	各次测量与均值之差的平方均值开方	反映整体波动	对单次尖峰不敏感	判断常态稳定性
极差	最大值减最小值	能抓住最坏情况	易被离群值带偏	判断极端表现
修正值	标准差为主，极差超阈值时上调	兼顾两者	计算稍复杂	客户端实际采用

抖动多少算正常

本地区域 20 毫秒以内属于正常，40 毫秒以上开始影响语音与游戏。跨洲方向的标准可以放宽到 30 毫秒以内，因为跨洲本身的往返次数更多，波动空间更大。

历史稳定性怎么统计

稳定性统计的是「达标轮次占比」。一轮采样里四项都达到各自阈值，这一轮记为达标。七天内的达标轮次除以总轮次，就是稳定性比例。

为什么用七天而不是三十天

七天能覆盖一个完整的工作日与周末周期，又不至于把过时的历史带进来。三十天的窗口会让一个已经修好的节点长期背着旧账。

评分与实际体验的偏差

评分是四个数字的加权，实际体验是人的感受。两者大体一致，但有三种典型偏差需要知道，否则会误判。

偏差一：评分相近但体验不同

两个节点评分都是 86，但一个延迟低抖动高，另一个延迟高抖动低。对游戏用户，前者体验更差；对下载用户，两者差别不大。评分相同不等于适配相同。

偏差二：评分高但当下不可用

评分基于采样，采样有间隔。节点在两轮采样之间劣化时，评分还停留在上一轮的高位。这种情况通常持续不到一分钟。

偏差三：评分低但对你够用

纯网页浏览对抖动不敏感。一个抖动偏高导致评分 70 的节点，用于浏览可能完全没问题。评分低不等于不能用，只是不适合敏感用途。

三种偏差的识别与处理

偏差	表现	原因	处理
评分相近体验不同	同为 86 分，游戏体感差别大	四项结构不同	按用途看单项而非总分
评分高但不可用	显示高分却连不上	采样间隔内的劣化	重连或等下一轮采样
评分低但够用	70 分节点浏览正常	用途对抖动不敏感	按用途判断，不必追求高分

按用途看单项，而不是看总分

总分适合快速排序，不适合做最终决定。真正的决定应基于用途对应的单项阈值。下表给出五类用途各自该看哪一项。

五类用途的关键单项与阈值

用途	首要单项	阈值	次要单项	可放宽项
视频	抖动	≤ 40 ms	丢包 ≤ 0.5%	延迟
对战游戏	抖动	≤ 10 ms	延迟 ≤ 60 ms	丢包
语音会议	丢包	≤ 0.5%	抖动 ≤ 20 ms	延迟
大文件下载	丢包	≤ 0.5%	延迟 ≤ 200 ms	抖动
网页浏览	延迟	≤ 120 ms	丢包 ≤ 1%	抖动

为什么下载不看抖动

下载是长连接、大报文，抖动带来的时序变化会被缓冲吸收。真正影响下载的是丢包导致的丢块与重传，以及总带宽。抖动在下载场景里几乎没有存在感。

为什么会议最怕丢包

语音编码对丢包有补偿机制，但补偿能力有限。丢包超过 1% 时，补偿后的语音开始出现断续与机械音。延迟可以靠缓冲吸收，丢包不能。

采样流程的五个环节

从发起采样到评分落到列表，中间有五个环节。任一环节出问题，都会让评分失真。理解这五个环节，能解释大部分「评分看起来不对」的情况。

1. 发起采样：按连接状态决定间隔，连接中 30 秒、空闲 5 分钟
   • 客户端被系统休眠后会推迟采样
   • 手动刷新可立即触发一轮
2. 建立探测连接：对每个候选节点发起 10 次 443 建连
   • 探测包很小，不影响正在进行的传输
   • 弱网环境下建连会超时
3. 剔除异常样本：超时与明显离群的样本单独记录，不参与中位计算
   • 样本少于五次时标注样本不足
   • 样本不足的节点不参与方向性结论
4. 计算四项分数：分别归一化后按 45/30/15/10 加权
   • 归一化阈值按方向略有差异
   • 跨洲方向的抖动阈值放宽
5. 写入候选队列：按分数排序，进入分组内的候选序列
   • 连续三次不达标降到队尾
   • 恢复后自动回归

手动刷新会不会打乱采样

不会。手动刷新只是提前触发一轮，不会重置历史稳定性统计。频繁刷新唯一的影响是多消耗一点探测流量，对评分没有副作用。

休眠后评分为什么突变

系统休眠会挂起采样，恢复后第一轮采样往往包含大量超时样本，导致评分短暂偏低。等下一轮完成，评分会回到正常水平。

评分与切换的关系

评分决定排序，排序决定候选。但真正触发切换的是另一套判定：新线路分数必须比当前线路高 25% 以上，且连续三次成立。评分高不等于立刻切换。

为什么要有 25% 的阈值

两条线路分数接近时，若按「谁高用谁」切换，会出现来回跳。每次跳都重建连接，视频会卡、会议会掉帧。25% 的阈值让切换只在差异明显时发生。

五项常见读数异常与解释

采样过程中会出现一些看起来反常的读数。下面五条是编辑部在复现时最常遇到的，每条给出成因与是否需要处理。

异常一：延迟正常但评分很低

说明扣分来自其他三项。查抖动与丢包，通常其中一项明显超标。评分是加权和，单项拖低总分是正常表现，不代表延迟有问题。

异常二：同一节点两次采样差一倍

常见于跨洲节点。跨洲路径的跳数多，任一跳出现排队，延迟就会翻倍。两次采样间隔越长，遇到不同排队状态的概率越高。

异常三：抖动为 0

十次测量结果完全一致的概率极低。出现抖动为 0，通常是样本被缓存或目标返回了固定响应，不是真实测量。这类样本应剔除。

异常四：丢包恒为 0 但体验卡

说明瓶颈不在网络层。可能是本地 CPU 或磁盘瓶颈，也可能是目标服务端限速。网络指标正常而体验不佳时，先查本机资源占用。

异常五：所有节点同时变差

几乎可以确定是本地出口问题，而不是节点集体故障。查本地带宽占用、路由器负载、以及是否有其他工具在接管路由。

五项异常的成因与处理

异常	可能成因	是否需要处理	处理方式
延迟正常评分低	抖动或丢包超标	需要	查另外两项，换节点
两次采样差一倍	跨洲路径排队状态不同	不需要	看多次采样的整体分布
抖动为 0	样本被缓存或目标固定响应	需要	剔除样本，重新采样
丢包 0 但卡顿	本机资源或服务端限速	需要	查 CPU、磁盘与服务端
全部节点变差	本地出口问题	需要	查本地带宽与路由

六种测量方式的对照

同一个「延迟」，用不同方式测出来的数字可能差几十毫秒。下表把六种常见测法列清楚，避免把不同口径的数字混着比。

六种延迟测法的口径差异

测法	测的是什么	典型值（东亚）	包含握手	适用场景
ICMP ping	网络层往返	12 ms	否	粗略判断可达性
TCP 建连	传输层握手完成	19 ms	部分	客户端评分采用
TLS 完成	含加密握手	33 ms	是	判断握手开销
首字节	含服务端处理	53 ms	是	判断端到端体验
应用层请求	含业务逻辑	80 ms 以上	是	判断具体业务
HTTP/3 首字节	含 QUIC 握手	46 ms	是	新协议下的对比

为什么客户端用 TCP 建连

TCP 建连既反映网络往返，又不受服务端业务逻辑影响，是最接近「线路质量」的单一指标。ICMP 常被限速甚至屏蔽，不适合做评分依据。

不同测法的数字不可混比

看到「ping 12 毫秒」与「客户端显示 19 毫秒」不要以为有矛盾，两者测的不是同一件事。比较时必须用同一口径。

评分表里的常见读数组合

节点列表里看到的评分，往往对应一组固定的读数组合。下面把常见组合列出来，读者可以直接对号入座，判断这个节点大致处于什么状态。

评分与读数组合的常见对应

评分区间	延迟量级	抖动量级	丢包量级	状态判断	建议
90–100	≤ 40 ms	≤ 10 ms	≤ 0.3%	处于良好状态	可直接选用
80–89	40–70 ms	10–20 ms	≤ 0.5%	正常可用	日常用途足够
70–79	70–120 ms	20–40 ms	≤ 0.8%	轻度劣化	观察一轮再看
60–69	120–200 ms	30–60 ms	≤ 1.2%	明显劣化	建议换节点
60 以下	> 200 ms	> 60 ms	> 1.2%	进入降权候选	不要选用

为什么评分区间能反推读数

因为权重是固定的。四项加权的结果落在某个区间时，各项的取值范围也就大致确定。这个反推是近似的，用来快速判断够用即可，不适合当作精确读数。

一个容易被忽略的情况

跨洲节点的延迟天然在 150 毫秒以上，因此它的评分上限本来就不高。若把跨洲与本地区域的评分放在一起比，会误以为跨洲节点质量差。实际上它在自己所在的方向里可能是最好的。

评分与用途的取舍

评分高不代表什么都能干。下面这张表把「评分够用」与「单项够用」分开，避免用一个数字覆盖所有判断。

评分与单项的优先级对照

用途	评分下限	关键单项硬线	单项不达标时	评分再高也不救
网页浏览	60	延迟 ≤ 120 ms	换低延迟节点	否
视频播放	70	抖动 ≤ 40 ms	换低抖动节点	是
语音会议	75	丢包 ≤ 0.5%	换低丢包节点	是
对战游戏	80	抖动 ≤ 10 ms	换双上游节点	是
大文件下载	70	丢包 ≤ 0.5%	换稳定线路	是
固定出口业务	不限	出口地区一致	换同地区节点	是

为什么单项不达标时高分也没用

因为加权求和允许其它项补偿。延迟 200 毫秒但丢包极低的节点，总分可能仍有 75 分。然而语音通话丢一个包就断续一次，高分救不了这个体验。

怎么快速做这个判断

看列表时先扫抖动与丢包两项，它们在多数客户端里直接显示。抖动与丢包都在线内再看评分，通常就已经够用了。

四项指标的采集成本

评分每 30 秒跑一轮，那么这轮采集本身占多少资源，是值得算清的。下面是实测的探测开销数据。

单轮采样的开销实测（132 个候选节点）

项目	单轮消耗	折合每秒	折合每小时	对使用的影响
探测连接	约 1584 次	约 53 次	约 3.2 万次	不影响正在进行的传输
探测流量	约 2.4 MB	约 80 KB	约 290 MB	按流量计费时需留意
连接数	同一时刻不超过 8	—	—	不超过常规上网的并发数
CPU 占用	约 0.4%	—	—	可忽略
内存增量	约 3 MB	—	—	采样缓冲，轮次结束即释放

探测流量为什么看起来不小

1584 次建连乘以每次的握手开销，总量约 2.4 MB。这个数字按小时看会显得惊人，但一次连接只持续几十毫秒，且大部分时间处于等待状态，并不占用实际带宽。

对按流量计费网络的影响

在蜂窝网络下，采样流量会计入套餐。若长时间挂着不连接，每小时约 290 MB 的探测量值得留意。介意的话可以在设置里关闭空闲采样，连接期间的采样无法关闭。

关掉空闲采样的取舍

关闭后，空闲状态下不维护候选排序，第一次连接时需要做一轮完整采样，多花 6 到 10 秒。对只在需要时连一次的用户，这是划算的；对全天常连的用户，保持开启更好。

评分与拥塞的关系

拥塞是评分最主要的外部扰动。下面这组对照说明拥塞如何改变各项读数，以及评分在该场景下的表现。

同节点在正常与拥塞状态下的读数对照

状态	延迟	抖动	丢包	评分	判定依据
正常时段	19 ms	9 ms	0.2%	93	白天采样基线
轻度拥塞	24 ms	16 ms	0.4%	86	评分下降 7 分
中度拥塞	31 ms	25 ms	0.6%	79	评分下降 14 分
重度拥塞	58 ms	52 ms	1.4%	61	进入降权候选
节点劣化	19 ms	9 ms	0.2%	93	读数正常但历史分低

拥塞时评分下降的幅度

从 93 分降到 79 分只用了 14 分，但抖动从 9 毫秒涨到 25 毫秒，接近三倍。这说明权重设计并没有让抖动充分反映在总分上，用途相关的单项仍然必须单独看。

拥塞与劣化的区别

拥塞是暂时的，读数会在几小时内回落；劣化是持续的，历史稳定性分同步走低。区分两者的方法是对比历史分：拥塞时历史分不变，劣化时历史分已经很低。

评分的历史维度怎么用

历史稳定性占权重 10%，看起来不起眼，但它决定了引擎会不会把一个「偶然很好」的节点排在前面。这一节说明它的判定与用法。

达标轮次怎么算

一轮采样里四项都达到各自的硬线，这一轮记为达标。七天内的达标轮次除以总轮次，得到的就是该节点的历史稳定性比例。

为什么用七天窗口

七天覆盖一个完整的工作日与周末周期，能同时反映日常与高峰两种状态。三十天的窗口会把已经修复的问题长期算进历史里，让节点一直背着旧账。

历史稳定性分档与对应的判断

稳定性比例	分档	含义	引擎行为	使用者判断
≥ 95%	优秀	几乎每轮都达标	优先被选中	可以放心使用
90%–95%	良好	偶有单轮不达标	正常参与排序	日常无感
80%–90%	一般	有一定波动	参与但排名靠后	留意时段
70%–80%	偏差	波动较频繁	进入降权候选	建议换用
< 70%	不良	经常不达标	降到候选队尾	不要选用

稳定性低但当下读数好

这种情况确实存在，常见于刚维护完的节点或刚恢复的线路。此时读数漂亮，但历史分还没累积回来。引擎会保守地把它排在后面，等它稳定几轮后再提上来。

四个指标的自查对照

如果只记住一件事，就是：四个指标各看一个硬线。下面把这四条线与对应的问题现象放在一起，读者可以自检。

四项指标的硬线与对应问题

指标	硬线	超标后的典型现象	先做什么	再做什么
延迟	120 ms	页面加载慢、操作有迟滞感	换同区域节点	查本地带宽
抖动	40 ms	语音断续、视频缓冲	换双上游节点	错峰使用
丢包	0.5%	长连接重传、会议卡顿	换线路	查本地出口
稳定性	80%	时好时坏、频繁切换	解除锁定重选	换方向

为什么这四条线要分开记

四个指标对应四种不同的问题，处理顺序也不同。延迟高先换节点，丢包高先查本地出口，抖动高先错峰，稳定性差说明这个节点本身不可靠。混在一起记会导致处理方向错误。

评分口径的版本对照

评分体系随版本调整过。下面列出几个版本的差异，方便对照自己客户端里的设置与历史记录。

评分口径的版本对照

版本	指标构成	采样间隔	切换阈值	备注
v4.2.0	延迟 / 丢包 / 抖动 / 稳定性 四项	30 秒 / 5 分钟	25%	本页所述口径
v4.1.0	延迟 / 丢包 / 抖动 三项	60 秒 / 5 分钟	25%	稳定性项为后续版本加入
v4.0.0	延迟 / 丢包 两项	60 秒 / 10 分钟	30%	初版四项评分体系
v3.9.6	单延迟评分	120 秒	无	仅按延迟排序

为什么口径变化会影响历史读数

指标数量变了，评分自然不可比。升级前的评分与升级后的评分放在一起没有意义，这也是为什么本站所有评分读数都标注了对应的客户端版本。

跨版本比较的正确做法

只看同一版本内的相对排序，不看跨版本的绝对分数。若必须比较，用延迟与抖动这两项——它们在四个版本里的测量方式没有变。

常见问题

下一步

理解了评分，接着看切换判定：什么时候它会自己换线路，以及为什么不建议你手动干预。