云服务器时间不准？用 chrony 排查和修复时间同步问题

服务器时间偏了几秒，看起来不起眼，却常常引出一串怪问题：HTTPS 证书校验失败、Kerberos 或 JWT 认证报“token 未生效/已过期”、分布式数据库告警时钟偏移、日志时间对不上导致排障困难。下面整理一套用 chrony 排查和修复时间同步的顺序，命令在 EulerOS、CentOS 7+/8、Ubuntu 20.04+ 上都适用。

一、先确认时间到底偏了多少

timedatectl

重点看三行：

• Local time / Universal time：本地时间和 UTC 时间；
• Time zone：时区是否正确，很多“时间不对”其实只是时区错了；
• System clock synchronized：是否已同步，no 说明同步服务没在工作。

如果只是时区错了，直接改时区即可，不用动时钟：

timedatectl list-timezones | grep Shanghai
sudo timedatectl set-timezone Asia/Shanghai

要知道真实偏差，可以和一个可靠的 NTP 源对比（不修改时间）：

chronyc -n tracking        # chrony 已运行时
# 或者临时查询，不改时钟
sudo chronyd -Q 'server ntp.myhuaweicloud.com iburst'

tracking 输出里的 System time 一行就是当前系统时间和参考源的偏差。

二、确认同步服务是谁、在不在跑

同一台机器上只应有一个时间同步服务，否则会互相打架。

systemctl status chronyd 2>/dev/null || systemctl status chrony
systemctl status ntpd systemd-timesyncd 2>/dev/null | grep -E 'Loaded|Active'

常见情况：

• CentOS/EulerOS 默认是 chronyd；Ubuntu 新版本服务名是 chrony，或默认用 systemd-timesyncd；
• 如果 ntpd 和 chronyd 同时启用，建议保留 chrony，停掉另一个：

sudo systemctl disable --now ntpd systemd-timesyncd
sudo systemctl enable --now chronyd   # Ubuntu 上是 chrony

三、看时间源是否可达

chronyc -n sources -v

关注第一列和 Reach：

• ^* 表示当前正在使用的源，^+ 是可选的备用源；
• ^? 表示源不可达或还没完成测量；
• Reach 是最近 8 次轮询的成功位图（八进制），377 表示全部成功，0 表示一次都没连上。

如果全是 ^? 且 Reach 为 0，基本是网络问题：

# NTP 使用 UDP 123 端口
sudo chronyc -n sourcestats
nc -vzu ntp.myhuaweicloud.com 123

这时检查安全组出方向和网络 ACL 是否放通了 UDP 123，以及系统防火墙（firewall-cmd --list-all 或 iptables -S）有没有拦截。在华为云 ECS 上，内网可以直接使用华为云提供的 NTP 服务器，延迟低，也不依赖公网出口。

四、修正配置

编辑 /etc/chrony.conf（Ubuntu 是 /etc/chrony/chrony.conf）：

# 至少配置两到三个源，优先内网源
server ntp.myhuaweicloud.com iburst
pool ntp.aliyun.com iburst maxsources 2

# 偏差超过 1 秒时，前 3 次更新允许直接跳变，之后只平滑调整
makestep 1.0 3

# 把系统时间定期写回硬件时钟
rtcsync

driftfile /var/lib/chrony/drift
logdir /var/log/chrony

几个要点：

• iburst 让启动时快速发几包，几秒内就能完成首次同步；
• makestep 很关键：chrony 默认只“慢慢追”时间，偏差几分钟时可能要追很久，配置后开机阶段会直接校正；
• 不要配置太多公网源，三个左右足够。

改完重启并验证：

sudo systemctl restart chronyd
chronyc -n sources
chronyc tracking

五、偏差已经很大时，立即校正

如果业务已经受影响，可以让 chrony 马上跳变一次：

sudo chronyc makestep

注意：时间跳变（尤其是往回跳）会影响依赖单调时间的程序，例如定时任务可能重复执行、部分数据库会报错。生产环境建议在低峰期操作，并先通知相关业务方。

六、防止再次出问题

1. 把时间偏差纳入监控：定期采集 chronyc tracking 的 System time，超过阈值（如 100ms）告警。
2. 镜像标准化：自定义镜像里预置好 chrony 配置和时区，避免新机器“出生即偏”。
3. 容器场景：容器共享宿主机时钟，不要在容器里跑 chronyd，在宿主机上保证同步即可。
4. 虚拟机挂起、热迁移或长时间高负载后，时间更容易漂移，这类事件之后可以检查一次 chronyc tracking。

小结

排查顺序可以记成一句话：先看时区，再看服务，然后看源可不可达，最后改配置并校正。大部分时间问题都出在“时区设错”“服务没开或多个服务冲突”“UDP 123 被拦”这三处，按顺序过一遍，通常十分钟内就能解决。