先用 TCPing 排查节点入口，再用真连接延迟确认代理链路，最后用下载测速判断持续传输能力。本文适合遇到“延迟很低却打不开网页”或“测速很快但日常卡顿”的用户。读完后，可以按同一网络、同一目标、分轮测试的方法比较结果，而不是只按列表中最小的数字选节点。
一、先看测量对象：三个数值不能互相替代
先确认菜单里的测试名称，再比较数字。TCPing 通常指向节点服务器的 TCP 端口发起连接，并记录建立连接所需的时间；它不是传统的 ICMP Ping。毫秒写作 ms，表示耗时，通常越低越好。下载测速常用 MB/s，表示每秒传输的数据量，通常越高越好。
真连接延迟则通过节点发出一次实际请求，检查代理能否访问指定的测试地址。客户端版本、内核和测试地址不同，计时起点与终点也可能不同。它可能包含代理握手、目标连接、TLS 握手及等待响应的部分耗时，不能简单当作服务器的网络往返时间。
TCPing：检查入口端口
主要回答“本机能否连到这个地址和端口”。它不验证 VMess 或 VLESS 等代理协议的认证，也不证明节点能够访问目标网站。
适合：快速筛除入口连接失败的配置，检查地址、端口和本地网络。
真连接延迟：优先确认日常可用性
推荐使用配置建立代理链路，再访问测试地址。比单纯端口连接更接近打开网页的过程，但成功只代表该测试目标可访问。
适合：选择日常浏览节点，检查协议参数与代理出口是否可用。
下载测速：检查持续传输能力
通过节点持续接收数据。结果同时受本地带宽、节点负载、出口路径和下载服务器限制，不能直接换算成网页打开速度。
适合：视频、大文件下载，以及比较同一时段的持续吞吐表现。
二、TCPing 很低却打不开网页：按链路逐层排查
先不要反复切换协议。TCPing 成功，只说明入口端口完成了 TCP 连接。如果节点入口是反向代理或中转服务器，测试可能在入口处就结束了；后面的代理认证、服务器转发和目标站点都尚未经过验证。
| 观察到的现象 | 优先检查 | 下一步操作 |
|---|---|---|
| TCPing 成功，真连接失败 | 协议参数、认证、传输与安全设置 | 核对订阅中的地址、端口、用户标识，以及 TLS、SNI 或传输路径；不要把入口可达当成配置正确。 |
| 真连接成功，只有部分域名失败 | DNS、路由与目标站点限制 | 比较测试域名与失败域名的路由去向，查看失败请求是否走了直连。 |
| 客户端测试成功，浏览器无法访问 | 系统代理或应用接管范围 | 确认浏览器使用客户端本地监听端口；安卓端确认 VPN 已连接，目标应用包含在代理范围内。 |
| 换到另一网络后恢复 | 当前接入网络与入口路径 | 分别记录 Wi-Fi 和移动网络结果，不要把两个网络的样本混在一起排序。 |
TLS 是保护连接的加密协议；SNI 是 TLS 握手中用于指明目标主机名的信息。入口端口即使能连接，SNI、证书验证、WebSocket 路径或 Reality 参数不匹配，仍可能在后续握手阶段失败。先重新核对订阅参数，不要通过关闭证书验证来掩盖问题。
三、真连接延迟怎么测：固定目标，重复确认
先固定测试地址，再对候选配置重复测试。测试地址是客户端用来判断连接状态的目标 URL，不是节点服务器地址。不同网站的部署区域、响应方式和访问策略不同；今天测一个目标、明天换另一个目标，得到的结果不适合直接比较。
- 确认测试设置。在 v2rayN 的「设置」→「参数设置」中查找与延迟测试地址、下载测速地址有关的项目。具体字段名随版本变化，先记录当前值，不要为追求更低数字频繁更换。
- 分开执行测试。在 v2rayN 配置列表中选中条目，打开右键菜单，分别执行名称包含「Tcping」和「真连接延迟」的测试项。不要将批量测试与大文件下载同时运行。
- 安卓端选择可用的测试项。在 v2rayNG 主列表打开右上角菜单，查找「测试全部配置真连接」等测试项；部分版本需要先启动服务。若名称不同，以当前版本菜单为准，不把“测试成功”理解成所有应用都已被接管。
- 至少测三轮。每轮结束后等待约 10 秒，再测下一轮。保留每一轮的成功或失败状态；成功样本看中位数，不只取最小值。
- 补一次实际访问。选中配置后启动连接，打开日常使用的网站。测试地址成功、实际网站失败时，转向检查该网站的 DNS、路由和访问限制。
这里的数字是操作建议，不是节点实测成绩。三轮测试只能做快速筛选，不能证明长期稳定；若用于会议或长时间传输，还应在实际使用时段继续观察。批量测试并发较高时，本地网络和设备资源也可能被占满，出现异常后应改为单条重测。
结论：先剔除反复失败项，再比较成功样本
不要让一次很低的成功耗时掩盖其他轮次的失败。先保留重复测试均能完成、实际目标也可访问的配置，再比较它们的典型耗时与波动。
四、下载测速怎么看：区分带宽、单位与测试成本
只对已经通过真连接测试的少量配置做下载测速。吞吐量指单位时间内传输的数据量，它与延迟是两个维度。连接建立得快，不代表持续传输能力强；持续下载速度高，也不代表每次小请求都响应迅速。
- 先对齐单位。1 Byte 等于 8 bit。忽略协议开销时，100 Mbps 的带宽约对应 12.5 MB/s；这是单位换算，不是节点速度承诺。若界面显示 MiB/s，还要注意它与十进制 MB/s 不完全相同。
- 确认线程数量。单连接与多连接测试不能直接混比。多连接可能更容易用满带宽，但单个下载任务或单条业务连接未必获得相同速度。
- 保持测试条件一致。使用相同下载地址、相同持续时间和相同网络，暂停后台同步、系统更新及其他设备的大流量任务。
- 看持续表现。刚开始的瞬时峰值容易受缓冲和采样影响。观察后续是否持续稳定，再结合实际视频或文件下载验证。
- 控制流量消耗。按持续 10 MB/s 下载 20 秒计算，数据量约为 200 MB，另有协议开销。批量测试会累加消耗本地网络与订阅流量。
测速服务器本身也可能成为瓶颈。如果同一时段所有配置都得到接近的低速度，先检查本地网络与测试源，不要立即认定全部节点拥塞。浏览器测速还受浏览器代理设置影响；它测到的可能是直连路径，必须先确认请求确实经过选中的配置。
五、桌面与安卓怎么选：同一方法，分别验证接管范围
先把“节点本身能用”和“应用已经走代理”分开验证。v2rayN 是桌面客户端；v2rayNG 是使用 Xray 内核的安卓客户端。两端即使导入同一条订阅，也可能因为接入网络、DNS 和代理范围不同，出现不同结果。不要要求两个设备的延迟数字完全一致。
推荐方案：先测配置，再测实际应用
桌面端：v2rayN
- 先运行真连接测试，确认选中配置可以访问测试目标。
- 使用系统代理时，确认目标程序会读取系统代理设置；命令行工具不一定自动跟随。
- 检查本地监听地址和端口。例如实际端口若为 10808，应用必须使用对应端口与协议，不能凭记忆填写。
- 使用 TUN 虚拟网卡接管流量时，检查接管状态与路由，不把它和系统代理的效果混为一谈。
安卓端：v2rayNG
- 选中配置并启动服务，确认系统已授予 VPN 权限。
- 若启用分应用代理，检查浏览器和实际业务应用是否处于预期范围。
- 切换 Wi-Fi 与移动网络后重新测试，不沿用上一网络的排序结论。
- 若切到后台后才断流，再检查系统电池限制；不要先把所有故障归因于节点速度。
两端保持测试目标一致，但分别记录网络、时间和应用接管状态；可用性验证通过后，再比较延迟与吞吐。
记录结果时，写下测试时间、客户端版本、网络类型、目标地址、成功次数与速度单位即可。分享截图前遮住订阅链接、用户标识和服务器敏感信息。无需把完整配置发给他人，通常先提供失败阶段与相关错误文本就能缩小范围。
六、常见问题：超时、负数与测速排序
真连接显示 -1，是不是延迟低到测不出来？
不是。部分版本用负数或特殊文本表示失败、超时或没有有效结果。先查看当前客户端的状态说明，再单独重测该配置，并检查运行日志。不要把负数放进成功样本排序，也不要把它当成“负延迟”。
为什么浏览器能打开网页，客户端测试却超时？
先检查测试目标是否单独受限，再确认浏览器是否真的走了同一配置。浏览器可能命中缓存、使用另一代理扩展，或按路由直连。固定一个目标重复比较；若仅测试地址失败，可在设置中换成已确认可达且响应稳定的测试目标，再重新建立基线。
延迟最低的节点，看视频为什么还是缓冲？
先停止其他下载，再对当前配置测持续吞吐。视频缓冲还可能来自媒体服务器路径、节点出口负载或本地无线网络。比较同一视频、相同清晰度和同一时段，别用测试首页的毫秒数代替视频传输能力。
每次排序都变化，要不要一直切到第一名？
不必追逐单次最小值。先保留一个持续可用的主用配置和一个备用配置，重复三轮确认成功率。只有出现持续失败、明显波动或实际任务变慢时再切换；若只差少量毫秒，先观察实际体验，不要频繁中断现有连接。
七、最后按这个顺序选节点
- 先确认入口。TCP 传输可用 TCPing 做初筛，但不把端口可达等同于代理可用。
- 再确认链路。固定真连接测试地址，重复测试，优先保留没有反复失败的配置。
- 然后看任务。日常浏览参考真连接的稳定性；视频和大文件再补下载测速；实时业务在实际应用里验证。
- 最后查接管。确认系统代理、TUN 或安卓 VPN 的作用范围，避免客户端测试通过、业务流量却没有进入代理。
把每个指标放回它所测量的环节，排查会更直接。TCPing 用来问入口通不通，真连接用来问代理链路能否完成请求，下载测速用来问能否持续传输。先保证可用，再比较稳定性，最后看峰值，通常比只盯着一个排名更接近日常需求。