ConnProof

TLS handshake timeout：TLS 握手超时的原因与排查方法 ​

TLS-002TLS handshake timeout严重程度 High
一句话结论

TCP 连接已经建立，但 TLS 握手没有在限定时间内完成。最可能是中转线路或防火墙在握手阶段干扰或丢弃了数据包；第一步是切换到另一个网络对同一目标重新检测，对比结果。

适用环境WindowsmacOSLinux
适用客户端通用客户端
最后验证：2026-07-28规则版本：v1内容更新：2026-07-28

结论 ​

这个错误的关键信息是分层的：TCP 三次握手已经成功（说明 IP 可达、端口开放），失败发生在其后的 TLS 握手阶段——客户端发出了 ClientHello，却在限定时间内没有收到有效的握手响应。问题出在"能连上但谈不拢加密"这一层，而不是网络完全不通。

适用环境 ​

  • Windows / macOS / Linux
  • 所有使用 TLS 的连接：HTTPS、基于 TLS 的代理协议、wss://

一分钟快速判断 ​

  1. 换网络（手机热点）对同一目标运行 connproof tls <主机> --port 443。热点下成功而原网络失败 → 原网络链路对 TLS 握手有干扰，跳到"如何区分"一节。
  2. 检查系统日期时间。偏差超过几分钟就先校准——时间错误更多导致证书校验失败（TLS-001），但部分服务端也会直接掐断时间异常的会话。
  3. 同一网络下检测其他 HTTPS 站点（如你常用的网站域名）。全部超时 → 本地或出口问题；只有特定目标超时 → 目标或其线路问题。

这条错误代表什么 ​

TLS 握手是加密通道的协商过程：客户端发送 ClientHello（包含支持的协议版本、加密套件和 SNI），服务端回应 ServerHello 与证书，双方再完成密钥交换。超时意味着这个往返在中途停住了——最常见的停点是 ClientHello 发出之后。由于 SNI 在 ClientHello 中明文可见，具备深度包检测能力的设备可以在这一刻决定放行、丢弃或重置连接；丢弃就表现为超时。

需要说明：仅凭"超时"本身，无法区分是去程包被丢、回程包被丢，还是服务端根本没处理。下面的证据可以缩小范围。

ConnProof 如何判断 ​

connproof tls 目标域名 --port 443 --verbose

ConnProof 记录并区分：

  • TCP 建连耗时（证明前一层正常）；
  • 发送的 SNI 值；
  • 握手停止的位置与等待时长；
  • 与 --timeout 的关系（是慢还是死）。

补充对比检测：

  • connproof tls 目标域名 --port 443 --timeout 30000：把超时放宽到 30 秒。能成功说明是严重延迟而非阻断，指向线路拥塞或 MTU 问题；仍失败则更像策略性丢弃。
  • 对同一 IP 用不同域名（不同 SNI）检测：一个成功一个失败，是 SNI 相关干扰的强证据。

最常见原因 ​

  1. 中转线路在握手阶段提前关闭或丢弃：线路对特定 SNI 或流量特征有策略，ClientHello 之后不再转发。
  2. 防火墙或安全设备的 TLS 检查：企业网关做 TLS 拦截失败时，可能既不放行也不重置，表现为超时。
  3. SNI 与目标不一致：客户端配置里的伪装域名/SNI 写错，服务端对未知 SNI 不响应。
  4. MTU 或分片异常：证书链较大的 ServerHello 分片后部分丢失，握手永远等不齐。PPPoE、VPN 嵌套环境常见。

Windows 排查步骤 ​

  1. connproof tls <目标> --port 443 确认失败层级与耗时；
  2. connproof tls <目标> --port 443 --timeout 30000 区分"慢"与"死"；
  3. 临时关闭第三方防火墙/安全软件的网络过滤功能后复测（记得恢复）；
  4. 若使用 VPN 或虚拟网卡，尝试把物理网卡 MTU 从 1500 降到 1400 复测（netsh interface ipv4 set subinterface "以太网" mtu=1400 store=persistent，测完记得改回）；
  5. 换网络对比，确定干扰发生在哪一段。

macOS 排查步骤 ​

  1. 同样先跑两次不同超时的 connproof tls；
  2. 系统设置 → 网络 → 详细信息 → 硬件 中检查 MTU 设置，嵌套 VPN 时降低到 1400 复测；
  3. 公司设备检查是否安装了带 TLS 检查的管理软件（描述文件里通常有企业根证书，这类环境更常见 TLS-001，但检查失败时也会表现为超时）。

手机端排查步骤 ​

  • 分别在 Wi-Fi 和蜂窝数据下检测同一目标，差异直接指向其中一个网络；
  • 手机端无法调 MTU，重点做网络对比和节点对比；
  • 如果只有代理客户端内的连接超时而浏览器正常，检查客户端里该节点的 SNI/伪装域名配置是否与服务端一致。

IPv6 环境下的额外检查 ​

双栈网络中还有一种隐蔽情形：域名同时有 A 和 AAAA 记录，系统优先尝试 IPv6，而本地 IPv6 路由到目标并不通畅——表现出来的同样是握手或连接超时，但根源在地址族选择。用两条命令直接对比：

connproof tls 目标域名 --port 443 --ipv4
connproof tls 目标域名 --port 443 --ipv6

如果 IPv4 检测顺利完成而 IPv6 超时，当前证据支持"IPv6 链路不通"而不是 TLS 本身的问题：可在应用或系统中暂时优先 IPv4，并参考 IPv6 resolved but unreachable 做进一步确认。两个地址族都超时，则回到上文的网络对比与 MTU 排查路径。这个两分钟的对比经常能省去后面所有步骤，建议在双栈环境中优先执行。

如何区分本地问题和节点问题 ​

证据更可能是
热点下同一目标握手成功原网络链路干扰
所有目标在本网络下都握手超时本地出口或防火墙
只有走代理的握手超时，直连正常代理线路或节点配置
换 SNI 后成功SNI 相关策略或配置错误
放宽超时后成功拥塞或 MTU，而非阻断

仍未解决时收集什么信息 ​

  • ConnProof 错误码（TLS-002）与脱敏报告；
  • 客户端名称和版本、操作系统版本；
  • 问题发生时间段（策略性干扰常有时段规律）；
  • 两个网络下的对比结果；
  • 失败检测层级（TCP 成功 + TLS 超时）。

禁止提交：完整订阅链接、节点密码、验证码、私钥、Token。

重新运行检测 ​

connproof tls 目标域名 --port 443 --format markdown --output tls-report.md

修复后应看到握手成功、协议版本与证书有效期证据。

相关文档 ​

更新记录 ​

  • 2026-07-28：规则 v1 发布，加入 SNI 对比与超时放宽两种对照检测方法。