TCPing 适合初筛服务器端口，真连接延迟适合检查代理链路，下载测速适合判断持续吞吐。本文面向已经导入节点、但不知道该按哪个数字排序的用户：先明确测试边界，再用相同目标、相同网络和重复采样选出主用节点，最后定位“延迟很低却打不开网页”的原因。
一、三种测试测的不是同一段链路
v2rayNG 使用 Xray 内核处理代理连接，但列表里的 TCPing 通常只是对配置中的服务器地址和端口发起 TCP 连接。它不是系统的 ICMP Ping，也不会完成 VMess 或 VLESS 的代理认证。服务器填写域名时，测试前还需要解析地址；解析耗时是否计入显示值取决于实现，不能把它当成纯线路往返时间。
TCPing：服务器端口可达性
检查手机能否与节点端口建立 TCP 连接。假设节点使用 TCP 443，测到 45 ms 仅说明该端口连接较快，不能证明 UUID、TLS 的 serverName 或 Reality 参数正确。
适合：批量初筛、检查地址与端口是否可达。
真连接延迟：经代理访问测试目标
推荐通过待测配置请求测试 URL，计时可能包含代理握手、目标域名解析、TLS 建连与 HTTP 响应等环节。它比端口探测更接近日常打开网页的过程，但只代表这一测试目标。
适合：判断配置能否工作、选择日常浏览的候选节点。
下载测速：持续传输能力
经代理持续下载数据，观察单位时间内收到多少字节。结果受到节点限速、拥塞、目标服务器带宽与测试时长共同影响，不能由一次延迟测试推算。
适合：视频播放、大文件下载、检查晚高峰吞吐。
推荐先看真连接延迟，不等于永远选择毫秒数最低的节点。测试 URL 与实际使用的网站可能位于不同地区；节点访问测试站很快，访问业务站仍可能绕路。对主要使用 UDP 的场景，TCPing 和普通 HTTPS 下载也不能验证 UDP 转发能力。
二、在 v2rayNG 中按固定顺序测试
先保留现有配置，不要一边测速一边修改路由、DNS 与传输参数。v2rayNG 不同版本的菜单译名可能略有变化，以下以常见的 TCPing、真连接测试入口说明；找不到同名项目时，按功能识别，不要把列表底部的当前连接测试当成全部节点测试。
- 暂停其他传输。停掉应用更新、云盘同步与视频下载，固定使用同一个 Wi-Fi 或同一张移动数据卡。记录时间与网络类型，不要在两轮之间切换接入网络。
- 批量检查端口。打开主界面右上角「⋮」，选择「测试全部配置 TCPing」或对应 TCPing 项。先标记失败节点，保留成功节点，不急着删除配置。
- 批量检查代理链路。在同一菜单选择「测试全部配置真连接」或对应真连接项。若版本在「设置」中提供「测试 URL」或「连接测试 URL」，记录当前值；比较过程中不要更换地址。
- 复查当前连接。选中候选节点，点击右下角连接按钮并确认 Android VPN 授权。若界面提供底部连接状态测试，点击后检查当前配置是否仍能完成请求。
- 只给候选节点做吞吐测试。使用确认经过代理的浏览器访问固定测速页面，或下载同一个有足够带宽的测试文件。不要同时测试多个节点，避免它们争抢本地带宽。
批量真连接测试和当前连接测试的运行方式不一定相同，尤其是在客户端自行启动临时测试核心时。比较结果应同时记录“批量测试”还是“当前连接测试”，不要把不同入口产生的数值混成同一组样本。
三、用重复采样区分低延迟与高吞吐
下面是一组用于解释读数的示例记录，不是本站实测，也不代表任何服务的速度承诺。假设三条节点使用相同测试 URL、相同下载文件与同一接入网络，真连接每条测三次，下载结果取稳定阶段的平均速率。
| 候选节点 | TCPing | 真连接三次采样 | 下载平均速率 | 判断 |
|---|---|---|---|---|
| A | 38 ms | 310 / 920 / 460 ms | 1.2 MB/s | 端口快，完整请求波动明显 |
| B | 82 ms | 205 / 218 / 211 ms | 8.0 MB/s | 请求稳定，适合作为主用候选 |
| C | 65 ms | 三次均超时 | 未测 | 先排查配置，不进入吞吐比较 |
A 的 TCPing 最低，但三次完整请求的中位数是 460 ms；B 的中位数为 211 ms，且三次读数接近。此时优先试用 B 更合理。三次采样只能做快速初筛，不能据此计算可靠的丢包率，更不能把一次超时直接解释成线路丢包。
注意 MB/s 与 Mbps 相差八倍，MiB/s 又使用不同的字节计量方式。测速页面显示 64 Mbps，下载器显示约 8 MB/s，通常并不矛盾。持续 15 秒、平均 8 MB/s 的测试约消耗 120 MB 数据，多轮测试前应考虑移动数据额度。
结论：先剔除重复失败，再比较中位数与稳定下载速度
不要因 A 的 38 ms 就把它设为主用。先复查 C 的失败原因，再让 A、B 在实际业务中各运行一轮；若 B 持续稳定，就保留 B 为主用、A 为备用。
四、TCPing 很低，为什么真连接仍然超时？
端口可连接只验证了入口的一部分。代理认证失败、传输层参数错误、节点到测试站不可达，都发生在 TCP 建连之后。按下面顺序检查，可以避免把配置错误误判为服务器带宽不足。
“TCPing 只有 40 ms，为什么真连接一直超时？”
打开节点编辑页，核对地址、端口、UUID 与传输设置。VLESS + Reality 配置还应核对公钥、shortId 与 serverName；WebSocket 配置核对 path 和 Host。随后查看主界面「日志」中的连接或握手错误，不要通过关闭证书验证来掩盖问题。
“真连接显示 -1，是延迟太高吗？”
负数通常是失败标记，不是负延迟；具体提示以版本界面为准。先对同一节点重测，再查看日志是否出现解析失败、连接超时或 TLS 错误。若所有节点同时失败，优先检查测试 URL、本地网络与系统时间。
“真连接很好，但打开某个网站特别慢？”
用相同浏览器测试两个不同目标，确认是否只有一个站点慢。再核对该域名的路由是否走代理、DNS 是否返回合适地址。真连接只验证测试 URL，不能证明所有网站的解析与出口路径都正常。
“下载第一秒很快，随后一直下降？”
把测试延长到至少 15 秒，观察稳定阶段而非峰值。暂停其他传输后重测同一文件；仍持续回落时，再比较另一条节点。短时突发带宽、服务端限速与拥塞都可能产生这种曲线，仅看一轮不能确定原因。
对于主要使用 UDP 传输的配置，TCPing 失败也不能单独判定节点失效，因为相同地址与端口可能根本没有提供 TCP 服务。先确认节点的传输类型，再使用客户端支持的真连接测试或实际业务验证。
五、浏览网页与下载文件，选节点的顺序不同
网页通常包含多次小请求，更容易受到连接建立时间、解析时间与抖动影响；下载大文件更依赖稳定吞吐。不要给所有用途套同一张“延迟从小到大”排行榜，也不要用协议名称直接推断速度。
推荐方案：按实际任务设置主用与备用
网页、消息与接口请求
- 先确认真连接连续三次成功。
- 比较中位数，同时检查最高值是否明显偏离。
- 实际打开常用站点，观察首次加载与连续请求。
- 保留一条不同出口的备用节点，应对目标站点异常。
视频与大文件下载
- 先通过真连接检查，再做持续下载。
- 比较相同文件、相同时长下的平均速率。
- 在平时使用的晚间时段复测，避免只看空闲时段。
- 检查是否有卡顿或连接中断，而不是只记最高速度。
主用节点按实际任务选，备用节点按可用性留；更换网络后重新验证，不沿用旧排名。
v2rayN 桌面端也可以沿用这套判断顺序，但不同客户端的测试目标、并发数量、超时阈值和计时边界可能不同。手机上的 200 ms 与电脑上的 150 ms，不一定说明电脑所用节点更快。先统一测试条件，再比较结果。
六、保存一份能复查的测速记录
只截图一个绿色毫秒数，事后很难判断为何换网络后表现不同。记录无需复杂，但应包含接入网络、时间、测试入口与目标。下面的清单足够完成日常复查，也能帮助定位晚高峰拥塞和单一目标异常。
- 环境：填写 Wi-Fi 或移动数据、测试日期与时间，并注明是否正在充电、是否开启省电限制。
- 客户端：从「关于」记录实际版本号，注明是 v2rayNG 还是 v2rayN；升级后重新建立基准。
- 测试条件：记录测试 URL、下载目标、单次时长，以及分应用代理和路由模式是否改变。
- 结果：记录 TCPing、三次真连接原始值、失败次数和稳定阶段下载速率，统一使用同一种单位。
- 业务验证：补充常用网站是否能打开、视频是否连续播放，再决定是否设为主用。
最终选择顺序可以固定为：端口初筛 → 真连接验证 → 重复采样 → 按需下载测速 → 实际业务复查。这样既能减少无意义的批量下载，也能把“配置不通”“测试目标异常”和“吞吐不足”分开处理。
客户端安装与首次连接
按操作系统选择 v2rayNG 或 v2rayN；首次使用先完成导入与连接，再按本文顺序测试节点。