服务器时间不同步导致的证书与鉴权故障排查手册

服务器时间不同步，看似只是几分钟偏差，却常常是证书报错、登录失败、接口鉴权异常的真正根因。本文给出可直接照做的排查手册。

一、先定位：是单机漂移还是全网不同步

1. 在故障节点和正常节点分别执行 date -u 与 date，记录时区与时间差。
2. 用 timedatectl status 查看 NTP 是否启用、是否已同步、本地时区是否正确。
3. 用 chronyc tracking 与 chronyc sources -v 检查 chrony 的参考源、偏移量（Offset）、上次同步时间与可达性。
4. 若使用 systemd-timesyncd，查看 timedatectl timesync-status 与 journalctl -u systemd-timesyncd 日志。

二、对比各节点时间差

1. 选取一台可信时间源，例如内网 NTP 或权威时间源，作为基准。
2. 对比应用节点、网关、数据库、证书签发与校验节点的当前时间，差值超过 5 秒就应重点怀疑，超过 5 分钟时 Kerberos、部分 JWT 与证书校验几乎必然出问题。
3. 检查虚拟机时间同步：宿主机时间漂移、快照恢复、休眠唤醒后，虚拟机时钟可能跳变；确认 VMware Tools、KVM guest agent 或云厂商时间同步服务是否正常。
4. 检查容器时间：容器默认继承宿主机时钟，重点排查宿主机，而不是在容器内单独改时间。

三、证书有效期校验

1. 用 openssl s_client -connect 域名:443 -servername 域名 查看证书链与过期时间。
2. 用 openssl x509 -in cert.pem -noout -dates -subject -issuer 核对 Not Before 与 Not After。
3. 若客户端报证书过期或尚未生效，先不要急于换证书：先确认客户端当前时间是否在证书有效期内；很多“证书过期”其实是客户端时间快了几个月或慢了几年。
4. 检查中间证书与系统根证书时间：系统时间错误也会导致根证书被误判为过期或未生效。

四、Token 与 JWT 时间窗口

1. 解码 JWT 的 iat、nbf、exp，确认当前时间是否落在有效窗口内。
2. 检查服务端与客户端、网关与鉴权服务之间的时间差；JWT 的 nbf 在未来、exp 已过，都会直接返回 401。
3. 检查鉴权服务是否配置了合理的时钟容差（clock skew），一般建议不超过 60 秒，容差过大只是掩盖问题。
4. 检查 OAuth 授权码、刷新 Token、短信验证码、一次性口令的有效期，时间不同步会让“刚拿到就过期”反复出现。

五、修复步骤

1. 统一时区：timedatectl set-timezone Asia/Shanghai，并确认所有节点一致。
2. 统一 NTP 源：内网优先使用云厂商或企业 NTP，chrony 配置 server 内网地址 iburst，重启 chronyd 并用 chronyc makestep 强制校准一次。
3. 开机自启时间同步服务，避免重启后回到手动时间。
4. 校准后再次执行 date、chronyc tracking、openssl 证书检查与一次登录鉴权复测，确认报错消失。
5. 若证书确实已过期，再按正常流程续签并替换，不要用改系统时间的方式“绕过”过期证书。

六、预防与监控

1. 对所有节点做 NTP 偏移量监控，偏移超过 1 秒告警，超过 5 秒升级处理。
2. 在发布与变更检查清单中加入时间同步检查，特别是在快照恢复、迁移、跨机房切换之后。
3. 定期演练：模拟一台节点时间偏差 10 分钟，验证证书、登录与接口的报错是否可快速定位。
4. 保留排查证据：故障时的时间、chrony 状态、证书有效期与 JWT 时间窗口截图或日志，便于复盘。

结论：遇到证书与鉴权故障，先查时间，再查证书与 Token。先统一时钟，往往能用最小代价恢复服务。