TCPing 用来初筛服务器端口是否可达，真连接延迟用于验证代理链路能否完成一次目标请求，下载测速观察持续传输能力。适合已经导入订阅、但不知道该按哪列排序的用户。按本文顺序测试，可以把“端口通”“代理可用”和“下载够快”分开判断，避免选中延迟最低却无法正常使用的节点。
三种测速测的不是同一段链路
节点列表里的毫秒数不是统一标准。TCPing 通常只向节点地址和端口建立 TCP 连接；真连接测试会调用代理内核，通过指定节点访问测试地址；下载测速则继续接收响应数据，计算一段时间内的吞吐量。三者的终点、请求量和计时范围不同，不能直接比较大小。
这条流程描述的是一次经代理访问目标服务的逻辑过程。若节点使用额外的传输层或中转，入口到代理服务之间还可能有其他环节。TCPing 往往只覆盖流程前部；真连接和下载测试才会继续检验后面的路径。
| 测试方式 | 主要回答 | 不能据此确认 |
|---|---|---|
| TCPing | 节点入口的 TCP 端口能否建立连接 | 代理认证、目标网站访问、持续速度 |
| 真连接延迟 | 指定代理路径能否完成测试请求 | 所有网站可用、长时间下载稳定 |
| 下载测速 | 到测速资源的有效传输速率 | 网页首屏快、其他时段也有相同速度 |
TCPing 很低，为什么节点仍然不可用
以服务器端口 443 为例，TCPing 显示 38 ms，通常表示本机可以较快地与该地址的 TCP 监听端口建立连接。它并没有提交 VMess 或 VLESS 所需的认证信息，也没有验证 TLS 参数、WebSocket 路径或节点出口能否访问目标站点。
- 认证信息不匹配：服务端仍可接受 TCP 连接，但随后拒绝代理请求。继续刷 TCPing 不会定位到认证字段错误。
- 传输参数不匹配：端口可达，但 TLS 的服务器名称、传输路径等参数错误，应用层连接仍会失败。
- 入口不等于最终服务器：若地址前面有中转或 CDN，较低的数值可能主要反映到入口的距离。
- 协议并非只依赖 TCP：TCPing 不能代替对实际 UDP 业务的测试；不要用它推断所有协议都可用。
反过来，TCPing 超时也要结合测试实现和网络环境判断。先确认客户端测的是当前节点地址与正确端口，再查看真连接结果。若二者都失败，才继续排查本地网络、入口端口、节点状态和订阅参数，而不是仅凭一项结果认定服务器宕机。
真连接延迟更接近可用性，但要看测试目标
真连接测试通常通过内核为待测节点建立代理路径，再请求配置中的测试 URL。计时可能涉及域名解析、代理握手、目标站 TLS 握手和响应等待；具体起止点由客户端与内核实现决定。它不是一个可以固定拆成“TCPing 加几次往返”的数值。
部分测试地址返回很小的响应，甚至使用 204 状态码作为成功信号。这样的请求适合判断响应速度，却没有持续传输足够的数据，因此不能据此推算下载带宽。DNS 缓存、连接复用和测试资源所在区域，也会影响重复测试的结果。
真连接测试记录
- 目标地址
- 固定同一个 HTTPS 测试 URL
- 测试轮数
- 每个节点 5 次
- 间隔
- 每次至少间隔 3 秒
- 记录项目
- 中位数、最慢值、失败次数
先保持目标与测试方式一致，再比较不同节点。
下载测速记录
- 下载资源
- 固定同一个测速文件
- 测试时长
- 例如每次 10 秒
- 并行任务
- 同一时刻只测 1 个节点
- 记录项目
- 平均速度、波动、实际流量
资源须足够大，避免过早下载完而无法观察持续速率。
测试目标本身不可达时，多个正常节点也可能同时显示超时。此时先保留原配置，换一个已知可访问的小型 HTTPS 目标做对照；再恢复原地址重测。如果只有某个目标失败，应检查该目标的访问限制和节点出口路径，不宜立刻删除整个订阅。
下载测速看吞吐量，先分清 MB/s 与 Mbps
下载速度取决于整条路径中较慢的环节，包括本地宽带、无线信号、节点入口、服务器出口、目标资源限速以及测试并发数。节点入口距离近，只能帮助降低部分往返时间，不等于出口带宽充足。高延迟节点也可能在连接建立后维持较高吞吐量。
注意单位：1 MB/s = 8 Mbps，这里按十进制单位换算。标称 100 Mbps 的接入带宽，理论换算约为 12.5 MB/s；实际应用还受到协议开销和共享网络影响。若界面使用 MiB/s，应按二进制字节单位另行换算，不能把所有带有字母 M 的值放在一起排序。
| 显示数值 | 十进制换算 | 阅读方式 |
|---|---|---|
| 5 MB/s | 40 Mbps | 每秒约传输 5 MB 数据 |
| 10 MB/s | 80 Mbps | 不能误读成只有 10 Mbps |
| 100 Mbps | 12.5 MB/s | 理论换算值，不是测速保证值 |
在 v2rayN 中按固定顺序比较节点
以下以 Windows 上 v2rayN 的常见桌面界面为例。不同版本和界面分支的菜单文字可能略有不同，应按“Tcping”“真连接延迟”“速度”识别测试项目。测试参数通常在「设置」→「参数设置」内的测速相关设置中；先记录当前测试 URL、超时和下载时长，再开始对照。
- 更新并核对列表：更新对应订阅分组，确认待测节点属于同一轮列表。订阅更新成功只代表配置获取成功，不代表每个节点已经通过连通性测试。
- 固定本地条件：暂停其他下载与云同步，保持同一网络接入方式。不要让一个节点在有线网络下测，另一个节点在拥挤的无线网络下测。
- 先测入口：在服务器列表选中候选行，右键选择 Tcping 对应测试项。保留结果，供判断入口连通性使用，不要立即按最低值确定最终节点。
- 再测真连接：右键选择真连接延迟对应测试项。建议采用前文的 5 次记录法；若当前版本提供测试并发设置，比较时设为 1，减少任务互相影响。
- 少量测下载：只对真连接稳定的两三个节点执行速度测试。记录平均速率，不把启动瞬间的峰值当作持续带宽。
- 回到实际应用验证：把候选项设为活动服务器，检查「系统代理」菜单中的当前状态，并确认浏览器是否使用系统代理。打开实际使用的页面，再完成一次真实下载。
内置测试可能使用专门生成的测试配置，并不等同于浏览器当前的完整访问路径。如果内置真连接成功，而浏览器失败，应进一步检查系统代理、应用自身代理、路由规则和 DNS。若应用手工指定了本地代理，例如 127.0.0.1:10808，必须与「设置」→「参数设置」中实际监听端口一致；这里的端口只是示例，不是所有安装的固定值。
用一组示例读懂“延迟低但下载慢”
下面是一组用于说明判断方法的假设数据，不是本站实测，也不是任何服务的性能承诺。假设在同一网络、同一时段、同一测试目标下，节点 A 的 TCPing 为 32 ms、真连接中位数为 460 ms、下载平均为 2 MB/s；节点 B 的结果如下。
A 到入口更快，但经过代理访问测试目标时反而更慢，说明入口之后的路径或处理过程值得继续检查。不能只凭这三项就断言服务器 CPU 不足或线路拥塞；需要结合日志、不同目标和不同时段重测。就这组示例而言，B 更值得进入实际应用验证阶段。
判断：先剔除不稳定项，再按用途排序
网页使用优先比较真连接成功率与响应波动，大文件传输再比较持续下载速度。即使某节点偶尔出现最低毫秒数，只要重复测试频繁失败，也不宜排在稳定候选项之前。
同样要防止平均值掩盖异常。五次结果为 180、190、185、900、超时，与五次都在 220 ms 左右的体验并不相同。记录超时次数和慢请求，比只看刷新后留下的最后一个数字更有用。晚间集中使用时再复测一次，能发现白天测试没有暴露的问题。
常见测速疑问与下一步操作
TCPing 有数值，真连接全是超时，要先改哪里？
先核对测试 URL 和超时设置，再查看内核运行日志。若出现 TLS 或认证相关报错，检查订阅是否为最新、系统时间是否准确，以及传输参数是否被手工修改。端口已通时，反复更换本地监听端口通常不能修复远端握手错误。
真连接成功，浏览器却打不开，是节点坏了吗？
先确认活动服务器，再检查「系统代理」状态和浏览器代理设置。手动配置代理的应用还要核对本地地址与端口。若只有部分域名失败，检查路由是否将它们送往直连，以及 DNS 是否返回了异常地址，不要把单个目标失败当作整个节点失效。
下载能跑满，网页还是要等很久，为什么？
持续传输快不代表建连快。网页会访问多个域名，并经历多次解析、握手和响应等待。先看真连接的波动，再用浏览器网络面板区分 DNS、连接、TLS 和等待响应耗时；必要时更换目标对照，排除网站本身处理慢。
桌面与安卓测出来不同，哪个结果才算准？
先让两台设备使用同一个网络、同一节点、同一测试目标和相近时间，再比较。v2rayN 是桌面客户端，v2rayNG 使用 Xray 内核，v2flyNG 使用 v2fly 内核；具体测试实现和设置可能不同。每个结果首先描述的是本机当时的访问条件，不宜跨设备直接排名。
最终保留一份简短记录即可：测试时间、网络接入方式、节点名称、真连接成功次数、延迟中位数、下载平均值。涉及订阅地址和认证信息的内容不应放进公开截图。需要进一步排查时，可从问题诊断按“连接失败”或“部分网站不可用”继续定位。