TLS 与证书错误排查：时间、域名与信任链

TLS 会验证通信对象的身份，也会协商加密连接。浏览器的证书警告、节点日志中的 x509 和笼统的 handshake failed 可能发生在不同连接上。先读完整错误，再选择对应修复，避免通过“允许不安全连接”让警告消失，却没有解决原因。

先确定是哪一层 TLS 失败

代理访问 HTTPS 时，可能同时存在“客户端到节点”和“浏览器到目标网站”两层连接；节点协议未使用普通 TLS 时情况又不同。先记录错误出现在客户端日志、订阅更新窗口还是浏览器页面，并看报错对应的域名。

错误特征	主要方向	第一个对照
expired / not yet valid	证书有效期或系统时间	检查设备时间，再看证书日期
hostname mismatch / 名称不匹配	URL、SNI 或证书名称	核对最新官方节点参数
unknown authority / unable to get local issuer	信任链、CA 存储、证书替换	同目标换应用或网络
handshake failed / EOF / reset	协商、服务、网络、协议参数	查看更早的具体日志
只有订阅下载报错	订阅 HTTPS 服务	查最新地址及订阅更新排查

“所有节点都失败”只能说明共享因素值得先查，不能仅凭这一现象断定时间错误。不要在证书告警页面输入账号密码，也不要从告警页临时提供的陌生地址下载根证书。

第一步：确认日期、时间和时区

先在系统设置中开启自动日期与时间，核对年份、日期、时区和实际 UTC 时间。时区设置影响显示；手工把显示时间改得“看起来正确”，可能让 UTC 仍然错误。

Windows 可使用管理员终端查询时间服务；需要重新同步时再执行第二条：

w32tm /query /status
# 使用当前配置的时间源重新同步，不改时间源配置
w32tm /resync

微软文档将 w32tm 用于时间配置和诊断。加入组织域的设备通常遵循域时间层级，应由管理员处理异常；同步失败也可能是服务或时间源不可达，不要盲目改用随机服务器。Windows 时间服务说明

macOS 在“系统设置 → 通用 → 日期与时间”中检查自动时间，操作可对照 Apple 官方说明；Linux 使用发行版提供的时间同步服务。校准后重新发起失败连接。若时间已正确而证书确实过期，应由服务端续签，不能把设备时间调回过去。

第二步：核对地址、SNI 与最新订阅

节点配置中的服务器地址、TLS 的 SNI/服务器名称，以及传输层的 HTTP Host 是不同字段，不能随便互相替换。某些合法配置会让它们不同，也应以服务商或自建服务端的明确配置为准。按以下顺序处理：

1. 备份当前配置，更新官方订阅，确认启用的是更新后的配置。
2. 检查是否在手动编辑或转换过程中丢失了 TLS、SNI、传输类型等参数。
3. 同一订阅选择另一节点复测，判断是否只有特定服务器失败。
4. 自建服务检查服务器实际返回的证书链及其名称和有效期；购买服务则将脱敏报错交给服务商处理。

mihomo 将 sni/servername、证书验证与客户端指纹分别定义。不要为了消除名称错误，把 SNI 随机改成一个知名网站；也不要把 TLS 客户端指纹误当成证书指纹。mihomo TLS 字段说明

第三步：区分目标网站证书与节点证书

用相同 HTTPS 目标，经当前本地 HTTP/mixed 端口测试，端口按实际设置更换：

# macOS / Linux；Windows 使用 curl.exe
curl -q --proxy http://127.0.0.1:7890 --noproxy localhost --connect-timeout 10 --max-time 20 --head https://example.com/

同时观察客户端日志。如果内核在连接节点时已报 TLS 错误，先解决节点这一层；如果代理隧道已建立，而 curl 报目标网站名称或签发链错误，则继续检查网站 HTTPS、程序 CA 存储和网络环境。HTTP 状态成功后仍要在连接列表确认出站，避免测试实际走了 DIRECT。

看到 HTTP/1.1 200 Connection established 只表示本地 HTTP 代理接受了 CONNECT 隧道，后面的目标 TLS 仍可能失败。继续看是否有目标网站自己的响应、curl 最后一条错误及同时刻的内核日志，不把这一行当作网站证书已经通过。

需要更细信息时，在上面的命令中加 --verbose，只在本机查看。对本次 HTTPS 测试，curl 的错误 35 指向 TLS 建连失败，60 指向对端验证失败，77 指向读取 CA 文件的问题；这些数字区分处理方向，不能单凭 60 判断证书过期。它们描述 curl 自己观察到的连接，节点内部的握手仍以代理内核日志为准。curl TLS 错误码

浏览器已经显示目标证书时，打开其证书详情，记录请求域名、证书包含的名称、有效期与签发者，和同目标的另一网络对照。只对某个过期网站失败、其他站点均正常时，暂时停止向该站点提交信息并由站点维护者修复；节点证书过期或名称与官方配置不符时，则交给节点服务方处理。不要安装报错页面临时推荐的根证书，也不要因为签发者名称陌生就直接认定攻击。

必要时在本机使用 curl --version 记录 TLS 后端。curl 官方说明，不同构建可能使用系统原生信任存储或文件型 CA；浏览器成功而 curl 失败，可能是二者信任来源不同，也可能是请求路径不同。对目标服务需要私有 CA 的情况，只使用可信管理员提供的 CA，并按应用官方流程配置。curl 证书与 CA 文档

详细日志可能记录 URL、认证头、内部地址或浏览历史。先在本机检查，分享前脱敏，不要直接上传整个配置目录。

第四步：检查网络环境与兼容性

同一设备、同一节点、同一目标换用自己的手机热点。如果证书签发者或错误仅在公司、校园网络出现，可能涉及组织的 HTTPS 检查或认证门户，应向管理员确认；不要擅自绕过受管设备策略。个人安全软件具备 HTTPS 扫描时，可在确认影响范围后短暂做对照，随后恢复原设置。

若所有网络都存在同样错误，核对客户端与内核是否匹配当前节点要求。备份后从项目官方渠道更新兼容版本，并查看发布说明。出现 EOF、连接重置或通用握手超时时，还需检查服务端口、传输方式和节点状态；这类报错没有足够证据时，不应反复安装证书。

成功验证与恢复

完成修复后，保持证书校验开启，用原节点访问原目标，再用另一节点或应用对照。确认日志不再出现相同错误、浏览器没有证书告警，并测试重新启动后仍正常。仅“忽略警告后能打开”不算验证通过。

恢复排查期间临时改变的网络、日志级别与安全软件设置；无效的手动 SNI、CA 路径或协议改动也应撤销。不要把 skip-cert-verify、allowInsecure 或 curl 的 --insecure 留作长期解决方案，它们会跳过关键的身份校验，curl 官方也明确反对在生产使用中这样处理。

仍需协助时，提供完整但脱敏的错误文本、发生层次、系统时间与时区、客户端/内核/curl 版本、是否所有节点与目标受影响、不同网络的对照，以及最近一次有效配置的时间。证书的公开名称、有效期和签发者通常足以帮助定位，不应提供私钥、订阅、密码或完整认证日志。