system clock drift detected：系统时钟偏差为什么会让一切连接失败
system clock drift detected严重程度 High本机时钟与服务器报告的时间存在明显偏差。偏差超过一定幅度后，TLS 证书校验和各类时间敏感的鉴权会全部失败，看起来像是服务端全面故障；第一步是开启系统的自动时间同步并立即同步一次。
结论
时钟偏差是连接故障里性价比最高的排查项：检查只要十秒，修复只要一次点击，但它造成的症状极具破坏性且极易误判——所有节点同时失败、所有 HTTPS 站点报证书错误、所有需要登录的服务拒绝你。整个画面看起来就像服务商全线崩溃，而问题其实在你这台设备的一个数字上。
适用环境
- Windows / macOS / Linux 桌面系统
- Android / iOS 移动设备
- 高发场景：主板电池耗尽的旧电脑、从快照恢复的虚拟机、长期关机后开机的设备、手动改过时间的设备
一分钟快速判断
- 直接看时间：不只看时分，核对日期和年份。设备时间与手机运营商时间对照最方便；
- 看症状是否"全面"：单个网站证书错误多半是那个网站的问题，所有 HTTPS 站点都报错则强烈指向本机时钟；
- 跑一次体检：
connproof doctor"系统时间"一项现在会给出具体的偏差秒数，而不只是显示当前时间。
这条错误代表什么
时间在网络安全里是一个基础参数，至少三处依赖它：
一、TLS 证书的有效期。 每张证书都有 notBefore 和 notAfter。你的时钟如果跑到了证书签发之前，证书被判定为"尚未生效"；跑到了过期之后，判定为"已过期"。证书本身完全正常，是你的表错了——这是 TLS-001 最常见的隐藏成因。
二、时间敏感的鉴权。 许多鉴权机制会拒绝时间戳偏离过大的请求，用来防止重放攻击。时钟偏差会让这类请求被服务端直接拒绝。
三、会话与令牌的有效期。 时钟错乱会让本地判断的"未过期"与服务端判断的"已过期"不一致，表现为反复要求重新登录。
三者叠加的结果就是：一台时钟不准的设备，看起来像是被整个互联网拒绝了。
ConnProof 如何判断
单靠本机无法验证自己的时钟——这是个先有鸡还是先有蛋的问题。ConnProof 的做法是向一台服务器要一个参考时间：发起一次 HTTP 请求，读取响应中的 Date 头，与本机时钟比较。
有两个细节决定了这个判断是否严谨：
一、扣除飞行时间。 服务器生成 Date 的时刻位于"请求发出"与"响应收到"之间，因此比较基准取两者的中点，而不是任意一端。这样能消除大部分网络延迟带来的偏差。
二、给出不确定度而不是假装精确。 Date 头只有秒级精度，加上往返延迟，结果天然带误差。报告里会写成"快 3.2 秒（±0.4 秒）"，那个 ± 就是往返时间的一半。没有把握的精度不写进结论，这是本工具的一贯做法。
判定阈值：
| 偏差 | 判定 | 含义 |
|---|---|---|
| 小于 5 秒 | pass | 与网络噪声不可区分，正常 |
| 5～60 秒 | warning | 尚未到通常的失败阈值，但应开启自动校时 |
| 超过 60 秒 | fail（SYS-001） | 足以导致证书校验与鉴权统一失败 |
| 参考不可达 | inconclusive | 离线环境下的正常结果，不做猜测 |
注意最后一行：离线时工具不会假装知道。这与"本地无法验证就显示正常"是两种完全不同的做法。
最常见原因
- 自动时间同步被关闭，或同步服务器在当前网络下不可达（部分受限网络会阻断校时协议）；
- 主板电池耗尽：台式机关机后时间回退，每次开机都要重新校准，是老机器的典型症状；
- 虚拟机或系统镜像从快照恢复：快照里的时间停留在创建时刻，恢复后可能落后数月甚至数年；
- 手动修改过时间：某些应用或游戏会诱导用户改系统时间，改完忘记调回；
- 时区正确但时钟偏移：这两个是独立的设置，时区显示对不代表时刻对——很多人只检查了时区就排除了时间问题。
Windows 排查步骤
设置 → 时间和语言 → 日期和时间，确认"自动设置时间"已开启，点击"立即同步"；- 同步按钮报错时，检查 Windows Time 服务是否运行（服务列表里的
W32Time）； - 校时后重新运行
connproof doctor，确认偏差回到 5 秒以内； - 若关机后又偏移，基本可以判定是主板电池问题，更换电池即可根治。
macOS 排查步骤
系统设置 → 通用 → 日期与时间，开启"自动设置日期与时间"；- 受限网络下自动同步可能失败，换网络后再同步一次；
connproof doctor复测确认。
手机端排查步骤
- Android 与 iOS 都在日期时间设置里开启"自动设置"（通常由运营商网络提供时间）；
- 开启后仍不准的，开关一次飞行模式强制重新获取；
- 手机时间通常比电脑可靠，可以用手机作为核对电脑时间的参照物。
如何区分本地问题和服务端问题
这条错误必然是本地问题，但值得说明它与其他故障的边界：
| 证据 | 结论 |
|---|---|
| 所有 HTTPS 站点都报证书错误 | 强烈指向本机时钟 |
| 只有特定站点报证书错误 | 那个站点或其链路的问题，见 TLS-001 |
| 校时后一切恢复 | 确认为 SYS-001 |
| 校时后仍全部失败 | 时钟不是原因，转 all nodes timeout 的排查流程 |
| doctor 显示偏差但连接正常 | 偏差尚未到阈值，校时即可，不必紧张 |
仍未解决时收集什么信息
- ConnProof 错误码（SYS-001）与 doctor 的脱敏输出（含偏差秒数与误差范围）；
- 操作系统版本与设备类型（物理机 / 虚拟机）；
- 校时前后的对照结果；
- 时间偏移的方向与幅度（快还是慢、差多少）。
禁止提交：完整订阅链接、密码、验证码、私钥、Token。
重新运行检测
connproof doctor修复后"系统时间"一项应显示偏差在 1 秒以内，状态为 pass。随后再排查原本的连接问题——时钟偏差会掩盖真实故障，必须先修它再往下查。
相关文档
更新记录
- 2026-07-29：规则 v1 发布，同时在 doctor 中加入基于 HTTP Date 头的实际偏差检测（此前仅显示本机时间并标记 inconclusive）。