TLS 握手失败怎么办？时间、证书、SNI 与协议配置排查

TLS 握手失败说明客户端和服务端在建立加密连接的第一步就没有谈拢。排查顺序建议是：先校准系统时间，再更新订阅确认节点参数，然后检查证书与 SNI，最后排除安全软件和公司网络等中间设备。握手原理可以先看 TCP、UDP 与 TLS 基础。

问题现象

• 客户端日志出现 tls: handshake failure、certificate 相关报错或 x509 字样。
• 所有 Trojan、VLESS 等基于 TLS 的节点同时失败，其他类型节点正常。
• 浏览器提示“您的连接不是私密连接”，而且多个知名网站同时出现。
• 刚更新订阅或刚升级客户端后，部分节点突然无法握手。

可能原因

快速检查

1. 打开系统设置，开启“自动设置时间”和“自动设置时区”，并手动同步一次。
2. 在客户端中更新订阅，确认节点参数是最新的。
3. 换一个非 TLS 类或其他机场的节点对比，缩小范围。
4. 临时关闭杀毒软件中的“HTTPS 扫描”“加密连接检查”等功能后重试。

Windows 可以用下面的命令强制同步时间（需管理员权限）：

w32tm /resync
Get-Date

详细排查

查看证书签发者和有效期

用 openssl 直接连到目标，观察返回的证书。-servername 用于指定 SNI：

openssl s_client -connect www.google.com:443 -servername www.google.com </dev/null 2>/dev/null | openssl x509 -noout -issuer -dates

如果签发者是安全软件、公司名称或陌生机构，说明中间设备在解密流量；如果有效期已过，说明是证书本身的问题。

查看握手停在哪一步

curl.exe -v -m 15 -x http://127.0.0.1:7897 https://www.google.com -o NUL

端口以客户端设置中实际显示的为准。输出停在 TLS handshake 附近并报错，结合日志可以判断是本地到节点这一段，还是节点到目标网站这一段出了问题。

核对节点的 TLS 字段

以 Clash Meta（Mihomo）内核的配置为例，常见字段如下，具体以机场下发的订阅和当前内核文档为准：

proxies:
  - name: example-trojan
    type: trojan
    server: node.example.com
    port: 443
    password: your-password
    sni: node.example.com        # Trojan、Hysteria2 使用 sni
    skip-cert-verify: false
  - name: example-vless
    type: vless
    server: node.example.com
    port: 443
    uuid: your-uuid
    tls: true
    servername: node.example.com # VLESS、VMess 使用 servername

手动编辑过配置的用户，最常见的错误是 SNI 填成了 IP、字段名写错，或者把 skip-cert-verify 改成了与机场要求不一致的值。

解决方法

1. 校准时间：开启自动同步并确认时区正确，这一步能解决相当比例的握手失败。
2. 恢复订阅原始配置：删除手动修改，重新更新订阅；如果使用了覆写脚本，先临时停用。
3. 更新客户端和内核：新参数需要较新的内核支持。
4. 处理中间设备：关闭安全软件的加密流量扫描；公司、学校网络请遵守单位规定，不要尝试绕过审计。
5. 联系机场：只有某个机场的节点握手失败且订阅已是最新，多半是服务端证书或配置问题，需要机场处理。

仍然无法解决怎么办

• 如果握手之后又被强制断开，参考 连接被重置怎么办。
• 如果所有节点既握手失败又长时间无响应，按 节点超时解决方法 排查本地网络与订阅状态。
• 向机场提供节点名、客户端版本、日志中的完整报错和出现时间。
• 请在遵守所在地法律法规和各服务使用条款的前提下使用相关工具。

更多连接类问题见 连接问题专题。