Leadaxe 说明连接检查可观测的阶段范围
Leadaxe 说明客户端无法观测 TCP、TLS、认证和 QUIC 内部握手，只能可靠展示 DNS、路由、节点测试和目标请求耗时及错误，并将 DNS 与路由查询支持指向另一项 core 工作。
作者原文@LeadaxeThe per-protocol handshake chain will not happen. The core does not expose handshake internals, and most of the listed steps are not observable from the client side at all.
Not observable:
- TCP
SYN/SYN-ACK/ACK— handled by the OS kernel; the app only sees how longconnect()took.- TLS steps (ClientHello, ServerHello, certificate verify), uTLS, REALITY "signature verify" / "cert borrowed" — inside the TLS library. A REALITY failure surfaces as a generic handshake error or as the decoy site answering.
- VLESS/VMess UUID, Trojan password, Shadowsocks cipher — the server sends no acknowledgement. A wrong credential means the server closes the connection or serves its fallback, which looks the same as any other failure.
- QUIC Initial / Handshake / 1-RTT, Hysteria2/TUIC auth — inside the QUIC stack.
- XHTTP "mode negotiation" — there is none; the mode comes from the config.
Observable:
- DNS: how the core resolves the domain, which DNS server answered, the addresses, the time.
- Routing: the rule that matches, the outbound, and the full chain (group selection, detours).
- Node: URL test delay through the selected outbound (exists today).
- Request to the target through the tunnel: total time, time to first byte, and the core's error text when it fails (dial timeout, TLS handshake error, EOF, etc.).
Karing's Net Check does exactly this (DNS, route, request) and shows no handshake steps either.
The DNS and routing queries need core support: Leadaxe/sing-box-lx#59.