Tcping 用于初筛服务器端口，真连接延迟用于检查代理链路，下载测速用于观察持续吞吐。本文适合正在按延迟排序、却发现网页体验与排名不一致的用户。读完可以建立一套固定测试顺序，分辨节点故障、测试目标故障和本地网络干扰，而不是只按最小毫秒数选择节点。
三种测速：观察范围不同
先给结论：三种结果不应互相替代。Tcping 很低，不代表代理认证成功；真连接延迟很低，不代表大文件下载很快；下载速度很高，也不保证每次打开网页都响应迅速。它们分别观察连接建立、完整请求和持续传输，单位与边界都不同。
v2rayN 是图形客户端，测速任务由客户端协调，有些任务需要调用所选内核。Xray、V2Fly 的协议支持与配置字段并不完全相同。测速前应确认节点能被当前内核正确加载，不能用端口可达代替协议兼容性检查。
Tcping：端口初筛
尝试连接节点配置中的服务器地址与 TCP 端口。能快速筛掉明显无法建立 TCP 连接的条目，但通常不验证代理凭据与出口访问。
适合：订阅节点较多，先做低成本排查
真连接延迟：日常可用性检查
推荐借助节点代理链路向测试地址发起请求。对日常网页使用更有参考价值，但结果仍取决于测试目标、请求方式和客户端版本。
适合：从可达节点中挑选日常浏览候选
下载测速：持续吞吐检查
通过代理读取测试资源，在一定时间内统计传输量。它更接近持续下载场景，测试本身会消耗流量，也可能碰到服务端限速。
适合：少量候选节点的带宽复核
Tcping：建立连接，不验证完整代理
Tcping 不是普通 ICMP Ping。它通常以 TCP 连接建立所需时间作为结果，目标是节点的服务器地址和端口。例如节点配置使用端口 443，测试的是这个端口，而不是随意选择的网页端口。域名节点还需要先解析地址；解析时间是否计入显示值，取决于具体实现。
TCP 建连成功后，代理服务仍可能因为 UUID、密码、TLS 服务名或其他参数错误而拒绝连接。对于经过反向代理或内容分发网络的节点，Tcping 可能只证明前端入口可达，不能证明后端代理服务正常。入口离本地很近，也不意味着出口离目标网站很近。
- 有数值：说明测试当时能与目标 TCP 端口建立连接，不等于已经完成 VMess、VLESS 或 Trojan 的代理会话。
- 超时：可能是端口被过滤、地址失效、网络路径异常或服务器不响应。要结合日志与其他测试判断。
- 不适用：若实际传输不依赖该 TCP 入口，Tcping 不能覆盖真实传输路径，失败也不能直接推出节点不可用。
- 波动较大：先在同一网络下重复测试，不要把一次建连变慢当成稳定故障。
真连接延迟：测试目标也在链路里
真连接延迟更接近“通过这个节点完成一次指定请求需要多久”。路径通常包括本地连接代理入口、代理协议协商、节点出口访问测试目标，再把响应送回本地。视配置与实现，还可能涉及域名解析、TLS 握手、连接复用和重定向。它不是单独测量节点服务器的距离。
“真连接”也不意味着完整模拟一次网页加载。页面可能包含几十个域名、脚本和图片；延迟测试通常只是一个小请求。不同版本对完成条件的处理可能不同，例如关注响应头、指定状态或请求完成。因此比较结果时，应固定测试地址和客户端版本。
| 环节 | 可能的影响 | 排查动作 |
|---|---|---|
| 代理入口与认证 | 端口可达，但参数错误导致请求失败 | 检查节点参数及内核日志，不先修改 DNS |
| 测试域名解析 | 解析失败、地址族差异或解析路径变慢 | 记录 DNS 配置，确认实际使用的解析与出站路径 |
| 出口到测试目标 | 目标站限流、拒绝访问或线路绕行 | 用另一个小型测试目标复核，不同时更换节点与地址 |
| TLS 与连接状态 | 新建连接与复用连接的耗时不一致 | 按相同流程重测，记录首次与后续结果 |
测试地址若返回 204，一般意味着响应没有正文，适合小请求检查；但不能据此假定所有 v2rayN 版本都只接受这一状态。应使用客户端支持的地址与成功判定规则。系统代理开关也不是内置测速成功的充分条件：内置测试可能使用专门的测试配置，未必完全沿用日常路由。
下载测速：吞吐与延迟分开看
下载测速关心一段时间里读取了多少数据，而不是第一份响应多久到达。结果受本地接入带宽、无线网络、代理出口容量、服务端限速、拥塞控制、测试时长和并发方式共同影响。下载目标和真连接目标如果不同，两项排名不同是正常现象。
先看单位。MB/s 是每秒兆字节，Mbps 是每秒兆比特。按十进制单位换算，8 MB/s × 8 = 64 Mbps；实际应用还存在协议开销。下面的数字仅为讲解示例，并非本站实测，也不代表任何节点服务的表现。
这组结果并不矛盾：入口建连较快，但完整请求需要经过更多环节；一旦连接建立，仍然可能获得较好的持续吞吐。若示例节点 B 的真连接延迟为 180 ms、下载速度只有 2 MB/s，B 可能更适合小请求，A 则可能更适合持续传输。最终仍要在目标应用里复核。
判断：按用途筛选，不做单项总排名
浏览场景先比较真连接延迟的稳定性；下载场景再比较平均吞吐。只对留下的两三个候选进行下载测速，避免对整个订阅反复消耗流量。
固定测试流程：先初筛，再复核
在 v2rayN 的节点列表中选中节点，打开右键菜单，按测试项目执行。常见项目包含 Tcping 延迟、真连接延迟和服务器速度；不同桌面版本的具体文案可能有差异。测试参数可从「设置」→「参数设置」查找，具体分组以当前界面为准。先记录原值，不必为了测速复制陌生配置。
- 清理变量：暂停后台下载，固定同一条本地网络，记录客户端与内核版本、测试地址及时间段。不要同时比较无线网络和有线网络的结果。
- 初筛入口：运行 Tcping，保留可达条目。对不适合 TCP 初筛的传输方式，直接进行对应的代理请求测试。
- 复核可用性：对候选做三轮真连接测试，每轮间隔约
10 秒。记录失败次数，取成功结果的中位数，不只保留最好的一次。 - 限制下载范围：仅测试两三个候选，逐个运行。若界面提供测试时长设置，可统一为
15 秒；若没有，则保持默认并记录实际时长。 - 检查真实应用：选择候选节点后打开常用网站，确认实际出站与预期一致。测试成功而应用失败时，重点检查路由、系统代理或 TUN 接管情况。
例如三次真连接结果为 180、195、420 ms，中位数是 195 ms；若另一个节点为 160 ms、超时、超时，不能只凭成功的那一次认定它更好。超时属于可用性信息，应单独记录，不把它静默丢掉，也不随意换算成零。
测试方案：区分日常响应与持续传输
网页与小请求
- 使用固定的小型测试目标。
- 比较三轮中位数与失败次数。
- 在常用网站验证首次打开体验。
大文件与持续读取
- 使用同一个下载目标。
- 固定测试时长和并发方式。
- 观察平均速度，区分瞬时峰值。
两种方案都应逐个测试节点；并行测速会竞争本地带宽，使结果难以比较。
异常结果：先定位失败发生在哪一层
延迟栏显示负值、空白或超时，通常是失败标记，而不是“负延迟”。具体含义取决于客户端版本，应结合日志确认。排查时每次只改一个条件，否则无法判断是换节点、换测试地址还是改 DNS 起了作用。
Tcping 有数值，真连接却一直超时？
先确认当前内核能启动并加载该节点，再检查认证参数、TLS 服务名和客户端日志。若日志显示目标访问失败，保持节点不变，换一个客户端支持的小型测试地址复核。不要因为端口可达就排除节点配置错误。
真连接成功，浏览器还是打不开？
确认浏览器流量是否进入 v2rayN。检查系统代理或 TUN 模式，并查看日志中实际目标与出站。内置测试可能使用专门的代理路径，浏览器却因路由规则走直连；两者不能自动画等号。
延迟很低，下载为什么只有几百 KB/s？
暂停其他下载，逐个测试候选，并用第二个下载目标交叉验证。若只有一个目标慢，优先考虑目标服务或出口到该目标的路径；若所有节点都慢，再检查本地网络与测试设置。
晚上测速变慢，是否需要重装客户端？
先用相同节点、地址和测试时长，在不同时间段各测三轮。若多个候选都只在晚间出现吞吐下降，更可能涉及共享带宽或链路拥塞。保留记录，再判断是否需要调整节点或网络。
能把桌面结果直接用于 Android 吗？
可以用作候选清单，但仍需在目标设备重测。v2rayNG 使用 Xray 内核，v2flyNG 使用 V2Fly 内核；设备性能、无线网络和测试实现都可能不同。应先确认节点协议兼容，再比较同一网络条件下的体验。
保存测试记录：让下一次比较有依据
节点名称相同，不代表入口、出口或后台线路始终不变。订阅更新后，应对常用候选重新做简短复核。日常记录不需要保存订阅地址或认证凭据，只保留测试条件与结果即可。
- 环境：操作系统、v2rayN 与内核版本、本地网络类型、测试日期和时间。
- 条件：测试目标、时长、是否逐个测试，以及当时采用的代理与路由设置。
- 结果：Tcping、三次真连接数值与失败次数、平均下载速度及单位。
- 应用反馈：常用网站是否可访问，持续传输是否稳定，实际出站是否符合预期。
需要进一步检查流量路径时，可阅读DNS 设置说明与TUN 模式说明。如果问题出现在订阅更新而非测速过程，应转到订阅更新排查。先分清故障所在的环节，再决定修改哪项设置。