本文速览
本文适合面对一组延迟数字却不知道该看哪项的 v2rayN 用户。读完可以分清 ICMP 往返时间、完整代理连接耗时与持续传输速度，并按网页浏览、视频播放和大文件传输等场景选择测试方法。
三种测试测量的不是同一段链路
节点列表里出现 35 ms、126 ms 和 78 MB/s 时，这三个数字不能直接横向比较。毫秒表示一次交互所需的时间，MB/s 或 Mbps 表示单位时间内能传输多少数据；即使同样以毫秒显示，ICMP Ping 与真连接延迟经过的协议栈也不一样。
ICMP Ping 通常从本机直接向节点服务器地址发送回显请求，主要观察网络层往返时间和丢包。它不会完成 VMess、VLESS、Trojan 或 Shadowsocks 的代理握手，也不会验证节点配置里的用户标识、端口、传输层参数和加密设置是否可用。
真连接延迟会让客户端启动当前配置，通过本地代理入口建立到目标站点的实际连接。过程包含域名解析、与服务器建立 TCP 或其他传输连接、完成代理协议握手，再等待测试目标返回响应。下载测速则继续传输较大数据，用时间和数据量计算吞吐率。
| 测试方式 | 主要单位 | 经过代理协议 | 适合判断 | 不能单独证明 |
|---|---|---|---|---|
| ICMP Ping | ms、丢包率 | 否 | 基础网络可达性、物理距离 | 节点配置能够代理流量 |
| 真连接延迟 | ms | 是 | 节点能否完成真实连接、交互响应 | 持续下载带宽足够 |
| 下载测速 | Mbps 或 MB/s | 是 | 实际吞吐量、线路拥塞情况 | 短请求一定响应迅速 |
ICMP Ping
执行快、流量消耗很低，适合先看服务器是否可达以及线路是否存在明显丢包。
适合:批量初筛、排查基础网络
真连接延迟
推荐覆盖代理握手和目标响应，最适合作为日常选择可用节点的第一依据。
适合:网页浏览、首次连接、日常换节点
下载测速
通过持续传输观察实际带宽，但耗时、流量和测试目标负载都会影响结果。
适合:视频、大文件与带宽确认
ICMP Ping 低，只代表基础路径较短
Ping 数值由本机到服务器 IP 的网络路径决定。通常情况下，同地区服务器会比跨洲服务器更低，但运营商路由、晚高峰拥塞和中间网络绕行都可能改变结果。一个地理位置较近的节点，也可能因为路由绕行而得到更高延迟。
例如，同一台电脑连续发送 20 次请求，节点 A 平均 38 ms、丢包 0%，节点 B 平均 31 ms、丢包 15%。只看平均值会误以为 B 更快，但 15% 丢包会触发重传和等待，网页加载及代理握手的实际表现通常更不稳定。此时应优先保留无丢包的 A。
部分服务器会限制或忽略 ICMP 请求，所以 Ping 超时不等于代理端口必然不可用。反过来，服务器能够回应 Ping，也不代表订阅中的端口正在监听，更不能证明 UUID、传输路径、TLS 域名等配置匹配。遇到 Ping 超时但真连接有数值的节点，应以真连接结果为准。
- 平均延迟反映总体往返时间，但会掩盖单次尖峰。
- 最低延迟接近链路的理想状态，不能代表持续使用体验。
- 最高延迟与波动范围可辅助判断网络抖动。
- 丢包率比相差 5 至 10 ms 的平均延迟更值得优先处理。
- 企业网络或公共网络可能直接过滤 ICMP，而不影响允许的 TCP 连接。
38 ms
示例 ICMP 平均值
0%
示例丢包率
112 ms
同节点真连接延迟
74 Mbps
同节点下载结果
真连接延迟最适合确认节点能不能用
真连接延迟比 Ping 多出了一整段应用层过程。以常见 TCP 传输为例，客户端需要解析地址、建立到服务器端口的连接、按节点配置完成代理握手，然后经代理访问测试目标。若使用 WebSocket、TLS 或其他传输组合，还会增加对应的握手步骤。
因此，真连接延迟高于 ICMP 延迟是正常现象。假设 Ping 为 40 ms，完整测试得到 105 ms，并不能据此认定节点异常。额外时间可能来自 TCP 建连、TLS 协商、代理协议处理、目标站点响应，以及客户端测试任务排队。
在 v2rayN 中，可先选中一个或多个节点，再使用「服务器」→「测试服务器真连接延迟」。部分界面版本也会在节点右键菜单提供同名操作。测试完成后，成功项会写入毫秒数；显示超时或失败的项目，需要结合日志判断是节点不可用、目标不可达，还是测试等待时间不足。
- 先更新订阅，避免用已经被服务端移除的旧配置测试。
- 在节点列表中选中候选节点，执行「服务器」→「测试服务器真连接延迟」。
- 将超时节点暂时排除，从有结果的节点里比较延迟和稳定性。
- 把候选节点设为活动服务器，开启系统代理后实际打开多个页面。
- 若首次结果异常，间隔 30 秒再测两次，避免单次网络抖动造成误判。
推荐方案:分两轮筛选候选节点
第一轮:确认可用性
- 批量执行真连接延迟
- 保留连续两次成功的节点
- 排除持续超时与握手失败项
第二轮:匹配实际用途
- 浏览用途比较响应时间
- 视频用途追加下载测速
- 晚高峰重新测一次候选项
先验证完整代理链路，再测带宽，可以减少对失效节点执行大流量测试的无效等待。
如果所有节点同时显示真连接超时，应先检查本地状态，而不是立即判断整条订阅失效。打开「设置」→「参数设置」→「基础设置」，确认本地监听端口未与其他程序冲突；常见配置会使用 10808 作为本地 SOCKS 入口，旧式分离配置还可能使用 10809 作为 HTTP 入口，实际应以当前界面显示值为准。
结论:日常选节点先看真连接结果
节点只要能连续完成两到三次真连接测试，才进入延迟比较阶段。Ping 很低但真连接持续超时的节点，不应作为当前活动服务器。
下载测速反映吞吐量，不等于打开网页更快
下载测速关注持续数据传输能力。测试通常通过当前代理连接下载一段数据，再用传输字节数除以耗时得到速度。它会同时受到本地接入带宽、无线网络质量、节点出口容量、线路拥塞、测速目标限速和客户端并发策略影响。
Mbps 与 MB/s 不能直接按相同数字比较。网络带宽常用 Mbps，文件下载界面常用 MB/s；理论换算关系是 8 Mbps 约等于 1 MB/s。若测速结果为 80 Mbps，对应理论上限约 10 MB/s，但协议开销、重传和磁盘写入会使实际文件速度略低。
高带宽节点未必拥有最低的交互延迟。例如节点 A 真连接延迟 85 ms、下载 42 Mbps，节点 B 真连接延迟 145 ms、下载 160 Mbps。日常打开网页时 A 可能更利落，而高码率视频或大文件传输更适合 B。选择标准应由用途决定，而不是把三项数值合成一个简单排名。
| 使用场景 | 优先指标 | 参考判断 |
|---|---|---|
| 文字网页与搜索 | 真连接延迟 | 连续测试稳定，数值波动较小 |
| 高清视频 | 下载速度与稳定性 | 持续带宽高于视频码率，并保留余量 |
| 大文件传输 | 下载速度 | 观察 30 秒以上的持续速度而非瞬时峰值 |
| 频繁交互页面 | 真连接延迟与抖动 | 优先选择响应稳定的节点 |
在 v2rayN 中选中候选节点后，可使用「服务器」→「测试服务器下载速度」。下载测速会产生实际订阅流量，不适合对整个节点列表频繁执行。先用真连接延迟筛到两三个候选项，再分别测速一次，通常已经足够判断。
结论:带宽测试要贴近使用时段
如果主要在晚间使用，就在晚间对候选节点各测两次，并以较低的一次作为容量参考。只记录空闲时段的峰值，无法代表拥塞时段的持续表现。
按固定顺序测速，结果才有可比性
测速最常见的问题不是工具错误，而是测试条件不断变化。上午测节点 A、晚上测节点 B，或者一项走有线网络、另一项走无线网络，所得差异无法单独归因于节点。应尽量保持设备、接入网络、测试目标和时间窗口一致。
建议每个候选节点执行三次真连接测试，间隔 10 至 30 秒，记录中位数而不是只取最低值。比如结果为 92 ms、108 ms、246 ms，中位数是 108 ms；246 ms 提示一次明显抖动，也应保留观察，而不是删除后只展示更好看的数值。
- 关闭正在进行的大文件下载、云端同步和系统更新。
- 在同一网络下更新订阅，选出地区和倍率符合需求的节点。
- 先执行真连接延迟，排除连续超时与协议握手失败的配置。
- 对剩余节点重复测试三次，比较中位数和最大值差距。
- 仅对最终两到三个候选节点执行下载测速。
- 设为活动服务器后打开实际使用的网站，确认系统代理已经生效。
节点 A：真连接 92 / 108 / 246 ms，下载 68 Mbps
节点 B：真连接 124 / 128 / 131 ms，下载 82 Mbps
节点 C：真连接超时 / 超时 / 310 ms，暂不选用
浏览优先：节点 B，延迟略高但波动更小
下载优先：节点 B，持续带宽也更高
继续观察：节点 A，需确认 246 ms 是否在晚高峰重复出现
若要确认浏览器流量确实经过代理，可以先在 v2rayN 中设定活动服务器并开启系统代理，再访问可信的 IP 信息页面，对比启用前后的出口地址。若地址没有变化，优先检查系统代理状态和浏览器自身的代理设置，不要用重新测速代替流量路径确认。
常见异常数值怎么处理
同一节点在短时间内出现明显不同的结果，通常需要从本地网络、节点负载和测试目标三端排查。不要只根据一次超时删除节点，也不要因为一次极低延迟就长期固定使用。连续结果比单次峰值更有判断价值。
路由分流也会影响测试与实际访问的对应关系。测试目标可能按当前路由规则走代理，但某个实际域名可能被规则设为直连；也可能正好相反。若测速正常而特定网站表现不同，应检查路由规则命中情况和核心日志，而不是继续重复下载测速。
Ping 只有 20 ms，为什么真连接超过 150 ms？
Ping 没有执行代理协议与目标站点握手。先连续测试三次；若都能成功且波动较小，这个差值本身不表示故障。还可更换测试目标，排除目标响应较慢的影响。
Ping 全部超时，但节点可以打开网页怎么办？
服务器或中间网络可能不回应 ICMP。保留能够通过真连接测试且实际访问正常的节点，不要把 Ping 超时当成删除配置的唯一条件。
真连接全部显示超时，先检查哪里？
先确认订阅已更新，再查看「设置」→「参数设置」→「基础设置」里的本地端口，并检查核心日志是否出现端口占用、域名解析失败或握手失败。随后单独测试一个节点。
下载测速很高，网页为什么仍然打开得慢？
下载速度衡量持续吞吐，网页还受连接建立、域名解析、目标服务器响应和大量短请求影响。改看真连接延迟与波动，并检查该域名实际命中了代理还是直连规则。
测速时应该一次选中所有节点吗？
真连接延迟可以批量初筛；下载测速只对最终候选节点执行。大量并发任务会争用本地带宽，也可能让后测节点得到偏低结果。
最终判断可以压缩为三步：Ping 用于了解基础网络与丢包，真连接延迟用于确认配置可用并比较交互响应，下载测速用于核对持续带宽。三者没有相互替代关系，也不存在一个数值能够完整概括节点质量。