本文适合遇到“延迟很低却打不开网页”“Ping 超时但代理正常”“测速很快却频繁卡顿”的 v2rayN 用户。先分清主机响应、端口连通、代理请求与持续吞吐四层指标，再用固定目标、串行复测和实际应用验证筛选节点；不把一个毫秒数当作完整的可用性结论。
四类测试：先确认数字来自哪一层
v2rayN 是桌面图形客户端，节点配置交给所选内核处理。服务器列表里的延迟不是节点固有属性，而是当前网络、测试目标、测试实现共同产生的结果。更换 Wi-Fi、改变测试 URL，甚至同一时段并行测试更多节点，都可能改变排名。
不同版本的菜单名称、测试选项和计时范围会有变化。执行前先看命令名称，不能把 TCPing 的结果称为“代理访问延迟”，也不能把下载速度列当作网页首屏加载时间。
| 指标 | 主要测量对象 | 能说明什么 | 不能据此确认什么 |
|---|---|---|---|
| ICMP Ping | 本机到目标地址的 ICMP 往返 | 目标是否响应、往返时间及样本丢失 | 代理端口、认证与目标网站是否可用 |
| TCPing | 本机到指定 TCP 端口的建连 | 对应地址与端口是否接受 TCP 连接 | VMess、VLESS 等协议配置是否正确 |
| 真连接延迟 | 经被测代理配置访问测试 URL | 该配置在指定测试条件下能否完成请求 | 所有网站、UDP 流量与长时间下载是否正常 |
| 下载测速 | 经代理下载测试资源 | 该资源与测试时段下的传输速率 | 日常延迟、长期稳定性及所有业务速度 |
Ping 与 TCPing：低延迟不等于代理可用
ICMP Ping 不会提交代理协议的认证信息，也不验证 TLS、WebSocket 路径或服务端出站能力。部分服务器或中间网络会限制 ICMP，因此 Ping 超时只能说明没有收到预期响应，不能直接判定代理失效。反过来，ICMP 正常也不表示服务端正在监听代理端口。
TCPing 更接近端口层检查。例如节点配置使用 TCP 443 端口，就应测试配置里的服务器地址与 443，而不是随意换成另一台主机。端口接受连接之后，仍可能在后续认证、TLS 协商或传输层路径匹配阶段失败。使用 CDN 的节点，TCP 连接还可能先到达边缘入口，并不代表已经到达实际代理服务。
- Ping 有响应，TCP 建连失败：优先检查节点端口是否填错、网络是否拦截该端口，以及服务端监听状态。
- TCP 建连成功，真连接超时：转查协议参数、TLS 服务名称、传输配置与服务端转发能力。
- Ping 超时，真连接正常：保留该节点，不要仅因 ICMP 无响应就删除。
- 节点使用非 TCP 传输：TCPing 不能代替对应传输的可用性测试，应使用内核实际建立代理连接。
真连接延迟：测试 URL 与内核都参与结果
真连接测试通常为被测配置启动或使用代理出站，再访问指定 URL。它比单独测试 TCP 端口覆盖更多环节，但“真连接”并不是所有版本统一的计时标准。DNS 解析、代理握手、TLS 建连、收到响应等步骤是否完整计入，需要以当前版本实现为准。
在 v2rayN 中，可先进入「设置」→「参数设置」，查找与延迟测试地址、测速地址相关的选项；服务器列表的右键菜单通常提供含“真连接延迟”的测试命令。具体分组和措辞以安装版本为准。记录当前地址后再修改，避免换了目标却继续把新旧数字直接比较。
固定的小响应测试目标
推荐使用稳定、可访问、响应内容较小的同一个 URL，保持协议与重定向行为一致。比较不同节点时只更换节点，不同时更改测试目标。
适合：日常筛选可用节点、比较重复测试结果。
实际使用的网站
用于补充验证登录、页面资源与特定出口限制。完整网页包含多个域名和请求，不能把整页加载耗时直接替代小响应延迟。
适合：通用测试通过，但特定业务仍然失败。
大文件下载目标
适合观察吞吐与持续传输，不适合作为低流量的频繁探测。资源限速、缓存命中与测试时长都会影响显示结果。
适合：候选节点已通过连通性检查，需要比较下载能力。
如果全部节点突然对同一 URL 超时，先检查该目标是否异常，而不是立即重新导入所有订阅。还应检查系统时间、日志里的证书错误，以及测试目标是否被服务端出口拒绝。通过一次真连接测试，只能证明这次测试请求成功。
下载测速：区分带宽、单位与瞬时峰值
延迟描述请求往返等待，吞吐描述单位时间传输的数据量。两者可能相关，却不是一回事。跨区域节点即使往返较慢，也可能有更高的持续下载速度；近距离节点即使建连快，也可能受共享带宽和高峰拥塞限制。
下面三项是单位换算示例，不是本站实测成绩，也不是任何节点的性能承诺。小写 b 表示 bit，大写 B 表示 byte；按十进制单位换算，1 byte 等于 8 bit。若软件显示的是 MiB/s，还要考虑二进制单位差异。
判断：先通过连通测试，再消耗流量测速
只给真连接稳定通过的两三个候选节点做短时、串行下载测试。记录持续速率而非最高一跳，并确认订阅套餐的流量计费方式。
- 本地上限：宽带速率、无线信号、路由器负载和其他下载任务，都会压低结果。
- 远端上限：节点出口、测速资源所在网络、单连接限速和服务端繁忙程度，都会限制吞吐。
- 测试时长：过短可能还没进入稳定传输，过长则消耗更多流量；比较时应统一时长。
- 协议开销：加密、封装与重传占用资源，实际应用速度通常达不到标称线路的理论换算值。
可复现的筛选顺序：固定条件，分层记录
不要选中全部节点后同时执行多种测试。并发任务会争抢本地带宽、连接资源和处理器时间，测试自身就可能制造排队。更可靠的做法是先粗筛，再缩小范围，最后检查实际应用。
- 固定环境：暂停系统更新与大文件下载，使用同一网络，记录当前内核、测试 URL 和测试时间。
- 初筛端口：对适用的 TCP 节点检查连通性。此步只是缩小范围，不以 Ping 结果作为唯一淘汰标准。
- 复测真连接：对候选节点逐个测 5 次，保留成功次数与各次耗时。成功不足 5 次时，不要只记录成功样本的平均值。
- 比较中位数：例如五次为 180、185、190、210、900 ms，排序后的中位数是 190 ms；同时保留 900 ms 的尖峰记录，不能用中位数掩盖波动。
- 短时测吞吐：对两三个稳定候选使用相同资源和时长，串行执行。上述数据只是计算示例，并非实测节点排行。
- 回到真实应用：切换活动节点，检查系统代理或 TUN 是否按预期启用，再验证常用网页、视频或文件传输。
两种使用需求：采用不同的复测重点
网页浏览与交互请求
- 优先检查真连接成功率与重复测试波动。
- 用实际网站验证域名解析、登录与资源加载。
- 保留高峰时段记录，不只看空闲时最低值。
大文件与持续传输
- 先确保连接稳定，再比较持续下载速率。
- 固定下载目标、测试时长与本地网络。
- 观察中途停顿和重连，不以瞬时峰值排名。
结论：主力节点按真实业务选，备用节点按可用性保留；延迟与吞吐分开记录。
测试通过仍打不开：检查实际流量路径
节点测试与浏览器流量不一定经过完全相同的入口和路由。客户端可以对指定节点发起测试，但浏览器可能没有使用系统代理，也可能被分流规则安排直连。因此，“服务器列表测试成功”与“当前应用已走该节点”是两个不同判断。
- 系统代理：确认应用是否读取系统代理设置。命令行工具和部分应用不一定自动跟随。
- TUN：检查虚拟网络接口是否成功启动、权限是否满足，以及相关路由是否生效，不要只看开关外观。
- 本地监听：核对参数设置中的实际端口。若自行配置为
127.0.0.1:10808，应用也必须使用对应端口与正确代理类型；此处是配置示例，不保证等于当前版本默认值。 - 路由与 DNS：查看目标域名命中的规则和出口。能访问测试域名，不代表业务域名也走同一路径。
- 内核日志：区分连接超时、认证失败、证书错误和本地端口占用，再决定修改哪一层配置。
VMess 与 VLESS 是代理协议名称，不是速度档位；更换协议不能替代参数核对。对于 TLS 节点，应按服务端要求检查服务名称等设置，不要为了让测试变绿而随意关闭证书验证。配置与服务端不匹配时，低 TCP 延迟没有修复意义。
常见问题：延迟列、测速值与节点选择
延迟显示 -1，是不是节点彻底失效了？
部分版本用负值或空值表示测试未成功，不代表“负延迟”。先看使用的是 TCPing 还是真连接测试，再用同一目标单独重试该节点，检查日志和超时设置；只有多次失败且实际应用也不可用，才继续按节点故障处理。
为什么 80 ms 的节点反而比 200 ms 的慢？
先确认两项数字来自相同测试。若都是同一 URL 的真连接延迟，再比较持续吞吐和请求成功率。80 ms 节点可能建连快但出口拥塞，200 ms 节点可能往返更远却有更充足的传输带宽。
测速时需要打开系统代理吗？
客户端内置节点测试通常自行使用被测代理配置，不应把系统代理开关当作其唯一前提，具体行为以当前版本为准。用浏览器或外部下载工具验证时，则要单独确认系统代理、TUN 或工具代理参数是否生效。
每次排名都变，要不要一直自动切换？
先固定测试条件，在空闲与高峰时段分别记录 5 次结果。若差距只有少量毫秒而成功率相近，优先保留当前稳定节点；只有持续超时、明显卡顿或业务不可用时再切换，避免把正常波动误当故障。
下载速度正常，可以证明视频和实时通信都正常吗？
不能。下载测速主要观察特定资源的吞吐，实时业务还受抖动、丢包、UDP 支持和应用自身选路影响。用实际应用短时验证，并记录中断现象，不要从单个下载成绩推断所有网络业务。
最终选择：成功率优先，延迟与速度按需排序
保留一个常用节点和一个已验证的备用节点。出现异常时先复测同一目标，再核对应用流量路径；只有证据指向节点参数或服务端，才调整订阅与协议配置。