TCP ping 成功，只证明指定 TCP 地址和端口在本次探测中可连接。它没有完成节点认证，也没有验证浏览器访问。反过来，主要使用 UDP 的节点不能只靠 TCP 结果判定可用性。
先记录用了哪种测试
2026-10-04 官方状态为稳定版 2.2.6、预发布版 2.3.10。2.2.6 说明真连接测试增加 Tcping 预检查，并移除独立 Tcping 菜单；2.3.10 又增加 TCP ping 测试和并发控制。旧教程中的菜单截图可能与当前版本不同。
| 观察方式 | 结果能够覆盖的范围 |
|---|---|
| TCP ping | 地址和 TCP 端口的连接耗时 |
| 真连接测试 | 通过生成的测试配置和内核请求测试目标 |
| 目标应用实际请求 | 当前应用、接管方式及目标服务的完整访问现象 |
三者的目标和执行路径不同，不宜把数值混放在同一排行榜，也不能把毫秒数换算成下载带宽。
Hysteria2 为什么不能按 TCP 探测定性
2.3.10 固定版本 RealPingWorkerService 的独立 TCP 测试分支明确排除了 Hysteria2、WireGuard、复杂配置和仅 h3 的相关情况；这些分支可能返回失败值，而没有按普通 TCP 节点执行端口探测。
真连接分支会按节点生成测试配置，再调用内核测量配置中的测试目标。其 TCP 预检查也有协议排除条件。由此，Hysteria2 的 TCP 负值不能单独解释成服务器失效，更不能据此删除节点。
一个有用的三步对照
- 固定网络和节点，记录客户端版本、节点协议与测试类型。
- 对适用的 TCP 节点先做端口探测，再做真连接；UDP 为主的协议直接优先核对真连接和相关日志。
- 选中同一节点，启动所需接管方式，在目标应用中建立一次新请求。记录请求目标与结果。
若 TCP 成功、真连接失败，继续检查协议字段、认证、TLS 及测试目标本身。若真连接成功、目标应用失败，应核对接管范围和目标请求；不能因真连接成功就保证所有应用可达。
保持测试条件可比
同一节点在 Wi-Fi 与移动网络上的结果不可直接归因于客户端版本。测试目标更换、网络瞬时拥塞或服务端限制，也会影响真连接结果。保留失败时刻和第一条相关错误，比只截一个负数更能定位问题。
批量测试可造成额外请求负载，先用少量节点定位，避免连续触发多轮。预发布版中并发控制改变测试任务组织方式，不代表每个节点一定更快。本站没有测得任何节点排名或速度提升。
完成标准
测试记录应至少包含版本、协议、网络、测试类型、目标与结果。只有一种不适用的探测返回负值时，结论应写“此探测不能确认该协议的可用性”。需要首次连接的完整验收时，参阅首次连接检查表。
官方依据
本文核对固定标签的分支条件，未执行真实节点或 Android 客户端测试，结果解释不能代替实际日志。