面向同时管理多个节点的用户,拆解 ping 与 Tcping、真连接延迟、下载测速三种数值各自的测量对象、误差来源与量级差异,给出「日常选节点」与「线路排障」两类场景的判断顺序,并列出四类最常见的误读。读完可以照着固定顺序筛节点,不再凭感觉随手切换。
三种数值分别在测什么
ping 测的是本机到目标服务器的一次 ICMP 往返时间,Tcping 测的是同一条路径上的一次 TCP 往返时间。两者只覆盖「本机到服务器」这一段链路,不进入代理协议,也不判断服务端有没有在正常转发流量。
真连接延迟测的是完整链路:建立 TCP 连接、完成 TLS 握手、跑完 VMess 或 VLESS 的协议握手,直到收到第一个有效响应字节。这个数值包含服务端处理时间,所以它比 ping 大属于正常现象,而不是节点出了问题。
下载测速测的是吞吐量,单位是 MB/s 或 Mbps,衡量单位时间内能搬运多少数据。它和延迟不是同一个维度:一个 40 ms 的节点可能只有 3 MB/s,一个 180 ms 的节点可能跑到 20 MB/s,两种情况都很常见。
| 数值 | 测量对象 | 覆盖范围 | 常见量级 | 主要误差来源 |
|---|---|---|---|---|
| ping / Tcping | 一次网络往返 | 本机到服务器 IP | 10~300 ms | ICMP 限速、握手队列排队 |
| 真连接延迟 | 握手到首字节 | 本机到出站完成 | 比 ping 高 30~150 ms | 服务端负载、TLS 协商、协议握手 |
| 下载测速 | 单位时间吞吐量 | 整条链路可用带宽 | 1~50 MB/s | 测速文件位置、单线程限制、本地带宽上限 |
ping 与 Tcping 的测量边界
Tcping 比 ICMP ping 更贴近实际使用场景,因为代理连接本身就建立在 TCP 上。ICMP 在很多线路上被限速或降优先级,甚至被直接丢弃,所以出现「ping 不通但节点可用」并不矛盾。
反过来也成立:ping 数值低不代表节点可用。服务器可能只开放了 443 端口,ICMP 与其它端口全部无响应,此时 Tcping 443 有结果、ping 无结果,属于正常配置而非故障。
- 能回答:本机到这台服务器的链路往返时间、是否丢包、是否持续抖动。
- 能回答:服务器对应端口是否在监听、TCP 握手是否被中途拦截。
- 不能回答:服务端进程是否正常转发、协议握手能否成功。
- 不能回答:节点的实际吞吐能力、是否被服务端限速。
真连接延迟
推荐覆盖握手到首字节的完整流程,最接近日常打开网页、加载接口时的真实体感。
适合:日常选节点、判断节点能否正常使用
ping / Tcping
只看链路层往返,数值干净、测量快,用来定位线路问题最方便。
适合:排查本地网络与服务器之间的链路质量
下载测速
衡量单位时间吞吐量,反映带宽而不是响应速度,测一次会消耗真实流量。
适合:大文件下载、视频场景的带宽筛选
真连接延迟为什么比 ping 高一截
真连接延迟至少包含三次往返:TCP 三次握手一次,TLS 握手一到两次(启用 TLS 1.3 后通常一次),协议握手与首字节一次。每一次往返都要叠加链路 RTT,因此链路本身 100 ms 时,真连接延迟落在 250~400 ms 属于常见范围。
判断标准不是绝对值,而是同一批节点里的相对排序,以及同一节点多次测量之间的波动幅度。跨地区节点之间比较绝对值意义有限,同一城市的两台服务器才适合直接对照。
推荐方案:两端各用哪套测速入口
桌面端(v2rayN)
- 节点列表右键 → 「测试服务器Tcping延迟」
- 右键 → 「测试服务器真连接延迟」
- 速度测试项或工具栏「测试速度」执行下载测速
安卓端(v2rayNG)
- 节点右侧菜单 → 「测试真连接延迟」
- 菜单内可一次测试全部节点
- 带宽筛选回到桌面端做,减少流量消耗
两端测出的真连接延迟量级接近,相差 10~30 ms 属于正常范围,不必追求两端数字完全一致。
下载测速的三个前提
下载测速最容易出偏差。默认测速文件大多在境外,如果本机宽带只有 100 Mbps,测出来的上限就是 12.5 MB/s,再快的节点也顶不上去。测速前先用本地直连跑一次基线,才知道瓶颈在节点还是在本地。
v2rayN 的测速文件地址可以在「设置」→「参数设置」里替换为离自己更近的地址,测速结果会更接近真实可用带宽。测速时用的节点会真实转发数据,这一点和延迟测试完全不同。
注意
下载测速每执行一次都会真实传输测速文件大小的流量。10 MB 的测速文件乘以节点数量,按流量计费的套餐几分钟内就会跑掉几百 MB。筛选节点优先用真连接延迟,只对最终保留的两三个节点做下载测速。
- 先用本地直连测一次基线带宽,把数值记下来作为对照。
- 对候选节点逐个执行下载测速,单线程结果不达标再试多线程。
- 把测速文件换成就近可访问的地址,减少跨境链路带来的干扰。
- 结果达到直连基线的 70% 以上,即可视为这条线路的合格吞吐。
判断顺序:从丢包到带宽
三类数值的使用有固定顺序,顺序颠倒会得出完全相反的结论。例如先看下载测速,会把带宽大但延迟高的节点排在前面,日常浏览反而更慢,于是又来回切换节点。
- 先看 Tcping 丢包率。丢包超过 5% 的节点直接排除,延迟数字不再参考。
- 再看真连接延迟的波动。同一节点刷新三次取中位数,波动超过 50% 的降为备选。
- 按真连接延迟中位数排序,取前三个进入下一轮。
- 对前三个做下载测速,按用途取舍:网页与接口选延迟低的,大文件与视频选吞吐高的。
- 连接后如果网页仍慢,先检查 DNS 与路由规则,而不是继续更换节点。
结论:先看丢包,再比延迟,最后才测带宽
丢包率超过 5% 的节点,延迟数字再低也不可用;真连接延迟波动小于 20% 的节点才值得进入下载测速环节。三步顺序颠倒,筛选结果几乎一定会反过来。
四类常见误读
| 常见误读 | 实际情况 |
|---|---|
| ping 低就等于快 | ping 只覆盖本机到服务器一段,不包含协议握手与转发耗时 |
| 下载测速快就适合浏览网页 | 吞吐与延迟是两个维度,网页加载更依赖延迟与 DNS 解析 |
| 只看最小值,不看波动 | 最小值常出现在网络空闲的一瞬间,中位数才代表常态 |
| 开着系统代理测速更真实 | 客户端自带的测速不经过系统代理,开着代理只影响浏览器内的测速 |
这四类误读的共同点,是把不同维度的数值混在一起排序。只要记住「链路、握手、吞吐」三个层次各自对应一种数值,选节点时就不会再被单个数字带偏。
结论:同一节点测三次,看中位数而不是最小值
最小值往往出现在网络空闲的一瞬间,不代表常态。三次测量取中位数,再与同批节点横向比较,筛选结果才稳定,也更容易在下次复现。
测速常见问题
为什么真连接延迟比 ping 高出一大截?
真连接延迟包含 TCP 握手、TLS 握手与协议握手,额外 1.5~3 次往返都会叠加链路 RTT,高出 30~150 ms 属于正常范围。差值长期稳定,说明服务端处理正常。
同一节点刷新两次延迟差很多,正常吗?
波动在 ±20% 以内属于正常;超过 50% 或频繁超时,先查本地网络,再考虑线路拥塞。这种情况把该节点降为备选,不要作为主力节点。
下载测速很快,网页打开还是慢?
吞吐与延迟是两个维度。打开网页更依赖握手延迟与 DNS 解析,换成真连接延迟更低的节点,并确认域名解析没有绕远路。
测速时要不要先关掉系统代理?
不需要。v2rayN 与 v2rayNG 自带的测速由客户端自己发起,不经过系统代理;只有用浏览器打开测速网站时,结果才会受代理影响。
测速会消耗节点流量吗?
会。Tcping 与真连接延迟只做握手,流量消耗可以忽略;下载测速会真实传输测速文件,10 MB 一次,按流量计费的节点建议只测最终保留的两三个。