连接排障 · Clash 技术博客

Clash TLS 握手失败怎么办？证书、时间与 SNI 排查

先看 TLS 错误发生在订阅下载、节点握手，还是访问目标网站。这三处都可能显示 handshake failed，但要检查的证书、时间和 SNI 完全不同。

阅读正文返回博客
  • TLS
  • 证书错误
  • SNI
  • 连接排障
本文目录
文章作者
Clashare
发布日期
更新时间
预计阅读
约 8 分钟

看到 TLS handshake failed，先保存完整错误和失败阶段

证书错误、系统时间不准和 SNI 配错都会显示成 TLS 握手失败，但修法完全不同。先复制日志里的完整原文，再确认错误发生在订阅下载、代理节点握手，还是打开目标网站；这两项确定后，才知道该查时间、证书链还是节点字段。

常见原文

日志文字优先方向
x509: certificate has expired or is not yet valid系统时间、证书有效期
x509: certificate signed by unknown authority系统 CA、企业 SSL 检查、私有证书
remote error: tls: handshake failureSNI、协议字段、服务端 TLS 配置
tls: failed to verify certificate: x509证书链、servername 与实际证书名称
EOF / connection reset by peer对端提前关闭、网络拦截；不能只凭这一句断定证书问题

复制错误前后几行，保留时间、目标域名和端口，但遮住订阅 token、UUID 与密码。只截“TLS failed”会丢掉真正能区分原因的部分。

订阅下载、节点握手和目标网站是三条不同连接

先做一个很简单的对照：现有节点还能不能访问其他 HTTPS 网站，订阅还能不能手动更新。两个结果组合起来，通常就能判断握手失败发生在哪一跳。

Profile 更新报 TLS，现有节点还能用

失败在订阅 URL；检查该域名证书、系统时间和网络检查设备。

只有一个节点报 handshake failure

失败在客户端到代理服务器；比较该节点的 server、port、SNI 与 TLS 字段。

节点能连，只有一个 HTTPS 网站报证书错误

查看目标站证书、浏览器/应用证书库和是否被安全软件解密。

所有节点同时开始 x509 报错

先看系统时间、内核升级和网络是否统一替换了证书。

时间不对时，任何证书设置都会被误判

Linux 与 Windows 可先查看
# Linux
date -R
timedatectl status

# Windows PowerShell
Get-Date
w32tm /query /status

证书有 Not Before 与 Not After。双系统切换、虚拟机快照、长期断电的 OpenWrt 或关闭自动校时，都可能让时间偏离。把日期、时区和 NTP 同步恢复后，重新启动 Mihomo 再复现一次；错误仍完全相同才继续检查握手字段。

单个节点失败时，对照 SNI 与服务端证书名称

TLS 节点连接的 server 可能是 IP，证书却签发给域名；这时配置通常需要正确的 servername 或 sni。值必须来自服务端配置，不能从网上猜一个热门域名。端口、传输类型、ALPN、Reality public-key/short-id 等字段也必须成套匹配。

字段名称按代理类型与当前 Mihomo 文档核对
proxies:
  # 下列 IP、域名和密码都是占位值，不能直接连接
  - name: tls-example
    type: trojan
    server: 203.0.113.10
    port: 443
    password: REDACTED
    sni: edge.example.com
    skip-cert-verify: false

在同一网络查看服务器实际返回的证书

域名和端口替换为失败目标
openssl s_client -connect edge.example.com:443   -servername edge.example.com -showcerts </dev/null

curl -Iv https://edge.example.com/

openssl 输出里看 subject、issuer、有效期与 Verify return code。加与不加 -servername 返回不同证书，说明服务端依赖 SNI；证书在手机热点正常、公司网络却变成企业 CA，则存在 SSL 检查或中间网关。

代理协议端口不一定提供普通 HTTPS 页面，curl 失败并不自动说明节点坏了；openssl 的证书与握手信息更有参考价值。Reality 等协议也不能按普通网站证书逐项套用，应回到对应协议文档。

只有公司网络失败，先确认是否有受管证书检查

企业代理、安全网关和部分杀毒软件会重新签发 HTTPS 证书。受管设备应由管理员安装组织 CA 并说明哪些流量允许检查；个人不要从报错网页下载陌生根证书，也不要为让 Clash 更新成功关闭全系统证书验证。

换手机热点后同一订阅 URL 立即正常，是网络路径差异的证据。把公司网络下的 issuer、错误时间和目标域名交给管理员，比不断换节点更有用。

修复后重复原来失败的那条连接

不要用“别的网站也能打开”代替验证。回到最初报错的订阅、节点或目标网站，用同一网络再试一次，并确认日志里的原错误已经消失。

验证结果

  • 系统时间与时区正确，重启内核后不再出现 not yet valid/expired
  • 订阅失败时，手动更新成功且更新时间变化
  • 节点失败时，同一节点完成握手并产生真实连接记录
  • 目标网站失败时，证书 issuer 与域名符合预期
  • 临时关闭的证书检查或安全设置已经恢复
  • skip-cert-verify 保持 false，除非受控测试有明确理由

参考资料