TCPing 用来初筛服务器端口，真连接延迟用来检查节点能否完成代理请求，下载测速用来观察持续传输能力。本文适合遇到“延迟很低却打不开网页”或“延迟高但下载快”的 v2rayN 用户：先统一测试条件，再分层排查，最后按实际用途选择节点。
三种测速分别测了哪一段连接
一次网页访问并不只有“连接服务器”这一步。本机需要访问节点入口，代理内核完成协议认证与传输协商，节点再连接目标网站，随后才有响应数据返回。TCPing、真连接延迟和下载测速截取的环节不同，数值不能放在同一列直接排名。
| 测试方式 | 主要测量对象 | 能说明什么 | 不能直接说明什么 |
|---|---|---|---|
| TCPing | 本机到节点地址、端口的 TCP 建连 | 入口端口是否可达，建连耗时大致多少 | UUID 是否正确，代理能否访问网站 |
| 真连接延迟 | 通过被测节点向测试 URL 发起请求 | 代理链路与该测试目标是否可用 | 所有网站的响应速度，大文件吞吐 |
| 下载测速 | 经节点从测速地址持续接收数据 | 该时段、该目标的传输速率 | 长期最低带宽，游戏延迟，所有应用体验 |
真连接测试常使用体积很小的 HTTP 响应，例如返回状态码 204 的地址。它是在执行一次实际代理请求，不是在加载整张网页；计时终点、连接复用和超时处理取决于客户端及内核实现。因此，不能把它简单解释成“浏览器页面完全打开需要多久”。
TCPing 很低，为什么节点仍然不能用
TCPing 通常尝试连接节点配置中的服务器地址与端口。若节点使用域名，还需要先获得地址；域名解析是否纳入显示耗时取决于实现。它不是 ICMP Ping，也不要求服务器回应 ICMP。即使服务器禁用了普通 Ping，TCP 端口仍可能正常建立连接。
例如，入口为 TCP 443 端口的 VLESS 节点，TCPing 显示 45 ms，只能表明入口接受了 TCP 连接。后续的 TLS 或 REALITY 协商、VLESS 认证，以及节点到目标网站的出站连接，都还没有被这个数字证明。
- 认证错误：VMess 或 VLESS 的 UUID 不匹配，TCP 仍可能连通，但代理请求会失败。
- 传输参数错误：WebSocket 的路径、Host 或 TLS 的
serverName不匹配，可能在 TCP 建连之后才暴露问题。 - 安全层参数错误：REALITY 的公钥、
shortId或相关配置不匹配，需要从内核日志核对，而不是继续刷新 TCPing。 - 测到的是入口：使用 CDN 的节点可能先连接到较近的边缘入口，入口延迟低不代表回源和后续出站也快。
真连接延迟：先判断请求成功，再比较毫秒数
真连接测试会让测试请求通过被测节点。它通常涉及本机到节点的连接、代理协议处理、节点到测试目标的连接，以及响应返回。使用 HTTPS 测试地址时，还会涉及到目标的 TLS 握手；具体耗时会受到 DNS 缓存、连接复用和测试机制影响。
因此，TCPing 为 45 ms、真连接为 260 ms 并不矛盾。两个数字之间的差额不是一个可以精确拆出的“服务器处理延迟”，不能简单相减后就归因于节点负载。测试目标的位置、节点出口路线和握手次数都可能参与其中。
TCPing 初筛
先检查入口连通性，快速定位整批节点是否存在明显的网络或端口问题。不要仅按最低毫秒数确定日常主力节点。
适合：节点较多、需要快速排查入口故障
真连接延迟筛选
推荐在同一个测试 URL 下重复测量，优先保留请求稳定成功、延迟波动较小的节点，再用实际网站复核。
适合：网页浏览、接口请求、日常节点选择
下载测速复核
对少量候选节点测试持续接收数据的能力。结合流量消耗与实际用途，不必对整份订阅反复进行满速测试。
适合：大文件传输、视频缓冲能力评估
真连接超时也不等于节点整体失效。测试地址自身不可达、目标限制某类出口、DNS 解析失败，都可能导致失败。先保留原地址的记录，再换一个稳定的小响应地址复测；不要在每轮比较中随意更换目标，否则排名没有一致的参照。
下载测速：MB/s、Mbps 与突发峰值怎样看
下载测速观察的是一定时间内接收到的数据量。瓶颈可能位于家庭宽带、无线网络、节点共享带宽、出口链路，也可能位于测速文件服务器。它描述的是整条路径的结果，不是单独给节点服务器做性能测试。
先看单位。十进制口径下，1 MB/s 等于 8 Mbps；宽带套餐常用 Mbps，应用下载界面可能使用 MB/s 或 MiB/s。下面是一组教学用示例记录，并非本站实测或任何节点的性能承诺，用于说明三个指标可以同时成立。
- 低延迟、低吞吐：短请求响应快，但长连接可能受到限速或共享带宽影响。
- 高延迟、高吞吐：远距离链路往返时间较长，建立连接后仍可能维持较高传输速率。
- 开头快、随后变慢：可能与突发带宽、拥塞、服务端策略有关，应观察稳定区间，不只记录瞬时峰值。
假设平均速率为 8 MB/s，持续测试 15 秒，接收数据约为 120 MB，尚未计入协议开销。测试多个节点会累计消耗流量。尤其是按量计费的订阅，先用真连接缩小范围，再对两三个候选节点测速更合适。
在 v2rayN 中建立可重复的测试流程
以下按节点列表的操作逻辑说明。不同版本的右键菜单可能写作“测试服务器延迟 Tcping”“测试服务器真连接延迟”或相近名称，设置项分组也可能调整；应以当前界面为准。测试前记录客户端与内核版本，升级前后的结果不要直接混成同一批数据。
- 固定网络条件：暂停其他下载、云同步和系统更新。先选定有线或同一 Wi-Fi 网络，测试过程中不要切换网络。
- 核对测试设置：打开「设置」→「参数设置」，查看当前版本提供的延迟测试地址、测速地址、超时和并发相关设置。记录实际取值；若设置位于独立测速分组，进入对应分组查看。
- 小批量初筛：在节点列表选中待测节点，右键运行 TCPing。再对同一批节点运行真连接测试，分开记录结果，不把两个延迟字段互相替代。
- 重复三轮：在同一测试目标下分别记录成功次数和延迟。示例三次结果为 180、185、620 ms，其中位数为 185 ms，但 620 ms 的波动也要保留。
- 单独测吞吐：仅对候选节点逐个运行下载测速。记录测试时段、持续时间和平均速率，避免多个下载任务争用本机带宽。
- 回到真实用途：设为活动节点后，打开实际使用的网站或业务。内置测试成功不代表系统代理、应用代理和路由配置已经正确。
两轮验证：区分节点质量与使用环境
受控测速环境
- 固定测试 URL、网络与测试时长。
- 先小批量延迟测试，再逐个下载测试。
- 记录三轮结果，不只截取最低值。
日常应用环境
- 恢复日常使用的系统代理与路由设置。
- 检查目标应用是否确实经过所选节点。
- 在常用时段复测网页、视频或下载任务。
受控测试用于比较节点，日常验证用于确认配置与实际体验，两者不能互相替代。
内置测试成功，浏览器仍然慢：核对代理路径
v2rayN 的节点测试与浏览器访问未必沿着完全相同的配置路径。节点测试通常为被测节点安排测试连接，而日常应用还受系统代理、应用自身代理设置、routing 规则和 DNS 行为影响。某个网站被规则分到直连后，切换节点也可能不改变其访问速度。
需要独立复核时，可以显式指定本地 SOCKS 入口。以下命令假设已经确认 127.0.0.1:10808 是当前可用的 SOCKS 或兼容混合入站，并已在界面选择目标节点；10808 只是本例端口，不保证适用于所有安装。若本地监听不同，先修改命令中的地址。
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 --output /dev/null --silent --show-error --write-out "HTTP=%{http_code} total=%{time_total}s\n" https://www.example.com/- 此命令适用于具备
curl的 Linux、macOS 终端。Windows PowerShell 可使用curl.exe，并将输出目标/dev/null替换为NUL。 socks5h表示把目标域名交给 SOCKS 代理端处理，能减少本地目标域名解析差异；后续实际解析位置仍由内核和路由配置决定。time_total是这次命令从开始到传输结束的总耗时，不等同于 v2rayN 真连接延迟字段，也不是单独的服务器处理时间。- 示例目标仅用于检查请求。固定使用同一稳定目标才能比较结果；不要用小页面响应去推算大文件下载带宽。
显式指定代理入口可以绕开系统代理是否生效这一层疑问，但不会自动绕过内核的 routing。如果仍怀疑请求走向，应在访问时对照日志中的目标、匹配规则与出站标签。分享日志前遮去订阅地址、认证信息和其他敏感内容。
测速常见问题：按症状缩小排查范围
TCPing 只有几十毫秒，真连接却超时，要换节点吗？
先在节点列表重做一次真连接测试，再查看对应时刻的内核日志。若出现认证或握手错误，核对 UUID、TLS、REALITY 和传输参数；若仅测试地址失败，换一个稳定目标复测后再判断。
所有节点同一时间测不出来，是订阅失效了吗？
先把测试范围缩到一个已知可用节点，并降低并发。检查本机网络、测试 URL 和内核是否正常启动；确认原因前不要反复删除并重新导入整份订阅。
下载速度很高，为什么打开网页还是慢？
大文件传输和多次短连接不是同一种负载。先观察真连接的多轮波动，再检查浏览器 DNS、路由以及网站第三方资源。用同一页面复测，避免拿不同站点的加载时间比较节点。
显示 -1 或超时，是延迟特别高的意思吗？
通常应把这类结果理解为测试未成功，而不是负数延迟。核对超时设置和日志，再单独重测；不同版本的失败显示不同，应结合状态文本判断，不能与正常毫秒数一起求平均。
应该一直选延迟最低的节点吗？
先比较成功率与波动，再看用途。浏览网页可优先保留真连接稳定的节点；大文件传输再比较持续吞吐。至少在常用时段复测一次，保留一个已验证可用的备用节点。
选节点的实用顺序是：请求能成功、结果较稳定、实际业务可用，最后才是单项数字更低或更高。将测试目标、网络、时段和单位写进记录，才有条件判断一次变慢来自节点、目标服务器，还是本机环境。