Tcping 适合筛查服务器端口是否能建立 TCP 连接，真连接延迟用于检查经代理访问测试目标的请求能否完成，下载测速观察持续传输吞吐。本文适合遇到“有延迟却打不开网页”或“延迟低但下载慢”的桌面用户，按测试范围、配置检查和结果组合给出排查顺序，避免只凭一个毫秒数选择节点。
Tcping、真连接延迟与下载测速分别测什么
v2rayN 是管理配置、调用代理内核的桌面客户端。节点列表中的测试结果来自不同测量流程，不是同一条线路的三种显示单位。先认清测量边界，才能知道一次成功排除了哪些问题，以及哪些问题仍然没有检查到。
| 测试项目 | 主要测量对象 | 不能直接证明 |
|---|---|---|
| Tcping | 本机到节点地址、端口的 TCP 建连耗时 | 代理认证正确、目标网站可访问 |
| 真连接延迟 | 经被测代理访问指定测试 URL 的请求耗时 | 所有网站可用、持续下载速度高 |
| 下载测速 | 经被测代理读取测速资源时的传输速率 | 交互响应快、所有下载源都同速 |
测速结果还取决于客户端版本、内核、测试 URL、超时和并发设置。真连接延迟通常包含代理连接、必要的握手以及目标响应等待，但具体计时起止点、连接复用方式由实现决定。不能把它当成精确到单一网络往返的测量，更不能直接用它减去 Tcping 来计算服务器处理时间。
Tcping 正常为什么仍然无法上网
Tcping 不等于命令行的 ICMP ping。服务器不回应 ICMP，不代表代理端口不可用；反过来，TCP 建连成功也只说明对应地址和端口接受了连接。端口后面的服务是否理解 VMess 或 VLESS、用户标识是否有效、传输参数是否匹配，都还没有被验证。
对常见的基于 TCP 的连接，Tcping 主要覆盖流程前部。后续 TLS 握手失败、WebSocket 路径错误、REALITY 公钥或服务名不匹配，都可能表现为“Tcping 有数值，真连接超时”。同一地址背后若有反向代理或中转，TCP 成功甚至可能只到达入口，尚未验证后面的代理服务。
- 认证参数：核对订阅是否更新，用户标识、密码等内容是否被手动改动；不要用另一个节点的字段拼接当前配置。
- 传输参数：检查 WebSocket 路径、Host、TLS 服务名以及 REALITY 相关字段，保留服务端要求的组合。
- 系统时间：开启系统时间同步。明显的时间偏差可能影响证书有效期判断，也可能影响带时间校验的协议认证。
- 服务端出站：即使入口能接受连接，服务端 DNS 或访问目标网站的网络异常，仍会导致真连接失败。
遇到这种组合时，应优先查看内核日志中的握手、认证与解析错误，再检查配置。反复点击 Tcping 不会验证新环节，也不能修复协议参数错误。涉及证书或认证失败时，不建议通过跳过证书验证来掩盖原因。
真连接延迟：测试目标与实际浏览要分开判断
真连接延迟比 Tcping 更接近日常请求，因为测试需要启动或调用代理内核，并经被测节点请求指定地址。它适合判断“这个配置是否能完成一条代理请求”，但仍然只是一条特定请求，而不是完整的浏览器访问过程。
真连接测试条件
- 配置入口
- 「设置」→「参数设置」内的测速相关选项
- 目标地址
- 记录界面中实际配置的延迟测试 URL
- 控制变量
- 测试期间不切换 URL、网络或超时参数
各版字段名称与位置可能不同，以当前界面中的测试地址和超时设置为准。
浏览器访问条件
- 应用接入
- 确认浏览器使用系统代理或明确配置的本地代理
- 节点选择
- 确认当前活动节点就是刚才测试的节点
- 路由判断
- 从日志确认实际网站走代理还是直连
内置测试可自行调用被测代理，不以系统代理已经开启为前提。
因此，真连接成功而浏览器失败并不矛盾。浏览器可能没有接入代理，也可能通过扩展使用了另一套代理配置；网站域名可能命中直连规则，而测试 URL 走了代理。应在浏览器发起请求的同时观察日志，确认请求有没有进入内核，以及匹配了哪个出站。
反过来，浏览器能打开常用网站而真连接失败，也可能是测试站点不可达、返回内容不符合测试实现的预期，或超时过短。先用同一个节点访问测试目标，再换一个已确认可用的轻量目标复测。更换目标是验证测试条件，不应把更容易得到低数字作为选择标准。
- 在节点列表选中少量待测项，通过右键菜单找到名称含“真连接延迟”的测试项。
- 等待本轮完成，记录成功或失败，以及当前测试目标；菜单措辞以所用版本为准。
- 将其中一个成功的节点设为活动节点，再用浏览器访问实际需要的网站。
- 若结果不一致，检查系统代理、本地监听端口、浏览器代理设置与路由日志。
下载测速：吞吐、单位与资源消耗
下载测速观察的是一段时间内接收数据的能力。链路带宽、服务器负载、丢包、拥塞控制、测速文件所在站点和测试持续时间，都会影响结果。低延迟有利于交互响应，却不保证持续传输吞吐高；带宽较大的远距离线路，也未必能得到最低的真连接延迟。
- 先看单位：
MB/s与Mbps不是同一单位。按十进制字节单位换算，1 MB/s 对应 8 Mbps；若界面使用 MiB/s，则需按二进制字节单位另算。 - 避免同时抢带宽：暂停大文件下载、云同步和其他节点的测速，否则测到的是共享出口竞争后的结果。
- 先小范围复测：从真连接成功的节点中选少量候选项，不要一开始就对整份订阅执行下载测速。
- 确认消耗：测速会产生实际下载流量，也可能被系统或服务端计入流量额度，重复执行不是没有成本的检查。
短时间下载容易受到连接建立和传输爬升影响，长时间下载又更容易遇到负载变化。若测试出现很高的瞬时峰值但随后明显回落，应看稳定阶段而不是只记最高值。不同测速资源可能位于不同网络，测试源本身限速时，也无法据此断言节点出口带宽不足。
端口与测试顺序：先确认可用，再比较快慢
排查时最容易混淆的是节点端口、本地监听端口和目标网站端口。这三个位置处在不同链路上。下列数字仅用于说明端口角色，不是对所有节点的配置建议，也不代表当前 v2rayN 的固定默认值。
例如，某应用若连接 127.0.0.1:10808，连接对象是本机监听入口，不是远端节点的 443 端口。只有当前配置确实在 10808 提供该应用所需的代理协议，这个填写方式才有效。端口数字相同不等于协议相同，HTTP 代理和 SOCKS 代理也不能随意互填。
- 检查配置：更新订阅后核对节点地址、端口和传输信息；若内核启动报错，先解决启动问题。
- Tcping 粗筛：用它识别明显的 TCP 建连异常，但不要仅按最小值立即确定活动节点。
- 真连接复筛：对候选项使用相同测试 URL；失败项结合日志排查，成功项再进行下一步。
- 下载测速补充：仅对有持续传输需求的候选项执行，保持同一测试资源，并观察是否稳定。
- 实际应用确认：开启所需的接入方式，访问常用网站，确认路由与日志符合预期。
建议在相同条件下重复 3 轮，记录中间水平和失败次数，而不是只保留最好的一次。这是比较方法，不是性能承诺。若工作时段与晚间的负载不同，可以分别留一组记录，避免拿清晨结果推断高峰时段表现。
常见结果组合：按失败环节处理
Tcping 有结果，真连接一直超时，先改哪里？
先打开日志，再单独测试一个节点。认证失败时更新订阅并核对用户标识；TLS 或 REALITY 握手错误时核对服务名、公钥等参数；解析失败时再检查对应域名的 DNS。不要同时修改传输、路由和 DNS，否则无法确认是哪项产生作用。
真连接正常，浏览器却打不开页面？
先把该节点设为活动节点，在主界面的系统代理选项中选择适合当前使用方式的设置。随后核对浏览器是否另设代理，以及本地端口是否与应用填写值一致。请求若已进入内核，再看目标域名命中的路由，而不是继续修改测速地址。
延迟很低，为什么下载还是慢？
先暂停其他下载，再用相同测速资源逐个测试候选节点。若只有某个下载站慢，检查目标站限速或出口到该站的路径；若多个资源都慢，再比较本地带宽、节点拥塞与不同时段表现。毫秒数无法直接换算成下载带宽。
结果显示 -1 或超时，是节点彻底失效了吗？
负值或超时通常表示本轮没有得到有效结果，具体显示约定取决于版本，并不是“负延迟”。确认测试目标能否访问、内核是否成功启动，再对同一节点重测。多个节点同时失败时，优先检查共同的测试地址、本地网络和监听端口。
节点选择：可用性优先，稳定性其次
日常浏览先排除反复真连接失败的节点，再比较重复测试中的响应与波动。有大文件传输需求时，补充看下载测速的持续表现。只有一个项目优秀的节点，不一定适合所有用途；也没有一个通用的毫秒阈值能替所有网络和网站判定“合格”。
- 网页与交互：优先考虑实际网站可访问、连接成功率稳定，以及多轮真连接延迟没有明显跳变。
- 持续下载：在可用的前提下，比较相同资源的稳定吞吐，同时留意流量消耗。
- 故障复现：记录测试时间、网络、目标 URL、错误类型与路由命中结果，不要公开订阅地址或认证字段。
可以把三种测试理解为逐步增加验证范围：Tcping 检查入口，真连接检查一条代理请求，下载测速检查持续传输。最后再用实际应用收尾，才能把“列表里有数字”落实为“当前使用方式确实可用”。需要继续核对接入与分流设置，可查看路由设置说明；订阅无法更新时，可查看订阅故障排查。