服务器时间不准：排查证书、登录和更新异常

证书“尚未生效/已过期”、带时间校验的登录或API签名失败、更新报错和日志时间跳跃，都值得检查时钟，但这些现象也可能有其他原因。先比较报错客户端与服务器的实际时间，保存偏差和原错误，再决定是否调整。

先确认是时区显示还是实际时刻不对

UTC与北京时间显示相差8小时可能只是时区不同。把两端时间换算到同一时区，与可信的正确时刻比较；不要看到差8小时就手动把系统时钟加8小时。时区应按业务要求选择，使用UTC本身不是故障。

Linux：查看当前时钟和正在使用的同步服务

在服务器终端查看时间；使用systemd的系统再执行timedatectl：

date -Is
timedatectl status

记录Time zone、System clock synchronized及NTP service。服务已启用不等于已经同步成功，也不能只凭一个字段判断所有发行版和同步程序的状态。非systemd系统按当前实际工具检查。

当前使用chrony时

如果已安装并正在使用chrony，执行以下监控命令；不要为了套用命令临时安装另一套同步服务：

chronyc tracking
chronyc sources -v

• tracking中的Reference ID、Ref time和System time用于核对所用来源、最近参考时间和系统时钟相对NTP时间的偏差；结合实际时刻判断，不能只看一项状态。
• sources -v中，选择状态*表示当前选中的最佳同步源；?表示暂不可用于同步，可能是不可达、上游未同步或样本不足，不等同于“网络一定被拦”。
• 没有选中源，或时间偏差持续不改善时，检查现有时间源的解析、可达性和同步服务日志，保留原输出。

如果当前使用systemd-timesyncd，且系统支持，可用timedatectl timesync-status查看该服务状态；此命令不适用于chrony。不要只因命令不适用就更换同步方案。

Windows：查看时间来源和最近同步结果

以管理员身份打开命令提示符，执行：

w32tm /query /status
w32tm /query /source

记录最近成功同步时间、来源和错误。域内服务器通常沿用已有域时间层级，不随意改成未知公网时间源。若来源与预期不符、成功同步时间明显过旧或命令报错，先检查现有W32Time配置、服务和域策略。

纠正前确认影响，再恢复已有同步配置

较大的时间跳变以及时区变更可能影响数据库、定时任务、订单和日志关联。先保存当前时间、时区、实际偏差和配置，确认维护安排；不要直接执行手动改日期或强制跳时命令。

• 只需改变Linux显示时区：确认业务使用该时区后，由管理员使用timedatectl set-timezone Asia/Shanghai等实际目标时区设置，再检查显示。该命令不能修复实际时钟漂移。
• Linux网络同步未启用：确认实例原来由timedatectl管理同步、已有可用同步服务且无冲突后，管理员可使用timedatectl set-ntp true。它会启用并启动首个现有同步服务，不安装服务，也不保证立即完成同步。使用chrony等既有方案时，按该方案修复，不并行启动多套同步服务。
• Windows已有时间服务及来源配置正确：管理员可用w32tm /resync请求重新同步。失败时保存错误，检查已有服务、来源与网络；不要反复手动改日期。

重新验证时间与原业务

调整后重新查询同一组同步状态，比较同一时区下的实际时间，并复测原来的登录、更新或HTTPS请求。命令返回成功不代替实际验证。时间已正确而证书仍报错时，继续检查域名、证书有效期、信任链及访问目标，不关闭证书校验。

持续漂移、无法获取时间源或同步命令反复失败时，可提交工单，提供实例标识、操作系统、异常时间和时区、实际偏差、同步工具与输出、原业务错误及已尝试操作。输出中的无关内部地址、凭据和用户数据应遮挡。

相关文档：HTTPS证书部署与验证 · 日志时间与断线排查