TCPing 用于筛查节点入口是否可建立 TCP 连接；真连接延迟用于验证代理链路能否访问指定测试目标；下载测速用于观察持续传输能力。本文面向使用 v2rayN、v2rayNG 或 v2flyNG 的用户，按测试范围、菜单操作、结果记录与故障定位依次说明，给出一套先筛连通性、再比响应、最后测吞吐的选节点流程。
三种测速分别覆盖哪一段链路
客户端列表中的毫秒值，只有在测试方法一致时才适合比较。一次 TCP 连接成功，并不代表 VMess 或 VLESS 身份验证成功；一次测试页面响应迅速，也不代表大文件能持续高速传输。先确认菜单执行的是哪种测试，再读结果列。
TCPing：检查入口连接
向节点地址和端口发起 TCP 连接，通常统计连接建立所需时间。它不同于系统 ping 使用的 ICMP，也不会完整验证代理协议、账户参数与节点出口。
适合：批量排除入口端口无法连接的配置，缩小后续测试范围。
真连接延迟：检查代理请求
推荐通过被测配置和内核向指定目标发出请求。耗时可能包含连接节点、代理握手、目标解析与目标响应；具体计时边界取决于客户端实现，不能简单等同于网络往返时延。
适合：日常筛选网页访问节点，确认协议参数与请求链路可用。
下载测速：检查持续吞吐
经被测配置下载测试内容，按传输字节数与耗时计算速度。结果受到下载源、线路拥塞、服务端限速、测试时长及设备处理能力共同影响。
适合：在少量可用节点之间比较大文件传输能力。
例如节点入口使用 TCP 443 端口，TCPing 成功只说明该地址的 443 端口当时可建立连接。即使 UUID 填错、WebSocket 路径不匹配，入口仍可能返回一个很低的毫秒值。对基于非 TCP 传输的配置，也不能只凭 TCPing 失败判断整个配置不可用。
v2rayN 与安卓客户端的测速操作
先更新订阅，再挑选少量配置测试。不同版本和界面的菜单文字可能略有差别，下面按常见中文界面描述；以实际出现的“Tcping”“真连接延迟”“速度”等动作名称为准，不把所有客户端都视为提供同一套测速功能。
- v2rayN：选中配置。进入服务器列表，按住 Ctrl 选择 3～5 个节点。右键打开菜单，先执行“测试服务器延迟 Tcping”，查看延迟结果；再对同一批节点执行“测试服务器真连接延迟”，等待整轮结束。
- v2rayN：比较速度。保留真连接测试成功的 2～3 个候选，右键执行“测试服务器速度”。不要在此时运行其他大流量任务，也不要把几百个节点同时送入下载测试。
- v2rayN：统一测试参数。打开“设置”→“参数设置”，在当前版本提供的测速相关项中核对延迟测试地址、下载测试地址和超时时间。若未提供其中某项，记录该版本默认行为，不必为寻找选项而修改节点协议。
- v2rayNG：批量测真连接。在配置列表右上角打开菜单，选择“测试全部配置真连接”。需要验证当前节点时，先选择该配置、启动服务并完成 Android 的 VPN 授权，再点击底部连接状态区域执行当前连接测试。
- v2flyNG：按实际菜单执行。在配置列表菜单中查找当前版本提供的连接测试操作，并记录测试类型。测试前确认配置属于其 V2Fly 内核支持的范围；依赖 Xray 特性的 VLESS + REALITY 配置应使用支持它的客户端与内核。
用同一组条件比较延迟与波动
下面是一组用于说明计算方法的假设记录，不是节点实测排名。假定在同一设备、同一 Wi-Fi、同一测试目标下，逐个测量节点 A 五次。TCPing 的结果为 31、34、35、37、52 毫秒；真连接结果为 168、175、182、194、620 毫秒。
把五个结果从小到大排列，第三个就是中位数。它比单次最低值更适合作为这一小组测试的典型值，但五次样本仍不足以描述长期稳定性。620 毫秒提示这轮出现了明显波动，应补测，而不是直接把该节点判为长期不稳定。
| 记录项目 | 节点 A | 节点 B | 判断方式 |
|---|---|---|---|
| TCPing 中位数 | 35 ms | 68 ms | 仅比较入口建立连接 |
| 真连接中位数 | 182 ms | 146 ms | B 对该测试目标响应更快 |
| 真连接成功次数 | 5 / 5 | 5 / 5 | 本轮均完成请求 |
| 下载平均速度 | 8 MB/s | 5 MB/s | A 对该下载源吞吐更高 |
结论：按实际任务保留两个候选
在这组假设结果中，网页交互可先试节点 B，大文件传输可先试节点 A。分别打开目标网站验证，再在常用时段复测；不要把入口延迟最低的节点自动设为所有用途的首选。
测试超时应单独记录，例如“4 次成功、1 次超时”，不能把超时当作 0 毫秒，也不宜只平均成功结果后隐藏失败次数。应用层超时可能来自解析、握手或目标响应，不能直接换算成底层网络丢包率。
下载速度的单位、时长与流量成本
宽带标称通常使用 Mbps，客户端常显示 MB/s 或 MiB/s。按十进制单位换算，8 MB/s 约等于 64 Mbps；若显示 8 MiB/s，则约为 67.1 Mbps。比较两个工具前先看单位，不能把数值相同当作速度相同。
- 固定测试源。同一节点对不同下载源可能获得完全不同的结果。源站的并发限制、内容缓存与节点出口到源站的线路都会改变吞吐。
- 固定测试时长。若工具允许配置，可统一观察 10～15 秒，并记录平均值与后半程表现。只看启动瞬间的峰值，容易把短时缓存或突发带宽误认为持续速度。
- 估算流量。以 8 MB/s 持续下载 15 秒，单节点内容流量约 120 MB；连续测试 5 个节点约 600 MB，实际还可能包含额外协议开销。
- 控制并发。逐个测试有利于比较单节点能力。多个节点同时下载会争用本地接入带宽，测到的是共享带宽下的竞争结果。
低延迟却打不开网页：按失败位置排查
先保留失败发生时的日志，再改变一个设置重试。一次同时更换 DNS、路由模式、传输协议与测试目标，会让成功或失败都难以归因。日志中若包含服务器地址、账户标识或订阅信息，分享前应遮挡相关字段。
TCPing 只有 30 毫秒，为什么真连接总超时？
打开该节点的编辑窗口，对照提供方参数核对地址、端口、UUID、传输类型与安全选项。WebSocket 配置继续核对路径和 Host；TLS 配置核对服务器名称。入口可达不代表这些参数正确，不要用关闭证书验证来掩盖配置错误。
真连接成功了，浏览器怎么还是打不开？
先确认当前活动节点就是被测节点。桌面端核对系统代理或 TUN 是否按预期启用，浏览器是否另设代理；安卓端确认 VPN 服务已启动、目标应用没有被分应用规则排除。随后访问实际目标并查看日志中的出站与错误信息。
所有节点一起显示超时，是订阅失效了吗？
先确认本地网络可用，再检查内核是否正常启动及日志中的错误。若所有节点都只对同一测试目标失败，可在“设置”→“参数设置”提供的测速项中换成另一个可控目标复测。测试目标异常与账户失效应分别验证。
测速很快，晚上下载却很慢，应该换协议吗？
先在晚间用同一下载源、同一测试时长复测，并暂停其他下载。如果多个节点同时变慢，继续检查本地网络与共享带宽；若仅某个节点变慢，再比较其他节点。更换 VMess 或 VLESS 不能自动解决出口拥塞或服务端限速。
对于“仅部分域名失败”，再检查 DNS 与路由。测试工具可能对每个候选配置创建独立测试出站，而浏览器流量仍遵循当前路由规则；两者不一定经过完全相同的路径。需要结合路由分流说明和DNS 设置说明，确认目标请求实际走向。
建立一套可重复的节点筛选流程
把初次筛选和日常复测分开。初次筛选的目标是找到少量可用配置；日常复测的目标是确认这些配置在实际使用时段仍然合适。不要为了追逐更低的一个毫秒值，反复对整份订阅执行高流量测试。
测试方案：初次筛选与日常复测
初次导入后
- 更新订阅，确认配置字段完整。
- 用 TCPing 辅助筛查适用的 TCP 入口。
- 选择 3～5 个候选，各做 5 次真连接测试。
- 对其中 2 个候选逐个做短时下载测试。
日常使用前
- 固定设备、网络与测试目标。
- 记录成功次数、中位数和明显波动。
- 在常用晚间时段补测同一组节点。
- 打开实际网站或文件，确认业务可用。
先确认请求成功，再比较响应时间；只有需要持续传输时，才增加下载测速。
记录时至少保留测试时间、接入网络、客户端名称、内核、测试类型与目标。v2rayNG 使用 Xray 内核，v2flyNG 使用 V2Fly 内核；v2rayN 的内核选择也应一并记录。对比协议或内核时，若节点出口、目标和测试时段都变了，就不能把全部差异归因于内核。
- 先判断成功率。频繁失败的节点即使偶尔出现低延迟，也不适合直接作为主用。
- 再判断响应与波动。结合多次真连接结果，选择与实际访问目标匹配的候选。
- 最后判断吞吐。按实际下载需求比较持续速度，同时保留一个经过验证的备用配置。