适合正在用 v2rayN、v2rayNG 或 v2flyNG 比较订阅节点的人阅读。重点是分清 ping、真连接延迟和下载测速分别回答什么问题，并用固定顺序排除域名解析、代理握手、路由分流、节点负载与本地网络造成的干扰。
三种测试测到的不是同一段链路
节点列表里同时出现 40 ms、120 ms 和 80 Mbit/s 并不矛盾，因为三个数字对应不同任务。ping 通常向服务器地址发送 ICMP 数据包，记录往返时间；真连接延迟会让客户端通过 VMess、VLESS 等节点完成代理连接，再访问测试目标；下载测速则持续传输一段数据，观察可用吞吐量。
ICMP ping 的边界最窄。它可以说明本地网络到目标地址的基础往返时间和丢包情况，却不会验证节点端口是否开放，也不会执行 TLS、WebSocket、gRPC、Reality 或代理协议握手。即使地址的 ping 是 38 ms，连接 TCP 443、完成 TLS 协商并建立 VLESS 通道后，首个网页请求仍可能超过 150 ms。
真连接延迟更接近日常打开网页的等待时间。v2rayN 这类客户端通常会启动本地代理，通过指定节点请求测试地址，并统计建立连接及取得响应所需的时间。结果可能包含本地 SOCKS 入站、核心处理、代理协议握手、服务端出站、目标站响应和部分域名解析时间，因此它比 ping 更能反映节点是否真正可用。
ICMP ping
快速检查基础网络距离、明显丢包与地址是否响应，不验证代理协议和节点端口。
适合:第一轮粗筛、判断线路波动
真连接延迟
推荐通过实际代理链路发起请求，覆盖端口连接、协议握手与目标站响应。
适合:日常选节点、确认节点可用性
下载测速
持续传输数据并观察吞吐量，结果会受到测速源、并发连接和节点负载影响。
适合:大文件、视频与高带宽任务
为什么 ping 很低，网页仍然打开得慢
最常见的原因是 ping 绕过了代理建立过程。假设服务器地址的 ICMP 往返为 45 ms，TCP 建连至少还需要一个往返；如果使用 TLS，还要增加协商过程；WebSocket 需要完成 HTTP 升级；代理核心随后才会向目标网站建立出站连接。每一步都可能增加等待时间。
第二个原因是 ping 的目标与网页目标不同。ping 测的是客户端到节点入口，打开网页还包含节点到目标站的线路。某个节点距离本地很近，但其服务端到目标站绕路，真连接延迟仍会偏高。相反，入口 ping 稍高的节点如果服务端出口稳定，网页加载和下载可能更顺畅。
第三个原因是 ICMP 处理策略与 TCP、UDP 流量策略并不一致。服务器可能限制 ICMP 响应频率，也可能完全不回应，但 443 或其他节点端口仍能正常工作。因此 ping 超时只能表示这次 ICMP 测试没有得到响应，不能单独判定 VMess 或 VLESS 配置失效。
| 现象 | 可能环节 | 下一步检查 |
|---|---|---|
| ping 低，真连接延迟高 | 端口、TLS、代理握手或服务端出口 | 连续测试 3 次并查看核心日志 |
| ping 超时，真连接正常 | 服务器未响应 ICMP | 以真连接结果为准，不因单项超时删除节点 |
| 真连接低，下载速度低 | 可用带宽、节点负载或测速源限速 | 更换同一测速文件并做时段对照 |
| 三项结果都波动 | 本地无线网络、运营商线路或节点负载 | 改用有线网络并在不同时段复测 |
- VMess 与 VLESS 的协议名称不能直接决定延迟，服务器位置、传输层、拥塞和出口路由通常更关键。
- WebSocket、gRPC 与普通 TCP 的握手流程不同，不应只用一次测试结果给传输方式排序。
- 启用路由分流后，要确认测试地址确实经过当前节点，否则测到的可能是直连结果。
真连接延迟与下载速度应该怎样一起看
真连接延迟回答的是“多久开始收到响应”，下载测速回答的是“连接建立后每秒能传多少数据”。浏览短网页、接口请求和即时交互更在意前者；下载大文件、加载高码率内容则更依赖后者。一个节点可以在 110 ms 内完成请求，但持续下载只有 3 MiB/s；另一个节点首包需要 180 ms，却能稳定达到 12 MiB/s。
下面是一组同一台电脑、同一有线网络、同一测试文件下的示例记录。测试前关闭其他下载任务，v2rayN 本地 SOCKS 端口为 10808，HTTP 端口为 10809；真连接延迟连续执行 3 次取中位数，下载部分在连接稳定后记录 30 秒平均值。
这组数据中，代理下载达到直连基线的大约九成，说明带宽利用情况较好；真连接延迟比 ping 多出 67 ms，属于代理握手和节点到测试目标链路共同产生的差值。这里不能把 67 ms 全部归因于某一种协议，因为目标站响应、域名解析缓存和连接复用状态都会影响结果。
结论:交互任务看真连接，大流量任务再看持续速度
先用真连接延迟排除握手失败和明显卡顿，再用同一文件测试持续吞吐量。不要为了低 10 ms 的 ping，放弃下载速度更稳定且真连接差距很小的节点。
换算单位时也要保持一致。客户端或浏览器常用 MiB/s 显示下载速度，网络带宽常用 Mbit/s；粗略换算需要乘以 8，但 MiB 与 MB 的定义仍有差别。11.5 MiB/s 约等于 96.5 Mbit/s，不能把 11.5 直接与“100 Mbit/s”比较。
推荐测试顺序:先排环境，再筛节点
正确顺序比反复点击测速更重要。测试期间如果订阅正在更新、浏览器正在下载、系统代理模式不断切换，得到的数字没有可比性。桌面端可以先打开 v2rayN，在「设置」→「参数设置」中确认本地监听端口，再检查当前系统代理模式和路由模式。
- 建立直连基线。暂时停止代理任务，用同一网络记录目标文件的直连速度和普通网页响应。如果直连本身持续波动，应先处理本地网络。
- 核对订阅配置。更新订阅后确认节点地址、端口、VMess 或 VLESS 协议、传输方式与 TLS 参数已经完整载入。
- 执行 ping 粗筛。查看是否存在明显高延迟或连续丢包。单个节点不响应 ICMP 时先保留，继续做真连接测试。
- 执行真连接测试。在 v2rayN 中选中候选服务器，通过右键菜单执行「测试服务器真连接延迟」。每个节点测试 3 次，舍弃第一次缓存状态不一致的结果，再比较后两次或取三次中位数。
- 手动打开目标网页。切换到候选节点后重新建立连接，访问实际要使用的网站，确认路由规则没有让测试流量直连。
- 最后测试下载。使用同一个 HTTPS 文件、相同持续时间和单连接条件，对 2 至 3 个候选节点做吞吐量对照。
- 增加时段复测。在白天与晚间各记录一轮。若晚间速度从 10 MiB/s 降到 2 MiB/s，而本地直连稳定，节点负载或跨网线路更值得关注。
测试路由分流时还要注意旧连接。修改规则后，浏览器可能继续复用已经建立的连接，导致新规则没有立即体现在结果中。关闭对应页面、等待连接释放后再测；必要时重启客户端核心，并从日志确认目标域名命中了代理出站还是直连出站。
常见误判与排查答案
延迟列表适合缩小范围，不适合直接代替实际使用。一次测试可能碰到域名解析缓存、服务端短时繁忙或测速目标限流。可靠判断至少需要相同环境、重复测试和实际目标验证三项条件。
ping 显示超时，这个节点还能用吗？
可以继续测试。先执行真连接延迟，再实际打开网页；如果代理握手成功且流量正常，说明节点入口可能只是未响应 ICMP。
真连接延迟每次差几十毫秒正常吗？
先连续测试 3 至 5 次。若结果在 120 至 160 ms 之间变化，可取中位数；若从 120 ms 跳到 800 ms，应检查无线网络、丢包、节点负载和目标站响应。
延迟只有 70 ms，为什么下载只有 1 MiB/s？
低延迟只说明响应开始得快。请用同一文件对比直连速度，再换一个节点复测；如果只有当前节点持续偏低，重点检查节点带宽与服务端出口。
测速很好，但浏览器偶尔打不开网页怎么办？
打开核心日志，检查域名解析、TLS 握手和路由命中记录；同时确认 v2rayN 的系统代理已启用，本地 10808 或实际设置的监听端口没有被其他程序占用。
换成 VLESS 就一定比 VMess 快吗？
不能只按协议名称判断。保持服务器、入口线路和目标站一致再比较；传输方式、TLS 配置、服务端负载和跨网路由都可能让结果反转。
最终选择可以按任务拆分：网页与远程交互优先选择真连接延迟稳定、连续测试离散程度小的节点；大文件任务优先选择持续速度接近直连基线的节点；两项都不稳定时，先排查本地网络和分流规则，再判断订阅节点本身。
结论:记录中位数，不追逐单次最低值
将 ping、真连接延迟、30 秒平均下载速度和测试时段记在同一张表里。单次最低数字只能表示当时的一次结果，中位数和跨时段稳定性更适合决定日常主力节点。