电脑时间不准，也会让代理连接失败吗？
会。使用常规 TLS 证书校验的代理连接，可能因为设备时间明显不准而失败。但“证书过期”也可能确实发生在服务端，不能看到这几个字就只改电脑时间。
本文以 Windows 11 上的 Clash 类客户端为例，处理日志明确提示证书“已过期或尚未生效”的情况。其他证书错误不一定适用这条排查路线。
这条错误，究竟在比较什么
日志中可能出现：
x509: certificate has expired or is not yet valid
意思是，用于校验的当前时间，没有落在相关证书的有效期内。它不等于“机场套餐到期”，也不能单凭这一句证明服务商没有续证书。
Go 项目的证书校验实现会比较当前时间与证书的生效、失效时间；没有另外指定校验时间时，使用当前时间。查看证书时间判断的实现
**下面是虚构示例，不是本站故障记录：**一张证书从 2026 年开始有效，电脑却错误地停在 2020 年。即使证书按真实日期仍有效，校验也可能认为它“尚未生效”。反过来，设备时间跳到很久以后，也可能把有效证书判断为过期。
先保存错误，再核对是哪台设备的时间
先记下错误原文、发生时间和节点名称。如果日志还列出“当前时间”和证书有效期，把这些信息一并保留。
再看运行代理的设备：
- 代理客户端直接运行在电脑上，就先核对这台电脑。
- 如果报错来自软路由上的代理，电脑只是经它转发，就应检查软路由运行环境的时间，不能只校准电脑后便认为这一项已排除。
日期、年份和小时都要看，不要只看任务栏右下角的分钟。可以对照一台已经确认自动对时正常的设备，先找出明显偏差。
Windows 11 上怎样核对
按 Microsoft 当前的官方说明，进入“开始 → 设置 → 时间和语言 → 日期和时间”：
- 查看显示的日期与时间，确认有没有明显错误。
- 开启“自动设置时间”，再检查系统校准后的结果。
- 核对时区。可以使用自动设置，也可以关闭自动设置时区后，选择实际所在的时区。
- 若时间仍不正确，先查看页面显示的同步状态或错误，按 Windows 的帮助继续处理，不把“开关已打开”当成校准成功。
校准目标是真实的当前时间。不要为了让某张过期证书暂时通过，把日期故意调回过去。
日志差八小时，也可能只是显示方式不同
日志可能使用 UTC，也就是协调世界时，时间末尾常见 Z；北京时间通常用 +08:00 表示偏移。
时间表示示例：2026-11-01T01:00:00Z 与 2026-11-01T09:00:00+08:00 是同一个时刻。这是格式说明，不是实测数据。查看 RFC 3339 的时区偏移说明
所以，要先换算到同一时区，再比较日志与电脑显示。不能看到小时数不一样，就直接把系统时间加减八小时。
校准以后，用同一节点重新验证
保持配置、接入方式和目标网页不变，让客户端重新发起连接，再看这一次的新日志。不要继续盯着校准前留下的错误。
| 这次看到的结果 | 下一步 |
|---|---|
| 时间恢复正确，原错误消失，目标网页能打开 | 记录这次变化，继续观察时间是否保持正确 |
| 时间确认正确，仍提示同样的有效期错误 | 保存错误中的有效期与节点信息，请服务商检查相关证书 |
| 错误变成域名不匹配、签发者不受信任等 | 按新的错误排查，不能继续只围绕时间调整 |
| 电脑时间正确，但日志里的校验时间仍明显不同 | 记录客户端、内核版本及运行环境，向项目维护者核对 |
这里给的是排查方向。只有一条节点失败，可以先试已确认可用的备选，同时保留故障记录；一次换节点成功，不能直接证明原节点的具体原因。
不用“跳过验证”代替修复
在 Mihomo 的 TLS 配置中，skip-cert-verify 的作用是跳过证书验证。查看该字段的官方说明
打开它不会校准时间，也不会更新服务端证书。即使错误因此不再显示，也不能据此认为原问题已经解决。遇到不清楚的证书配置，先让提供方说明原因和应当使用的正确设置。
求助时提供系统与客户端版本、校准前后的结果、经过遮挡的错误和节点名称即可。订阅链接、节点密码和完整配置中的凭据不要公开。
资料核对日期：2026 年 11 月 1 日。
评论