云服务器时间不准怎么办：用 timedatectl 和 chrony 排查时间同步

服务器时间看起来是小事，但时间一旦偏差，日志顺序会乱，TLS 证书校验可能失败，定时任务会提前或推迟执行，基于时间的一次性验证码也可能失效。小规格云服务器资源有限，更适合用轻量的 chrony 做时间同步。本文整理一套排查思路：先分清“时区不对”和“时钟不准”，再检查同步服务，最后才考虑校正。

一、先分清两类问题

很多“时间不对”其实是时区问题：差 8 小时整，多半是时区设成 UTC，而不是时钟漂移。差几秒到几分钟，才更像同步出了问题。

timedatectl

在使用 systemd 的发行版（如 Ubuntu、Debian、CentOS 7 及以后、openEuler 等）上，输出里重点看：

• Local time / Universal time：本地时间和 UTC；
• Time zone：当前时区；
• System clock synchronized：是否已同步；
• NTP service：同步服务是否启用。

二、修正时区

查看并设置时区：

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

改时区只影响时间的显示方式，不改变系统内部的 UTC 时间，一般比较安全。不过，依赖本地时间的 cron 任务和应用日志会受影响，生产环境最好在变更窗口里操作，并告知相关人员。有些应用（如 Java、数据库）会自己读取时区配置，改完可能需要重启对应服务才能生效。

三、检查 chrony 是否在工作

先确认安装和运行状态。服务名因发行版而异：RHEL 系通常是 chronyd，Debian/Ubuntu 通常是 chrony。

# RHEL / CentOS / openEuler
sudo dnf install chrony      # 老系统用 yum
sudo systemctl enable --now chronyd

# Debian / Ubuntu
sudo apt install chrony
sudo systemctl enable --now chrony

注意：同一台机器不要同时跑多个同步服务。systemd-timesyncd、ntpd 和 chronyd 会互相争抢时钟。装了 chrony 后，在 Ubuntu 上 timesyncd 通常会被自动替换；如果没有，可以用 systemctl status systemd-timesyncd 确认，再按需停用。

查看同步状态：

chronyc tracking
chronyc sources -v

tracking 中的 System time 表示当前和参考时间的偏差。Leap status 为 Normal 只说明闰秒状态正常，并不能单独证明时间已经准确同步，要结合偏差、Reference ID 和 Stratum 一起判断。sources 列表里，前缀 ^* 表示当前选中的源；^? 表示该源暂时不可用于同步，原因可能是连不上，也可能是刚启动、采样不足或还在评估中。所以即使所有源都显示 ?，也不能直接断定是网络问题：先看 Reach 列（八进制，0 表示最近几次都没收到响应，377 表示最近 8 次都成功），再看 LastRx 和偏差采样是否在更新；Reach 长期为 0，才更像是网络或时间源本身的问题。

四、常见原因与处理

1. 出站 UDP 123 被拦截：NTP 使用 UDP 123 端口。需要检查安全组出方向规则和本机防火墙（firewall-cmd --list-all 或 ufw status）。

2. 时间源不可达：内网环境访问不了公共 NTP 时，优先使用云厂商提供的内网 NTP 地址，具体地址以所用云平台的官方文档为准。在 /etc/chrony.conf（Debian 系为 /etc/chrony/chrony.conf）中配置：

   server <NTP地址> iburst
   

   改完后重启 chrony 服务。

3. 偏差太大，同步很慢：chrony 默认会平滑地调整时钟（slew），偏差大时追平需要很久。配置里的 makestep 1.0 3 表示启动后的前 3 次更新里，偏差超过 1 秒就直接跳变校正。

五、手动校正要谨慎

确实需要立即校正时，优先让 chrony 来做，而不是手动输入时间：

sudo chronyc makestep

尽量避免在生产环境里用 date -s 或 timedatectl set-time 随手改时间。时间突然回拨可能导致数据库事务、分布式锁、日志排序和证书校验出现异常；而且如果同步服务还在运行，timedatectl set-time 会被直接拒绝。正确的顺序是：先排查时区，再检查同步服务和网络，确认原因后再在维护窗口里校正，并留意依赖时间的业务。

六、小结

时间问题先分清是时区还是同步，再按“服务状态 → 时间源 → 网络”的顺序排查，必要时在维护窗口里交给 chrony 校正。