TLS 握手失败、证书错误的原因与解决：代理环境排查指南

问题现象

TLS 握手是 HTTPS 连接建立加密通道的第一步，客户端与服务器要在这里交换证书、协商加密方式。握手失败时，连接还没开始传输数据就中断了。在代理环境里，握手可能发生在两处：浏览器与目标网站之间，以及客户端与节点之间（Trojan、VLESS + TLS / Reality 等协议）。常见提示有：

• 浏览器：ERR_SSL_PROTOCOL_ERROR、NET::ERR_CERT_DATE_INVALID、NET::ERR_CERT_AUTHORITY_INVALID、“您的连接不是私密连接”；
• 命令行：curl: (35) schannel: failed to receive handshake、SSL_ERROR_SYSCALL、unable to get local issuer certificate；
• 客户端日志：tls: handshake failure、x509: certificate signed by unknown authority、x509: certificate has expired or is not yet valid、REALITY: processed invalid connection；
• AI 编程工具在终端里报 UNABLE_TO_VERIFY_LEAF_SIGNATURE 或 self signed certificate in certificate chain。

区分两类位置很关键：浏览器报证书错误，多半是本机时间或中间人软件的问题；只在客户端日志中出现握手失败，多半是节点配置或内核的问题。

可能原因

原因	判断方法	解决方法
系统时间不准	本机时间与手机相差数分钟以上，提示证书日期无效	开启自动同步时间，执行校时命令
安全软件或公司网络中间人检查	证书颁发者显示为安全软件或公司名称	关闭 HTTPS 扫描，或在对应工具中信任企业根证书
节点 SNI 或 Reality 参数不一致	同一订阅中某类节点集体失败，手动改过配置	更新订阅，恢复原始配置
客户端内核过旧	新协议节点失败，日志提示字段不支持	升级客户端和内核
系统根证书过旧	老旧系统上大量网站证书不受信任	更新系统，或安装最新根证书更新
节点证书过期	只有某个机场的 TLS 节点失败，时间正常	联系机场处理，期间换其他节点

为什么中间人检查会让握手失败

部分安全软件、公司上网行为管理设备或抓包工具，会在本机安装一张自己的根证书，然后把所有 HTTPS 流量解密检查后再重新加密。浏览器信任这张根证书，所以通常看起来一切正常；但命令行工具、Node.js、Python 等程序往往使用自己独立的证书库，并不认识这张根证书，于是报出“证书链中有自签名证书”。同样地，这类检查遇到代理协议的加密流量时，也可能直接破坏握手。

从报错信息判断排查方向

报错关键词	最可能的方向
CERT_DATE_INVALID、not yet valid、has expired	本机时间不准，其次是节点证书过期
AUTHORITY_INVALID、unknown authority、self signed	中间人检查、系统根证书过旧
SSL_PROTOCOL_ERROR、handshake failure	节点参数不一致、内核不支持、链路被干扰
REALITY 相关字样	Reality 公钥、短 ID 或伪装域名配置不一致
SSL_ERROR_SYSCALL、unexpected EOF	握手途中连接被切断，按连接重置思路排查

同一台电脑上，如果浏览器和终端报错类型不同，要分别处理：浏览器通常使用系统证书库，而 Node.js、Python 等程序往往自带证书库，信任关系并不一致。

快速自查

1. 把电脑时间与手机时间对比，误差应小于 1 分钟；
2. 点开浏览器地址栏的证书信息，看“颁发者”是否为正常的公共证书机构；
3. 暂时关闭安全软件的 HTTPS 扫描或网页防护功能后复测；
4. 在客户端中更新订阅，确认节点配置是机场下发的最新版本；
5. 检查客户端和内核是否为最新版，尤其是在使用 Reality、AnyTLS 等较新协议时。

逐步排查

1. 检查并同步系统时间。

   # Windows：查看时间同步状态（需管理员权限执行 resync）
   w32tm /query /status
   w32tm /resync
   # 查看本机与时间服务器的偏差
   w32tm /stripchart /computer:time.windows.com /samples:3 /dataonly

   # macOS：查看并校正偏差
   sntp time.apple.com
   sudo sntp -sS time.apple.com
   # Linux（systemd）
   timedatectl status

   偏差超过几十秒时，先把时间校准，再重新测试。

2. 查看证书颁发者，判断是否存在中间人。

   # Windows：输出中查找 issuer 字段
   curl.exe -v https://www.google.com -x http://127.0.0.1:7897 -o NUL

   # macOS / Linux：显示完整证书链
   openssl s_client -connect www.google.com:443 -servername www.google.com -proxy 127.0.0.1:7897 </dev/null | grep -E "issuer|subject"

   issuer 应为常见的公共证书机构；如果出现安全软件、公司或抓包工具的名称，就是中间人检查导致的问题。端口号以你的客户端设置为准，openssl s_client 的 -proxy 参数需要 OpenSSL 1.1.0 以上版本。

3. 排除 Windows 证书吊销检查的干扰。 Windows 自带的 curl 使用 Schannel，在代理环境下有时会因为无法访问吊销列表而报错。只用于诊断时，可以对比加上参数后的结果：

   curl.exe -v --ssl-no-revoke https://www.google.com -x http://127.0.0.1:7897 -o NUL

   加参数后正常，说明是吊销检查受阻，不是证书本身有问题，一般无需处理；日常使用中不要长期关闭这类检查。

4. 检查节点入口的握手。 对使用 TLS 的节点（非 Reality），可以直接检查入口证书是否有效、是否过期：

   openssl s_client -connect 节点域名:443 -servername 节点SNI </dev/null | grep -E "verify return|notAfter"

   Reality 节点借用其他网站的证书，不能用这个方法判断，应以客户端日志为准。

5. 核对节点配置。 如果你手动修改过节点的 servername、public-key、short-id、client-fingerprint 等字段，恢复为订阅下发的原始配置。这些参数只要有一项与服务端不一致，握手就会失败。Reality 的原理见 VLESS + Reality 是什么。

6. 升级客户端与内核。 Mihomo、sing-box、Xray 对新协议和新参数的支持依赖版本。升级前先导出当前配置备份，升级后重新更新订阅。

7. 给终端工具配置证书。 如果公司网络必须做 HTTPS 检查，需要按公司 IT 的说明为 Node.js、Python、Git 指定企业根证书（例如 Node.js 的 NODE_EXTRA_CA_CERTS 环境变量），具体方法以各工具官方文档为准。

注意事项

• 不要为了“能用”而在浏览器中一路点击“继续访问”，更不要在不明页面上输入账号密码；
• skip-cert-verify 和 --insecure 只适合临时诊断，长期开启会削弱安全性；
• 抓包工具用完后记得关闭系统代理并移除它安装的根证书。
• 双系统切换、主板电池没电或电脑长时间休眠后，时间最容易出错，遇到证书报错先看时间，往往能省下大量排查功夫。

仍然无法解决

1. 换到手机热点复测，判断是否是公司或校园网络在做 HTTPS 检查；
2. 在另一台设备上导入同一订阅，确认是否是节点本身的证书或配置问题；
3. 若日志显示握手在连接建立后被切断，参考连接被重置怎么办继续排查；
4. 若连握手都没开始就超时，参考节点超时怎么解决。

请遵守当地法律法规与服务条款，合理使用网络工具。

相关问题

• 连接被重置（Connection reset）怎么办
• 节点超时怎么解决：7 个常见原因
• VLESS + Reality 是什么？原理与客户端支持
• Claude Code 连接失败排查
• 更多连接问题排查