节点列表里的毫秒数与下载速度回答的是不同问题。Tcping 用来检查服务器端口是否可达，真连接延迟用来判断代理请求能否完成，下载测速用来观察持续传输能力。本文适合遇到“延迟很低却打不开网页”“真连接超时但端口正常”的用户，按测试范围、结果解释和排查顺序，说明怎样筛选可用节点，而不是只按一个数字排序。
三种测试分别测到哪一段
先把链路拆开：本机连接节点服务器，代理核心完成协议与传输层协商，节点再访问目标网站。节点服务器有响应，不代表身份认证成功；认证成功，也不代表目标网站可以访问。三种测试覆盖的范围不同，结果不能互相替代。
Tcping：服务器端口可达性
尝试与节点地址、端口建立 TCP 连接，主要反映连接建立耗时。不验证 VMess 或 VLESS 的认证信息，也不请求目标网页。
适合：快速排除端口不可达、服务器地址错误等基础连接问题。
真连接延迟：代理请求可用性
推荐通过待测节点向指定测试地址发起请求，覆盖代理协议协商与节点出口访问。它更接近日常网页请求，但只代表这个测试目标。
适合：日常选节点时，先筛出能够完成代理请求的候选。
下载测速：持续传输能力
经由待测节点下载测试数据，观察一定时间内的传输速率。结果受测试源、网络拥塞、测速时长与并发数量共同影响。
适合：已确认连接正常后，比较大文件下载等持续流量场景。
在 v2rayN 主窗口选中服务器后，打开右键菜单，分别查找“测试服务器延迟 Tcping”“测试服务器真连接延迟”“测试服务器速度”等项目。不同界面与版本可能调整文字和位置，应以当前菜单为准；不要把某个版本的快捷键当成所有版本通用的操作。
Tcping 很低，为什么网页还是打不开
Tcping 不等于系统的 ping。常见的 ping 使用 ICMP，而这里检查的是 TCP 端口。服务器可以禁用 ICMP 回应，却仍接受 TCP 连接；反过来，某台主机能回应 ping，也不代表节点所用端口开放。
如果节点填写的是域名，建立连接前还需要得到地址。域名解析耗时是否计入显示结果，取决于测试实现，不能仅凭一个 Tcping 数字推断 DNS 一定正常。对于不以 TCP 作为实际传输的配置，TCP 探测更不能替代真实协议测试。
- 端口通，认证错：UUID、密码或协议参数错误时，TCP 连接仍可能成功，但代理请求会失败。
- 入口通，传输不匹配：WebSocket 的路径、Host 或 TLS 的服务器名称配置不一致，可能在后续协商阶段被拒绝。
- 前置服务响应：使用反向代理或 CDN 的节点，Tcping 可能测到的是前置入口，不是后端代理服务的完整状态。
- 出口访问受限：节点接受连接后，仍可能无法解析或连接测试网站，原因包括出口网络故障、目标限制等。
判断：端口可达后，立即验证代理请求
当 Tcping 有结果而网页打不开时，下一步运行真连接延迟并查看核心日志。不要仅因毫秒数较低，就反复改本地系统代理设置。
真连接延迟包含什么，超时该查哪里
真连接延迟不是单纯的“本机到服务器距离”。一次测试通常包含连接节点、代理协议协商、节点访问测试地址，以及等待响应等阶段；使用 HTTPS 测试地址时，还涉及相应的 TLS 过程。具体计时边界、连接复用和成功判定会随版本实现变化，因此不适合拿不同工具的结果直接排名。
先在“设置”→“参数设置”中查找真连接测试地址、测速地址和超时相关选项。若当前界面分有多个页签，按“测试”或“速度”相关设置查找。记录实际 URL，再比较节点。测试地址返回空响应或较小内容，通常更适合观察请求延迟；大文件地址则更适合吞吐测试，两者用途不同。
- 只测一个节点。暂停批量任务，再对同一节点重测，避免并发连接抢占本地带宽或触发服务端限制。
- 核对节点参数。在服务器列表编辑对应条目，对照来源确认地址、端口、认证信息、传输方式与 TLS 设置，不要靠猜测补字段。
- 核对系统时间。启用操作系统自动校时。明显的时间偏差会影响证书验证，也可能影响具有时间要求的协议认证。
- 观察日志阶段。连接超时优先查可达性；证书错误查时间与服务器名称；认证或传输错误查节点参数。单独出现一个 timeout 并不能确定故障在哪一端。
- 更换合法可访问的测试目标复核。如果只对原目标失败，继续检查节点出口到该目标的连接，而不是直接认定整个节点失效。
下载测速怎么读：单位、时长与流量
下载测速观察的是吞吐，不是响应延迟。高延迟线路在持续下载时仍可能跑出较高速度，低延迟线路也可能被出口带宽或服务端限速卡住。首次请求是否利落和长时间下载是否稳定，需要分别判断。
上面的带宽数值是单位换算示例，不是本站实测结果。注意大写 B 与小写 b：MB/s 是每秒兆字节，Mbps 是每秒兆比特；若界面显示 MiB/s，其换算基数又与 MB/s 不同。比较前先统一单位，不能把运营商标称带宽与测速栏数字直接相减。
- 固定测试源：同一节点换一个下载地址，结果就可能变化。测试源自身的限速、负载和地理位置都会参与结果。
- 固定测试条件：保持同一网络、相近时间与同一测速设置；暂停大文件下载、云同步和其他占带宽任务。
- 避免只看瞬时峰值：短时间测试会受到连接建立与传输加速阶段影响。记录客户端显示的是平均值还是其他统计值，再解释结果。
- 关注流量消耗：假设持续以 10 MB/s 下载 10 秒，数据量约为 100 MB，另有协议开销。批量测试多个节点会继续累加。
把测试结果变成选节点的顺序
不要先给所有节点跑下载测速。先确认可达，再确认真实请求，最后只对少数候选测吞吐，排查范围更清晰，也能减少不必要的流量消耗。以下表格是结果组合的解释，不是某批节点的性能记录。
| 结果组合 | 优先判断 | 下一步 |
|---|---|---|
| Tcping 成功，真连接超时 | 入口可达，后续代理请求未完成 | 检查协议参数、核心日志与测试目标 |
| 真连接成功，下载速度偏低 | 基本请求可用，吞吐受限 | 固定测试源，排除本地占带宽任务后复测 |
| 真连接较慢，持续下载较快 | 响应延迟与持续吞吐表现不同 | 按网页交互或文件下载的实际用途选择 |
| 测试成功，浏览器失败 | 应用接管或目标路由可能不同 | 检查系统代理、浏览器设置与命中规则 |
操作：保留稳定完成请求的节点，再比较吞吐
对候选节点各做三轮真连接测试，记录失败次数与耗时变化。先排除反复超时的条目，再对剩余候选运行下载测速；最终用实际需要访问的网站复核一次。
三轮结果可以按从小到大排列，取中间值作为本轮比较参考，同时保留失败记录。不要把超时记成 0 毫秒后求平均；这样会把失败节点算成“更快”。不同时间段的结果也应分开记录，晚间拥塞不能用白天的一次测试解释。
延迟测试常见问题
显示 -1 或超时，是节点彻底失效了吗？
不一定。负值或超时通常是失败状态，不是实际延迟。先单独重测，再核对测试地址和日志。如果多个节点只对同一个目标失败，先换测试目标复核；如果只有一个节点持续失败，再检查它的配置与服务状态。
为什么刚测完很快，过一会儿又变慢？
列表数字是一次测试的结果，不是持续监测。保持同一测试目标，分三轮记录耗时和失败情况，同时暂停后台下载。若波动集中在某个时段，再比较该时段的实际访问表现，不必因一次峰值立即更换整套配置。
要先开启系统代理或 TUN，才能测节点吗？
内置测试一般会为待测节点建立测试路径，不应把开启系统代理或 TUN 当作统一前提。先确认核心能正常启动；测试通过后，再为浏览器等应用选择接管方式。若同时使用多种接管方式，要检查是否产生回环或路径混淆。
真连接最快的节点就一定最适合下载吗？
不一定。先用真连接筛出可用节点，再对其中少数候选运行下载测速。下载任务优先观察持续速率和稳定性；网页交互则更看重请求响应与失败率。测试目标与实际业务目标不同，最后仍需用真实访问场景确认。