服务器时间不同步导致证书与定时任务异常：NTP/chrony 校时配置与排查

发布时间：2026-09-16 12:31 更新时间：2026-09-16 12:31 阅读量：0

证书明明没过期，浏览器却提示校验失败；日志里的事件顺序乱七八糟，排查故障时对不上号；定时备份任务有时候早跑几分钟，有时候晚跑半小时。这几类看起来毫不相干的问题，背后常常是同一个原因：服务器时间不准。时间漂移不像 CPU 打满那样显眼，它悄悄发生，等暴露出来时，往往已经影响过证书校验、日志分析和业务调度。本文从现象出发，把时区、硬件时钟、网络校时这三者的关系讲清楚，再给出可执行的配置与排查步骤。

先分清三个时间概念：时区、系统时钟、硬件时钟

很多新手把“时间不对”笼统当成一个问题，实际上 Linux 里至少涉及三层：

时区（Timezone）决定系统把 UTC 时间显示成几点。它只影响“显示”，不改变时间本身。中国区服务器通常设为 Asia/Shanghai，也就是 UTC+8。如果时区错了，日志时间会整体偏移 8 小时，但证书校验基本不受影响，因为 TLS 校验用的是绝对时间戳。

系统时钟（System Clock）是内核维护的时间，所有进程读到的都是它。它平时由晶振驱动，晶振有误差，一天漂几秒到几十秒都属正常，所以必须定期校正。

硬件时钟（RTC）是主板上的电池供电时钟，关机后仍在走。开机时内核会读取 RTC 来初始化系统时钟。RTC 也可能不准，而且它记录的到底是 UTC 还是本地时间，取决于系统配置，这是容易踩坑的地方。

三者关系可以这样理解：网络校时负责把系统时钟拉回准确值，时区负责显示成当地时间，RTC 负责断电期间“记住”时间。任何一环出错，都会表现为“时间不对”。

校时怎么做：chrony 与 systemd-timesyncd 配置

先确认当前时间状态。查看系统时间和时区：

timedatectl
输出中重点看：
Local time / Universal time / Time zone / System clock synchronized

如果 System clock synchronized 显示 no，说明系统没有在跟任何时间源同步，这就是证书和 cron 出问题的根源之一。设置时区用：

timedatectl set-timezone Asia/Shanghai
timedatectl set-ntp true

不同发行版默认的校时服务不同。CentOS / RHEL 8 及以上、多数较新的发行版默认用 chrony；Debian / Ubuntu 部分版本默认用 systemd-timesyncd。两者选其一即可，不建议同时开启。以 chrony 为例，配置文件通常在 /etc/chrony.conf（部分发行版为 /etc/chrony/chrony.conf，以实际环境为准）：

# 指定上游时间源，可写多个
pool ntp.aliyun.com iburst
server ntp1.tencent.com iburst

允许本机所在网段向本机校时（按需开启，注意访问控制）
allow 192.168.1.0/24

记录时钟漂移速率，提升长期精度
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync

其中 makestep 1.0 3 的含义是：前 3 次校时如果偏差超过 1 秒，就直接跳变而不是缓慢调整，适合刚装好的机器；rtcsync 会定期把系统时间写回硬件时钟，避免重启后时间又跑偏。改完重启服务并验证：

systemctl restart chronyd
systemctl enable chronyd
chronyc sources -v
chronyc tracking

chronyc tracking 里的 System time 一行显示的是本机与时间源的偏差，正常情况下应在毫秒级。如果一直是几百毫秒甚至更大，先检查上游时间源是否可达，再看服务器出口是否放行了 UDP 123 端口——NTP 默认走 UDP 123，很多云安全组默认不放行，这是校时失败最常见的原因。

如果用的是 systemd-timesyncd，配置文件在 /etc/systemd/timesyncd.conf，在 [Time] 段里写 NTP= 即可，改完用 systemctl restart systemd-timesyncd 生效，用 timedatectl timesync-status 查看状态。

现象排查：证书、日志与 cron 分别怎么对

证书校验失败。TLS 校验会检查证书的有效期区间，如果服务器时间被设到了过去或未来，比如系统时间停在 2020 年，那么 2024 年签发的证书就会被判定为“尚未生效”。这类报错的典型特征是浏览器提示证书无效，但用工具查看证书本身完全正常。此时先执行 date -u 看 UTC 时间是否与真实时间一致，再排查校时服务。

日志时间错乱。如果日志整体偏移固定小时数，多半是时区问题，检查 /etc/localtime 指向是否正确；如果日志时间忽前忽后、事件顺序对不上，那是系统时钟在跳变，通常是校时服务没有持续运行，或者有人手动执行过 date -s 改时间。生产环境不建议手动改时间，容易让依赖时间差的程序（如数据库、消息队列）出错。

cron 提前或延迟执行。cron 依赖系统时钟判断触发点，时间跳变时任务可能被跳过或重复触发。更隐蔽的情况是：服务器时间比真实时间慢几分钟，任务实际执行时刻就整体后移。排查时先确认时间同步正常，再检查 /var/log/cron（以发行版实际路径为准）里任务的执行记录，对照真实时间看偏差。

另外提一句硬件时钟。可以用 hwclock --show 查看 RTC 时间。需要注意 RTC 存的是 UTC 还是本地时间：一般建议让系统按 UTC 管理 RTC，由时区负责显示转换，这样跨时区迁移和夏令时切换时不容易出错。是否启用 UTC 由 /etc/adjtime 第三行（UTC 或 LOCAL）决定，改动前先确认现有环境，避免重启后时间整体偏移。

小结一下：遇到证书报错、日志对不上、定时任务不准这三类现象，先跑一遍 timedatectl，把“时区是否正确、系统时钟是否已同步”这两个问题确认清楚，再去查上游时间源、UDP 123 放行和校时服务是否开机自启。给新机器装系统后顺手配好 chrony 并设置开机启动，比事后排查省事得多。生产环境还建议给关键服务器加一条时间偏差监控，偏差超过阈值就告警，别等到证书失效或任务错乱才被动处理。

继续阅读