判断网页能不能打开，先看经代理发出的真连接请求；判断大文件能下多快，再看持续吞吐量。ICMP ping 和 TCP 握手只覆盖链路中的一部分。本文适合正在比较 v2rayN 或 v2rayNG 测试结果的用户，重点说明测量边界、超时含义，以及怎样用同一目标、同一网络和重复样本完成有效对照。
四类测试的测量边界
延迟是完成某个动作所需的时间，速度是单位时间内传输的数据量。客户端列表中的毫秒数不是节点的固定属性：换一个测试目标、解析结果或连接复用状态，结果就可能变化。比较之前，应先确认测试按钮实际执行了什么，而不是只看列名里的“延迟”。
| 测试 | 主要测量对象 | 不能直接证明 |
|---|---|---|
| ICMP ping | 到目标主机的 ICMP 回显往返时间 | 代理端口可用、协议认证成功 |
| TCP 握手 | 到指定 IP 与端口建立 TCP 连接的耗时 | TLS、VMess 或 VLESS 配置正确 |
| 真连接延迟 | 经代理访问测试 URL 的请求耗时，边界取决于实现 | 所有网站可达、持续下载速度高 |
| 下载测速 | 经指定路径接收数据的有效吞吐量 | 首个请求响应快、交互稳定 |
例如，一个节点的 TCP 握手为 45 ms，真连接请求为 260 ms，并不矛盾。后者还可能涉及代理协议握手、服务器到目标站的连接、目标站 TLS 握手与响应等待。两项数据测量的终点不同，不能用相减结果直接计算“加密开销”。
ICMP ping 与 TCP 握手：只检查前半段链路
系统的 ping 通常发送 ICMP 回显请求，不会因为设置了 HTTP 或 SOCKS 代理就自动经该代理转发。对节点域名执行 ping，主要观察本地网络到该域名解析地址的可达性。若域名指向中转入口，结果体现的是入口，而不是最终出口到目标网站的完整路径。
- ping 超时但代理可用：主机或沿途设备可能不回应 ICMP；先测试实际服务端口，再发出经代理的请求。
- ping 很低但网页慢：入口距离近，不代表中转链路、出口带宽和目标站响应也快。
- TCP 握手成功但真连接失败：端口上有服务响应，仍可能存在 UUID、TLS 服务名、传输路径或协议参数错误。
TCP 测试必须针对节点配置中的实际端口。节点使用 443，就测该地址的 443；不能拿同主机的 80 端口代替。如果配置使用非 TCP 传输，TCP 探测的参考价值还会进一步下降。即便远端端口正确，握手完成也只说明 TCP 层连通，不等于应用层接受了这份代理配置。
真连接延迟：经代理请求一个具体 URL
真连接测试通常让内核通过待测节点访问 HTTP 或 HTTPS 测试地址。它比单纯测端口更接近网页访问，但“计时从哪里开始、到哪里结束”取决于客户端与内核实现。有的实现计到响应头，有的测试还受连接复用影响；不能把所有客户端的真连接结果当作完全同口径的数据。
对于 HTTPS 目标，流程中可能包含两段不同用途的 TLS：一段属于节点自身的传输安全，另一段属于客户端访问目标网站的 HTTPS。VMess 与 VLESS 是代理协议，是否采用 TLS、何种传输方式，需要结合节点配置判断，不能仅凭协议名称推算测试耗时。
测试 URL 应选择体积小、响应稳定、预期状态码明确的 HTTPS 端点。超时不一定代表节点完全不可用：目标站可能拒绝某个出口、解析失败，或者返回了测试实现不接受的状态。先换一个独立目标交叉验证，再检查日志中的连接、TLS 和响应错误。
真连接对照参数
- 目标协议
- HTTPS，记录完整 URL
- 目标端口
- 常见为 443，以 URL 为准
- 重复次数
- 同一节点连续测试 5 次
- 结果记录
- 中位数、失败次数、测试时段
这是一组对照实验建议，不是客户端内置默认值。
下载对照参数
- 目标资源
- 固定 URL 的大文件或持续数据响应
- 连接数量
- 先测单连接，再单独测并发
- 观察时长
- 每次约 20 秒，记录稳定区间
- 网络条件
- 同一接入网络，暂停其他下载
测速会消耗流量；移动网络下先确认套餐余量。
下载测速：吞吐量与毫秒数不是同一指标
下载速度受到本地接入带宽、节点限速、出口拥塞、目标服务器限速和 TCP 拥塞控制共同影响。低延迟有利于连接建立和交互，但不能保证带宽充足；高延迟线路也可能在连接稳定后获得较高吞吐量。测速开始的几秒还可能处于连接建立与拥塞窗口增长阶段，不宜只截取瞬时峰值。
Mbps 的小写 b 表示比特，MB/s 的大写 B 表示字节。100 Mbps 除以 8 得到 12.5 MB/s，这只是未扣除协议与链路开销的换算上限，不能要求应用始终达到该数值。若界面使用 MiB/s，单位又有区别，记录数据时要保留原单位。
- 单连接测试：更适合观察一次普通下载的表现，容易受单流限速和往返时延影响。
- 多连接测试：更容易填满带宽，但可能掩盖单连接较慢的问题，不能与单连接结果直接排名。
- 测试期间网页明显变慢：可能是带宽被占满、队列积压。先停止测速再测延迟，区分空闲延迟和负载延迟。
v2rayN 与 v2rayNG：固定条件再比较
客户端菜单会随版本和界面调整。桌面 v2rayN 可在服务器列表选中节点后，通过右键菜单查找「测试服务器真连接延迟」；批量测试前先只选一个节点，确认目标地址和日志表现。安卓 v2rayNG 可在主界面右上角菜单查找「测试全部配置真连接」。若当前版本名称不同，应按“真连接”功能识别，避免把 TCP 测试误当成完整请求。
- 记录环境：写下客户端版本、内核版本、接入网络和时间。两次测试若一个走 Wi-Fi、另一个走移动网络，就不是同条件对照。
- 固定测试目标：在当前版本提供的测试地址设置中核对 URL；找不到设置时，至少确认两次使用同一客户端和同一测试功能。
- 排除并发干扰：暂停同步、系统更新与其他下载。逐个测节点，避免批量连接争用本地带宽或服务器资源。
- 重复并保留失败：每个节点测试 5 次。超时不能作为 0 ms，也不应从记录里直接删除。
- 验证实际应用：选定节点后访问真实使用的网站，再单独下载测试文件。客户端内置测试可能使用独立的临时入站，不一定等同于系统代理或分应用代理路径。
手动验证时，若本地已配置一个支持 HTTP 的混合入站，端口为 10808，可以让命令行请求显式经过它。这里的端口只是示例，必须以客户端当前监听设置为准；仅有 SOCKS 入站时，不能直接套用 HTTP 代理参数。以下命令访问本站 HTTPS 页面，用于检查路径，不把该页面当作统一测速基准。
curl --proxy http://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --output /dev/null --silent --show-error --write-out "HTTP=%{http_code} TTFB=%{time_starttransfer}s TOTAL=%{time_total}s\n" https://v2ray-best.com/该写法适用于 Linux 或 macOS 终端。Windows 使用 curl.exe 并将 /dev/null 改为 NUL。TTFB 是从请求开始到收到首字节的累计时间，TOTAL 是到请求结束的时间；它们与客户端的真连接计时边界可能不同。更不能把连接本地代理端口的耗时当作连接远端节点的 TCP 延迟。
怎样读出一组延迟结果
优先看成功率，再看中位数，最后观察波动。下面是一组用于解释读数的示例，不代表任何节点实测：同一目标的五次结果为 180、190、185、920 ms 和一次超时。成功样本的中位数是 187.5 ms，但 4 次成功、1 次失败同样必须写进结论，只保留“约 188 ms”会掩盖可用性问题。
| 观察组合 | 优先考虑 | 下一步 |
|---|---|---|
| TCP 快，真连接超时 | 协议参数、目标站、DNS 或出口连接异常 | 更换测试目标，并核对内核日志 |
| 真连接稳定，下载慢 | 带宽、单流限速、目标资源限制 | 固定资源，对比单连接与多连接 |
| 空闲快，下载时延迟高 | 带宽占满、链路队列积压 | 暂停下载复测，再尝试限制下载速率 |
| 测试成功，某应用打不开 | 应用未进入代理、分流不同或站点特定限制 | 查该应用的代理入口和实际出站日志 |
跨时段也应保留同样条件。晚间拥塞与上午空闲的差异，可能大于两个节点之间的差异。若目的是视频或大文件下载，优先选择成功率稳定且持续吞吐量足够的线路；若目的是网页与远程交互，则更重视请求延迟及其波动。没有一个数字能替代全部使用场景。
常见问题：低延迟、超时与分流
ping 不通，还要继续测吗？
要。先按节点配置检查实际服务端口，再运行一次真连接测试。如果真连接成功，说明 ICMP 不响应并未阻止这条代理请求；后续观察实际网页和下载，不必为了让 ping 有结果而修改协议参数。
真连接只有 100 ms，为什么网页仍要等几秒？
测试只访问一个小目标，网页可能加载多个域名和大量资源。先停止下载，在浏览器开发者工具的「网络」面板查看慢请求，再核对该域名的路由出站与解析情况。测试 URL 的速度不能代表所有资源域名。
v2rayNG 测试成功，指定应用却没走代理？
检查系统是否已授予 VPN 连接权限，再进入 v2rayNG「设置」中的分应用代理选项，核对当前是代理选中应用还是绕过选中应用。保存后按界面要求重启服务，重新打开目标应用并观察连接日志；内置测试成功不能代替应用路径验证。
订阅更新后延迟变了，是更新重设了路由吗？
先核对节点地址、端口和传输参数是否随订阅改变，再检查当前选中节点。订阅主要更新服务器配置，通常不直接改写本地路由规则；即便节点名称没变，地址解析、出口负载和测试时间变化也会影响结果。
最终选型顺序可以固定为：先确认代理请求成功，再比较重复样本的延迟与失败次数，随后测试持续吞吐量，最后验证真实应用。ICMP 和 TCP 结果适合缩小排查范围，真连接适合检查请求链路，下载测试适合观察带宽；保持这些边界，才能解释数字为什么不同。