Linux时间同步实战：从NTP原理到chrony配置与排障

1. 从服务器时间错乱说起：为什么系统时间同步是刚需

我在维护服务器的头两年，没少被时间问题折腾。最典型的一次是某个周末凌晨，监控系统突然告警，说数据库主从复制延迟异常，我登录上去一看，主库和从库的时间差了整整40秒。40秒对日常操作来说不算什么，但对binlog的position定位、对依赖时间戳的分布式事务来说，就是灾难性的偏差——从库直接跳过了一批本该执行的relay log，数据一致性当场被破坏。

那次之后我把时间同步这件事彻底研究了一遍，才发现很多运维新手甚至一些老手，对Linux时间同步的认知都停留在“装个ntpdate就完事了”的阶段。实际上，时间同步远不止“对一下表”这么简单，它背后涉及系统时钟类型的选择、时区/UTC的处理、NTP协议的工作模型、chrony与ntpd的取舍、闰秒和漂移补偿等一系列问题。凡是跑生产环境的机器、做嵌入式Linux开发的板子、做自动驾驶多传感器融合的工控机，时间不同步都会引发一连串看似无关的诡异故障。

这篇内容不是为了把Linux时间同步讲成一本厚书，而是把我实际踩过的坑、验证过的配置、排查过的案例整理出来，从时间在Linux里怎么运转讲起，一直讲到生产环境里到底该用哪套方案。核心围绕两样东西：NTP/chrony的协议原理和配置实操，以及那些文档里不会明说但实战中一定会碰到的边界情况。适合刚配过时间但没搞懂原理的人，也适合被时间问题折磨过的运维，读完你可以照着直接改配置。

2. 系统时间到底是怎么转起来的：RTC、系统时钟、时区与UTC

2.1 硬件时钟与系统时钟：一对经常打架的“双时钟”

很多人不知道Linux里其实存在两套时钟。第一套是硬件时钟，也叫RTC（Real-Time Clock），它由主板上的纽扣电池供电，就算机器断电关机，它也会继续走。第二套是系统时钟，也就是内核维护的软件时钟，它从系统启动那一刻开始由内核计数，精度更高，但一断电就清零。

Linux开机时会把RTC的时间读出来，作为系统时钟的初始值，然后系统时钟就独立运行了。这里最关键的认知是：机器运行期间，RTC和系统时钟是两套独立走时的设备，不会自动互相校准。你在系统里执行date命令改的时间，默认不会写回RTC；你改RTC的时间，系统时钟也不会立即变化。很多刚接触Linux的人改完时间重启一下发现又变了，就是因为只改了一个时钟，或者改的方式不对。

日常判断时间准不准，我们要看的是系统时钟。而时间同步工具（ntpd、chronyd）做的事情，本质上是外部可信时间源校准系统时钟，再把校准结果写回RTC，让硬件时钟也不至于漂移太多——不然下次开机启动阶段的时间会很难看。

2.2 UTC、本地时间与RC边上那块“时区”的坑

接下来是时区。Linux系统内部其实有一条非常明确的原则：内核只认UTC。系统时钟在内部记录的一律是UTC时间，我们日常说的“北京时间”、“东京时间”，只是内核往外展示时套了一层时区偏移。你可以运行date -u看看，它会输出UTC时间；再运行date看看，输出的就是应用了时区后的本地时间。同一个底层时间，两个展示结果。

这个原则带来的实际影响是：配置时间同步时，时区不影响同步行为，但影响你看到的时间对不对。比如你在中国，系统安装在默认的UTC时区，那么就算NTP同步完全正常，你在终端输入date看到的也会是比真实北京时间慢8小时的时间。这种情况极容易误导新人——同步日志显示一切正常，但是系统时间怎么都对不上。

处理方式也很简单，设置时区用timedatectl set-timezone Asia/Shanghai，或者直接软链接/etc/localtime到/usr/share/zoneinfo/Asia/Shanghai。另一个容易踩的坑是：修改时区时，RTC的显示基准也会参与进来。RTC里存的时间到底是UTC还是本地时间，由/etc/adjtime里第三行的LOCAL或UTC决定。系统默认一般是UTC，也就是RTC存的是UTC时间；但Windows默认把RTC存成LOCAL时间，如果你双系统切换使用，最典型的表现就是：在Linux里改完时间，进Windows时间就乱了，或者反过来。这个问题的根治办法通常是让RTC统一按UTC存，然后在Windows侧改一个注册表项让它也按UTC解读RTC，这个不展开，但要知道问题出在哪。

2.3 timedatectl：排障时第一时间要用的命令

聊到时间和时区，就必须提到timedatectl，这是systemd体系下查看和修改整体时间状态的首选命令。强烈建议你在排查任何时间问题时，第一件事就敲一下：

bash复制timedatectl

它会一次性输出：当前本地时间、UTC时间、RTC时间、时区、是否开启NTP同步、NTP同步是否活跃、以及systemd-timesyncd是否在运行。我见过太多人在排查时间问题时一上来就改/etc/ntp.conf，结果根因是timesyncd和ntpd抢占了同一个端口（123/UDP）导致服务起不来。用timedatectl一眼就能看出系统当前到底用的哪个同步服务，这个信息比什么都重要。

还有一点，如果输出里显示NTP service: active，说明系统的网络时间同步服务是开着的；如果是inactive，即使你装了ntpd/chrony，也可能没有真正生效。很多精简版Linux默认只带systemd-timesyncd，它虽然轻量，但功能和精度都有限，生产环境建议直接换掉。

3. NTP到底是怎么对时的：层级、偏移、延迟与校准策略

3.1 时间层级与“向谁要时间”的选择逻辑

NTP（Network Time Protocol）的核心是构建一套时间信任链。最顶层是Stratum 0，指的是原子钟、GPS接收机这类高精度硬件时间源。它们通过串口或USB接口把时间传给上一级服务器，也就是Stratum 1。然后Stratum 1的服务器向Stratum 2的服务器提供时间，依次往下。层级数字越大，离权威时间源越远，理论上精度也逐级降低。

但实际运维中我一般建议：从Stratum 2开始用就够了。国内网络环境下，直接同步阿里云、腾讯云提供的NTP服务器（它们通常都是Stratum 2或更高级别的集群）完全能满足生产需要。层级只是参考，更重要的是网络质量和服务器稳定性。一个Stratum 3但网络极其稳定、延迟极低的内部NTP服务器，实战中往往比跨洋访问一个Stratum 1的公共服务器效果好得多。这也是为什么中大型企业会在内网架自己的NTP服务器，统一让所有机器指向内部源。

3.2 偏移、延迟和抖动的消解：为什么不能“拿回时间就改”

NTP对时不是简单地把远程服务器的时间拿过来直接覆盖本地时钟，而是要经过一套严谨的测量和滤波。核心指标有三个：

• offset（偏移）：本地时间和远程服务器时间之间的差值，正数表示本地偏快。
• delay（延迟）：网络往返时间（RTT），请求发出到收到响应的时间差。
• jitter（抖动）：多次测量delay值的波动程度，反映网络稳定性。

NTP的校准逻辑是：客户端发送带本地时间戳的请求，服务器收到后打上服务器时间戳，再返回给客户端，客户端收到时再打一个本地时间戳。通过这四个时间戳（t1、t2、t3、t4），可以算出：

code复制delay = (t4 - t1) - (t3 - t2)
offset = ((t2 - t1) + (t3 - t4)) / 2

为什么不能只取一次测量结果就校时？因为网络延迟是不对称的，请求过去的路径和响应回来的路径可能完全不一样。单次测量得到的offset可能包含很大的误差。NTP的算法核心是：在多次采样中，选取延迟最小的那组数据进行计算——因为延迟最小的包最接近“对称网络”的假设，误差最小。这种机制叫“过滤/筛选”，是NTP抗干扰的关键。

实际生产中，公共网络环境下的网络抖动往往比服务器本身的时钟漂移严重得多。所以NTP会周期性地采样、滤波、平滑校准，而不是猛一下把时钟往前跳或往后跳。这也解释了为什么你刚把ntpd配好，立即执行date看时间好像“没变化”——它还在采样和判定阶段，要等计算出稳的offset之后才逐步调整。

3.3 大步进与小步进：slew模式解决“时间一改日志乱套”的困境

系统时钟校准有两种方式：step（跳跃） 和 slew（微调）。step就是直接把系统时间改成一个新值，适合系统与真实时间偏差很大的情况，比如刚开机发现慢了1小时。但step有个致命副作用：时间突然往前或往后跳，会让日志、监控、定时任务、数据库事务等产生不可预知的混乱。一次大幅的step，甚至会让Linux的cron把本该执行的任务跳过或重复执行。

slew则是让内核通过调整每秒系统时钟走的刻度数（比如每秒实际走1.0001秒或0.9999秒），在较长时间内把偏差逐渐“抹平”。这个过程里系统时钟是连续前进的，只不过比真实时间稍快或稍慢，最终收敛到准确时间。它的好处是平滑无跳跃，对依赖单调递增时间戳的应用非常友好。

chrony和ntpd都支持这两种模式，区别在于触发阈值。默认情况下，chrony的阈值是偏差超过1000秒才做step，否则一律用slew。这个设计在生产环境里非常重要：一台服务器被误设成明年日期，你不想把时间直接从2026年跳回2025年打断所有服务，而是希望它平滑地走回去。虽然这样会有很长一段“错误时间”，但对业务的冲击远小于瞬间跳变。

3.4 什么是PTP/GPTP，和NTP的根本区别

排查时间相关问题时经常看到“gptp时间同步原理”这个热词，这里也顺便说清楚。PTP（Precision Time Protocol，IEEE 1588）以及用在音视频领域的gPTP（Generalized PTP，IEEE 802.1AS）是一套亚微秒级的时间同步协议，和NTP这种毫秒级精度的协议完全不是一个量级。NTP靠纯软件网络包往返测量来估时差，PTP则依赖网络交换机做硬件时间戳，在数据包经过物理层时打上纳秒级时间戳，从而消除操作系统协议栈和网络排队的延迟不确定性。

在自动驾驶、车载以太网、音视频同步等场景，PTP/gPTP是标配，因为摄像头、激光雷达、IMU的融合算法对时间戳一致性要求极高，毫秒级误差都会导致感知结果错乱。但在普通服务器的运维场景中，NTP/chrony的毫秒级精度已经完全够用。如果你在做嵌入式Linux、被要求在车里做时间同步，可以去搜索PTP的Linux实现ptp4l和phc2sys，那是另一个话题。这里不做展开，但你要知道：不同场景选不同的协议，别拿NTP硬扛高精度场景。

4. chrony配置实战：生产环境最稳的同步方案

4.1 为什么chrony逐渐取代了ntpd

老牌的ntpd曾是Linux同步事实标准，但最近十年里，chrony在很多发行版上已经取代了它。我自己的体验，chrony的优势相当明显：

• 同步速度快：ntpd刚启动时为了保证准确性，需要手动“渐进式”探测一段时间才能大幅校准；chrony可以在几秒内完成初始同步，这对于嵌入式设备、虚拟机快速迁移场景非常重要。
• 对网络抖动容忍度高：chrony内部实现了更好的滤波和预测算法，在不稳定网络上的表现优于ntpd。
• 无需一直在线：chrony支持“离线模式”，会根据历史漂移数据持续调整系统时钟，就算NTP服务器断网了，也能大差不差地维持时间精度。这对笔记本、便携设备、车载系统尤其友好。

现在CentOS 8+、Ubuntu 18.04+、Debian 10+默认安装的就是chrony。如果你还在老系统上用ntpd也不是不行，但新系统建议统一迁到chrony，少折腾。

4.2 一台干净的chrony服务器配置示例

假设你现在要配置一台内网NTP服务器，同时自己也同步公网时间源，并给局域网内其他机器提供时间。下面是完整的配置文件，以CentOS/RHEL系的/etc/chrony.conf为例，Ubuntu系的配置大同小异：

bash复制# 上游时间源：用阿里云和腾讯云的公共NTP
server ntp.aliyun.com iburst
server ntp1.aliyun.com iburst
server ntp.tencent.com iburst

# 接受客户端请求的网段，按实际修改
allow 192.168.1.0/24

# 即使无法访问上游也能对外提供服务
local stratum 10

# 记录时钟漂移率
driftfile /var/lib/chrony/drift

# 启用RTC实时时钟跟踪
rtcsync

# 让chronyd在启动时立即修正时钟
makestep 1 3

解释几个关键项：

• iburst：启动后的第一个同步周期内，连续发送多个时间请求，快速完成初始同步。没有这个选项，同步可能要等好几分钟，加了之后几秒内就能完成。内网设备建议必加。
• allow：不写的话默认只允许本机同步。要在同一局域网对外提供时间服务，必须显式放开网段。这里如果写错网段，客户端会一直处于“unreachable”状态。
• local stratum 10：当所有上游NTP都不可达时，本机可以把自己声明为stratum 10的时间源，继续给局域网提供服务。这样即使公司出口断网了，内网各机器的误差也不会迅速发散，因为大家从同一台机器同步，至少时间是一致的。注意：这台机器本身时间不一定准，所以只适合做内网一致性保障，不代表绝对准确。
• makestep 1 3：前三个时钟更新周期内，如果偏差超过1秒，就执行step跳跃校准。超过这个范围后，chrony就只使用slew微调。这个参数的用意是：刚部署时允许快速校正一次大偏差，之后长期运行中尽量平滑。

配置改完后执行：

bash复制systemctl restart chronyd
systemctl enable chronyd
chronyc sources -v

chronyc sources -v是核心排障命令，它会列出当前上游源的同步状态。字段含义：^*表示当前正在使用且同步正常的源，^?表示不可达或未完成握手，^+表示可用但不是主要的源。看到^*就说明同步链路已经通了。另外用chronyc tracking可以看当前的偏差、频率、上次调整时间等详细信息。

4.3 客户端配置与“分层级联”的实践建议

客户端有两种配置方式。如果是几十台机器的小规模场景，最简单的方式是直接修改/etc/chrony.conf，把server指向你的内网NTP服务器，注释掉默认公网源，重启chronyd即可。

bash复制# 只用内网服务器，减少对公网的依赖
server 192.168.1.10 iburst

但如果是上百台机器的规模，我建议用自动化工具批量下发生效，而不是一台台手改。Ansible的chrony角色、Puppet的chrony模块都有现成的模板，改一个文件分发下去就行。

关于要不要做多层NTP架构，我的观点是：大多数场景不需要。同步精度每经过一层就会打一个折扣，层数越多，末端误差越大。除非你的网络环境极其特殊（比如有隔离网段、防火墙策略强制分区域），否则客户端尽量直连同一台上游NTP服务器。真的需要做“级联分层”，也最多两级：一级服务器接公网源，二级服务器从一级同步并服务未来更大的子网。三级以上的级联，精度损失和排障复杂性都不划算。

4.4 chrony与systemd-timesyncd、ntpd共存的筋膜枪问题

这是我在实战中踩过最坑的一个点。很多发行版默认开启了systemd-timesyncd（systemd自带的时间同步服务），它默认监听123/UDP端口，也是用NTP协议。如果你再装一个ntpd或chrony，默认同样要监听123/UDP端口，就会发生端口冲突。表现形式非常迷惑：chronyc sources显示所有源都不可达，ss -ulnp | grep 123却能看到timesyncd占着端口。

解决办法是先停用系统自带的时间同步能力，再启用chrony：

bash复制timedatectl set-ntp false
systemctl stop systemd-timesyncd
systemctl disable systemd-timesyncd
systemctl restart chronyd
systemctl enable chronyd

timedatectl set-ntp false这个动作容易被忽略，它的作用是关闭systemd最上层的NTP总开关。有的发行版上，即使你disable了timesyncd，timedatectl还会检测到“NTP服务未激活”并把你的chrony排除在外。我自己遇到过几次：chrony起来了，但timedatectl显示NTP service: inactive，导致某些依赖systemd时间同步状态判断的监控脚本误报。

装完chrony后记得执行一遍：

bash复制timedatectl status

确认NTP service: active再走下一步。

4.5 补充：如果您在嵌入式Linux上做时间同步

嵌入式Linux的场景比服务器更特殊。很多板子没有RTC电池，或者RTC精度很差，每次开机系统时间都是从默认值（比如1970年）开始。这种情况下，即使配了chronyd，启动到获取到网络时间之间会有一段“错误时间窗口”，如果板子在这个窗口内写入日志、生成文件，时间戳就是错的。

我个人实践的思路是分两步走：第一步，在系统的网络就绪后执行一次chronyc makestep（或启动时强制makestep 1 3立即生效一次），让时间快速跳到正确值；第二步，如果板子经常掉电，建议把最近一次准确时间持久化到一个小文件（如/var/lib/fake-hwclock），开机时先读这个文件临时初始化系统时钟，等网络同步后再校正。这样能最大限度缩小错误时间窗口，日志时间戳也能保持基本有序。

5. 实测验证与排障思路：从现象到根因的完整链路

5.1 同步状态怎么查：chronyc的“体检指标”逐个拆解

配好chrony之后，日常巡检看这几个命令就够用：

bash复制chronyc tracking
chronyc sources -v -a
chronyc sourcestats -v

chronyc tracking最核心的输出项目：

• Stratum：本机当前处于第几层。
• Ref time (UTC)：上次成功从上游同步到时间的UTC时刻。
• System time：本地系统时钟与参考源的偏差，正数表示本地偏快。我一般看到绝对值小于10毫秒就不需要干预。
• Offset：建议关注多次采样的offset波动，如果每次都是几十毫秒在跳，说明网络路径不稳。
• Leap status：正常是Normal，如果出现Insert second之类的状态，说明上游有闰秒发生，chrony在做闰秒处理。

chronyc sources -v则是排查上游源可达性的第一现场。看M（time source）行的开头标记，^*表示它是当前选定的同步源，^+表示通过候选但非首选，^-表示被排除，^?表示握手失败或不可达，^x表示被falseticker（不合逻辑的时间点）丢弃。如果看到^?，优先检查防火墙出方向UDP 123是否放行、上游地址是否写错、DNS解析是否正常。

5.2 防火墙、SELinux和最容易被忽略的“UDP被过滤”

聊到防火墙，这里单独强调一次：NTP走的是 UDP 123端口。很多人在排查时习惯性地放行TCP端口，却忘了NTP根本不用TCP。如果你在云厂商的安全组、公司防火墙、或者本机firewalld里没有放行UDP 123的出方向和入方向，同步就会失败。

本机firewalld放行NTP服务（作为客户端需要出方向，作为服务端需要入方向）：

bash复制firewall-cmd --permanent --add-service=ntp
firewall-cmd --reload

如果你用的是iptables，注意放行规则里UDP协议别漏了。另外在RHEL/CentOS系上，SELinux也可能拦截chronyd访问网络或修改系统时间。如果配置完全正确但始终同步失败，可以临时执行setenforce 0测试一下，如果立即恢复正常，那就是SELinux的策略问题。正常情况下RHEL系自带的chrony SELinux策略是通的，但如果改了非标准端口、非标准配置路径，就需要对应调整策略。

5.3 一个完整排障案例：内网客户端全部同步失败

去年有一次，办公室新增了一台NTP服务器，配置完成、本机同步正常，但局域网内其他机器全部^?不可达。我排查的链路是这样的：

第一步，在NTP服务器本机执行chronyc sources -v，发现上游同步正常，说明服务器本身没问题。

第二步，从客户端机器执行chronyc sources -v，看到^?，说明客户端根本无法和服务器建立NTP通讯。

第三步，从客户端ping NTP服务器IP，通了；但nc -u 192.168.1.10 123测试UDP连通性，一直没有响应。

第四步，检查服务器firewall-cmd --list-all，发现NTP服务并未在放行列表里。前面提到allow只控制chronyd应用层接受哪些来源，但包要在系统防火墙层被放行才能到达chronyd。补上：

bash复制firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="192.168.1.0/24" port protocol="udp" port="123" accept'
firewall-cmd --reload

第五步，客户端再次chronyc sources -v，同步状态变为^*。

这个案例最有价值的一点是：chrony配了allow不等于防火墙放行，两层必须都通。而且防火墙规则修改后最好确认规则顺序，如果前面有DROP规则的优先级更高，加在后面的allow不一定会生效。

5.4 偏差一直很大时的深挖方向

如果同步链路显示^*，但chronyc tracking里Offset一直维持几十毫秒以上的偏差，通常说明系统时钟漂移率很高或者有硬件问题。第一步看driftrate（漂移率），如果每秒漂移几十微秒甚至几百微秒，说明RTC或者主板晶振质量一般，这不是配置能完全解决的，得靠chrony持续微调维持精度。

另一个可能性是NTP服务器负载过高。如果你在内网用一台很旧的虚拟机充当所有机器的NTP服务器，流量可能超过它处理UDP 123包的能力。此时用chronyc serverstats看一下本机处理请求的统计，能确认是否有丢包严重的情况。现实中的解法一般是换更强的机器，或者加一台NTP服务器分摊负载。

5.5 闰秒：一个平时遇不到但遇到就“全军覆没”的话题

每几年国际原子时会插入一次闰秒，把UTC多出一秒。对普通服务器来说，这1秒通常不会造成明显影响，但对高频交易系统、导航定位基准站这类对时间精度极度敏感的场景，闰秒就是个要命的话题。Linux内核在处理闰秒时，会让系统时钟出现“23:59:60”这样的假想秒，或者把秒数直接跳过，由此可能导致内核时钟冻结、应用卡顿等问题。

如果你在金融、交通、自动驾驶行业做运维，建议关注上游NTP源对闰秒的处理策略。比如谷歌用的是“leap smear”（闰秒涂抹）技术，把多出的1秒摊到当天的时间上，让客户端的本地时钟永远不会出现跳变或冻结；阿里云也推出了类似的处理。如果你的应用对闰秒零容忍，建议直接把上游切到这些做了涂抹处理的NTP源，而不是用传统的跳变式源。

6. 除了chrony，还有哪些时间管理的实战细节

6.1 手动改时间的正确姿势

有些场景下不能等NTP慢慢校准，比如测试环境坏了需要临时把时间拨回去，或者要在虚拟机里模拟一个指定的时间点。这时候正确的操作是：

bash复制# 先停止自动同步
systemctl stop chronyd
# 可选：直接设置日期时间，也可以带时区
timedatectl set-time "2025-06-15 10:30:00"
# 改完后重启同步
systemctl start chronyd

不建议在生产环境直接date -s "2025-06-15 10:30:00"，因为date命令只改系统时钟，不写RTC，而且可能被systemd的timesyncd/chrony立刻纠正回去，让你误以为命令没生效。用timedatectl set-time是更符合systemd体系的做法。

6.2 虚拟机场景的时钟漂移

虚拟机的时钟漂移速度通常比物理机快得多。原因是虚拟机的系统时钟依赖宿主机虚拟时钟的中断注入，而宿主机自身的负载、CPU调度延迟都会引入误差。VMware和KVM/QEMU都有各自的Guest Tools（如open-vm-tools、qemu-guest-agent），它们会主动校准虚拟机的时钟漂移。

如果你在虚拟机里跑业务，且任务对时间敏感，强烈建议装好Guest Tools，再做一层chrony兜底。很多虚拟机镜像为了精简默认都没装，结果就是跑一段时间后时间误差百毫秒级。补上的步骤一般就两条命令：

bash复制apt install open-vm-tools   # VMware
apt install qemu-guest-agent   # KVM/QEMU

装了agent之后，如果还开chrony，要留意两者之间是否存在重复校准的冲突。我的经验是让Guest Tools负责“粗校准”（防止大偏差），chrony负责“细校准”（精确到毫秒级），两者默认配置下一般不会打架，但如果发现时间反复跳跃，可以关掉Guest Tools的时间同步选项，只留chrony，挑一条路走到黑。

6.3 时间同步与日志/监控的联动价值

时间同步不只是“和真实时间一致”这么简单，它更是一个基础设施级的正确性前提。分布式环境里，日志统一时间戳决定了故障排查能不能按时间线还原事件；监控系统的告警时序、指标对齐，也依赖所有被监控端的时间一致；数据库复制、消息队列的延迟统计、证书的生效/过期判断，全都以信任系统时钟为前提。一个时间不一致的环境里，排查任何链路问题都会像在“对暗号”一样痛苦。

所以我的建议是，把时间同步状态纳入主动巡检：脚本定期抓chronyc tracking里的System time绝对值，超过阈值（比如50ms）就告警。这种做法比等着用户报障再查效率高得多。

6.4 关于“系统时间同步”的终极建议

做了这么多年运维，我对Linux时间同步的体会可以用一句话概括：原理不复杂，但坑在细节里。这套机制的关键在于三点：

• 清楚系统时钟和RTC是独立的两套体系，同步时要考虑双方向的写回。
• 生产环境优先用chrony，参数要理解iburst、makestep、allow、local stratum各自的作用再配置。
• 排障路径要有章法：先timedatectl看整体状态，再chronyc sources -v看源状态，再查防火墙和UDP 123，最后才动配置。

就算你只是在个人电脑上折腾Linux，把chrony配好、理解时间同步的运作逻辑，也能避免一堆看似莫名其妙的问题——比如文件时间戳忽前忽后、构建系统缓存失效、证书校验失败。这套基本功撑起的是整个系统的可信时间基础，值得多花半小时搞清楚。