Linux 系统时间总漂移？用 chrony 把 NTP 配稳的完整做法

系统时间不准看起来是小事，实际影响很大：日志时间戳对不上、证书校验失败、定时任务跑偏、数据库主从复制出现异常，都可能源于时钟漂移。本文按排查到配置的顺序，把一台 Linux 服务器的时间配稳。

一、先确认当前状态

执行 timedatectl，重点看三项：Local time 是否与标准时间一致，System clock synchronized 是否为 yes，NTP service 是否为 active。如果 synchronized 是 no，说明本机还没有成功同步过，先不要急着改配置，往下查服务与网络。

再看 chronyc tracking，输出里的 Reference ID、Stratum、System time 一项能告诉你当前时间与参考源的偏差。偏差在毫秒级属于正常；如果偏差持续增大，说明同步根本没生效。

二、chrony 与旧的 ntpd 二选一

新系统一般默认 chrony，它对间歇联网、虚拟机挂起恢复的适应性更好。不要让 chrony 和 ntpd 同时运行，两者抢端口会互相干扰。检查 systemctl status chronyd 与 systemctl status ntpd，只保留一个处于 active，另一个停用并禁用开机自启。

三、安装与配置 chrony

Debian/Ubuntu 用 apt install chrony，RHEL 系用 dnf install chrony。主配置文件是 /etc/chrony.conf，关键是 server 行。建议至少配 3 到 4 个时间源，同一机房或同一云厂商内网的时间源优先，延迟更低也更稳定；公网源作为补充。不要只配一个源，单个源挂掉后本机就会慢慢漂移。

配置里建议保留 makestep 1.0 3，意思是开机前 3 次更新内、偏差超过 1 秒就直接跳变校正，而不是慢慢追赶。这对刚开机的云服务器尤其重要，否则启动阶段的日志和定时任务都会带着错误时间跑。

改完配置执行 systemctl restart chronyd，再用 chronyc sources -v 确认每个源的状态：^ * 表示当前正在使用的源，^ + 表示可用候选，^ ? 表示尚未建立联系。如果所有源都是问号，先查网络。

四、网络与防火墙最容易卡住

NTP 走 UDP 123 端口。云服务器要同时查两层：云厂商安全组是否放行 UDP 123 出方向，服务器本机防火墙是否放行。很多人只查了一层，另一层拦着，同步就一直失败。排查时先在本地执行 chronyc activity 看在线源数量，再用 ss -tulnp | grep 123 确认 chronyd 是否在监听。

如果服务器在内网且不能直接访问公网，不要硬配公网源，改用机房内的时间源或内网 NTP 服务器，内网源通常由云厂商提供，延迟只有几毫秒。

五、虚拟机时间漂移的特殊处理

虚拟机挂起、宿主机负载过高、快照恢复后，客户机时钟容易跳变。除了 chrony，还要确认虚拟化时间同步机制是否开启，例如 KVM 的 kvm-clock、VMware Tools 的时间同步。两者冲突时以 chrony 为准，关闭虚拟化层面的强制时间同步，避免两边来回拉扯。

日常运维里，建议把 chronyc tracking 的 System time 偏差纳入巡检：偏差长期超过 100 毫秒就值得查一次；配合 timedatectl 的检查，一分钟就能判断时间服务是否健康。时间准了，日志、证书、定时任务和复制链路的很多怪问题会自然消失。