先说一个常见误区：很多人配置完chrony，执行完命令后，用chronyc tracking查看，仍然显示 Leap status : Not synchronised。第一反应通常是配置文件写错了？其实大概率不是，根本原因是：chronyd 服务压根没运行。默认情况下它不自动启动，所以第一步就是手动启动它，并设置开机自启，然后再做验证。
确认 chronyd 是否已安装并正在运行
当前主流发行版（如 RHEL 8+/CentOS 8+、Ubuntu 20.04+）基本都预装 chrony，但服务通常处于静默状态。你可以用 systemctl is-active chronyd 查看是否 active，再用 systemctl is-enabled chronyd 确认是否已设置开机自启。一旦看到 inactive 或 disabled，别犹豫，两步搞定：sudo systemctl start chronyd 和 sudo systemctl enable chronyd。启动后立即执行 chronyc tracking，看 System clock status 是否变为 OK。如果还是显示 Not synchronised，才说明尚未连接到时间源，这时需要深入检查配置文件。
/etc/chrony.conf 必改的三处关键项
默认配置使用的是 pool.ntp.org，在国内网络环境下延迟高且不可控。生产环境必须果断做三件事：
第一，将所有 pool 行注释或删除，替换为显式的 server 指令。例如三个可靠的国内源：server ntp.aliyun.com iburst、server time1.cloud.tencent.com iburst、server ntp.ntsc.ac.cn iburst。第二，务必确认配置中包含 makestep 1.0 -1 这一行。缺少它，哪怕时钟只偏差几秒，chronyd 也会缓慢调整，导致日志时间错乱、证书验证失败等连锁问题。第三，删除或注释掉 rtcsync。云主机或容器中硬件时钟并不可靠，写入 RTC 反而添乱。除非你确实在管理一台物理服务器且需要持久化时间，否则不要碰它。
用 chronyc 而不是 timedatectl 检查同步状态
很多人习惯用 timedatectl status 查看时间同步，但它只显示 "synchronized: yes/no"，过于粗糙，容易掩盖真实问题。真正可靠的检查方法如下：
chronyc tracking能显示当前偏移量（Offset）、估计误差（Root delay）、频率漂移（Skew）——这些才是判断是否真正同步的依据。chronyc sources -v列出所有时间源的状态：*表示当前主用源，+是备用源，?代表无法访问。如果看到大量?，大概率是云环境防火墙拦截了 DNS 或 UDP 123 端口。- 必要时可用
chronyc makestep手动触发一步校正，前提是配置中必须有有效的makestep行。 - 另外注意，
chronyc默认只接受本地 socket 连接，远程调用需额外配置cmdport 0并开放防火墙，通常没必要这么做。
云服务器或容器里同步失败的典型原因
许多用户卡在 Leap status : Not synchronised 这一步，其实跟配置文件本身关系不大，完全是环境限制。例如：
- AWS EC2、阿里云 ECS 等公有云禁止直连公网 NTP，必须使用内网地址。AWS 用
server 169.254.169.123 iburst，阿里云用server 100.100.2.136 iburst。 - Kubernetes Pod 内无法直接运行
chronyd，因为容器默认没有 CAP_SYS_TIME 权限，也不能绑定 UDP 123 端口。正确做法是让 Node 节点统一同步，Pod 直接复用宿主机时间。 - 防火墙未放行 UDP 123 出向流量（尤其在私有云或定制镜像中），用
chronyc sources -v查看，所有源状态均为?，根本原因就在这里。
实际部署时最容易被忽略的，就是云环境必须换成内网 NTP 地址，而且 makestep 这一行绝对不能少。少了它，系统时间哪怕只差几秒，就会在日志、TLS 握手、JWT 校验等环节引发一连串令人头疼的故障。
