握手超时与 TLS 错误怎么处理：从 SNI、时间同步到协议切换

TLS 错误是一类「卡在中间」的故障：TCP 三次握手已经完成，说明本机到节点的路是通的，但加密层协商失败，连接还是用不了。日志里常见的写法有 tls: handshake timeout、handshake failure、x509: certificate signed by unknown authority、certificate has expired or is not yet valid。它们指向四类原因，本文按从最便宜到最复杂的顺序给出处理方法。

TLS 握手在机场链路里发生在哪

本机与节点之间的加密连接，和浏览器与网站之间的加密连接，是两层独立的 TLS。客户端日志里的握手错误，绝大多数指的是第一层：客户端与机场节点之间的协商。这一层的参数全部来自订阅：服务器地址、端口、SNI（伪装域名）、是否校验证书、客户端指纹。任何一项与服务端当前配置不一致，握手就会失败。

原因	典型报错	判断方法	处理
系统时间偏差	certificate has expired / not yet valid	对比系统时间与网络时间	开启自动同步
SNI 或证书不匹配	x509: certificate is valid for … not …	用 openssl 看证书域名	更新订阅，核对 sni 字段
内核不支持服务端要求	handshake failure / unsupported protocol	更新内核后是否恢复	升级客户端与内核
中间设备干扰	handshake timeout、无明确报错	换端口、换协议对比	切换协议或入口
证书确实无效	unknown authority	其他用户同样报错	等机场修复，不要跳过验证

第一步：同步系统时间

证书有生效时间与过期时间，系统时间偏差超过几分钟就可能落在有效期之外。这是 TLS 错误里最常见也最容易修的原因，尤其是刚装好的系统、长时间休眠后唤醒的笔记本、没有电池的旧设备。

Windows PowerShell（管理员）：

# 查看当前时间源与偏差
w32tm /query /status
# 立即同步
w32tm /resync

macOS / Linux：

# macOS
sudo sntp -sS time.apple.com
# Linux（systemd）
timedatectl set-ntp true && timedatectl status

同步后重启客户端再测。时间问题还会让订阅更新报证书错误，相关情况见订阅更新失败怎么办。

第二步：更新订阅与内核

机场更换证书、调整 SNI 或升级协议版本后，旧订阅里的参数就过时了。手动更新订阅，再确认客户端内核版本：Clash Verge Rev 与 Mihomo Party 在设置里可以直接更新 Mihomo 内核；v2rayN 可以在「设置 → 核心」里更新；Shadowrocket 与 Stash 随应用版本更新。较新的协议（如 Reality、Hysteria 2）对内核版本有硬要求，旧内核会在握手阶段直接失败。协议之间的差异可以参考机场常见协议解析。

第三步：核对 SNI 与证书

SNI 是握手时告诉服务端「我要访问哪个域名」的字段，服务端据此返回对应证书。订阅里的 sni / servername 与服务端证书域名不一致，就会报「证书对该域名无效」。用 openssl 直接看服务端返回的证书：

# 把 SNI 设为订阅里的伪装域名，查看返回证书的域名与有效期
openssl s_client -connect 节点入口域名:443 -servername 订阅里的SNI </dev/null 2>/dev/null \
  | openssl x509 -noout -subject -dates

Windows 可以用 curl 的详细模式观察握手：

curl.exe -v --resolve 订阅里的SNI:443:节点IP https://订阅里的SNI/ 2>&1 | Select-String "subject|expire|SSL"

证书域名与 SNI 不一致、或已过期，说明是服务端配置问题，更新订阅看是否已修正；仍不一致就联系机场。自己手动改 SNI 通常无效，因为服务端只认它配置的那个域名。

另一种情况是 DNS 把入口域名解析到了错误的 IP，握手自然失败。用 nslookup 对比不同 DNS 的解析结果，方法见 DNS 污染怎么判断与修复。

第四步：判断是否为中间干扰

前三步都正常，但握手阶段仍然超时或被重置，且没有明确的证书报错，要考虑中间设备对 TLS 握手的干扰。特征是：

• 同一节点，换到手机热点就正常；
• 只有 443 端口受影响，换到 8443 或其他端口恢复；
• 只有某种协议受影响，其他带 TLS 的协议正常；
• 晚高峰更严重，深夜恢复。

处理按顺序尝试：换端口、换协议、换入口地区。握手超时与握手被重置的区别，可以结合连接被拒绝与连接被重置的含义一起判断。

逐步排查清单

1. 看日志确认错误词属于 TLS 类（tls、handshake、x509、certificate）。
2. 同步系统时间，重启客户端。
3. 手动更新订阅，升级客户端内核到最新稳定版。
4. 用 openssl 或 curl 核对服务端证书域名与有效期。
5. 换端口、换协议、换地区，对比手机热点。
6. 以上都无效且其他用户同样报错，等待机场修复并关注公告。

预防建议与小结

• 系统时间保持自动同步，虚拟机与长期休眠设备尤其要检查。
• 客户端内核每月更新一次，但不要在重要任务前升级大版本。
• 订阅每日自动更新，证书与 SNI 的变更才能及时同步。
• 选择机场时，关注它是否同时提供多种带 TLS 的协议、证书是否由公开 CA 签发。这类细节在稳定机场推荐与靠谱机场推荐的评估里都有体现。

总结一下：TLS 错误意味着网络通、加密层没谈拢。先同步时间，再更新订阅与内核，然后核对 SNI 与证书，最后才考虑中间干扰并切换协议。全程不要打开跳过证书验证。更多超时类问题见连接超时栏目。