chronyd默认未启用，需手动启动、设为开机自启并验证；若chronyc tracking显示not synchronised，首先确认服务是否运行，再检查配置中server、makestep和rtcsync三项关键设置是否正确。

chronyd 默认不启用，必须手动启动、配置并验证，否则 chronyc tracking 会显示 Leap status : Not synchronised —— 这不是配置错了，而是服务根本没跑起来。

确认 chronyd 是否已安装并正在运行

多数现代发行版（RHEL 8+/CentOS 8+、Ubuntu 20.04+）预装了 chrony，但 chronyd 服务通常未启用：
• 运行 systemctl is-active chronyd，返回 active 才算在跑
• 运行 systemctl is-enabled chronyd，返回 enabled 才算开机自启
• 若任一命令返回 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：没有它，时钟偏差超过 1 秒时 chronyd 只会缓慢调整，导致日志时间错乱、证书报错
• 删除或注释 rtcsync：云主机或容器里硬件时钟不可靠，写回 RTC 反而引入误差；除非你明确管理物理服务器且需持久化时间

linux-performance-analyzer

Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。

下载

用 chronyc 而不是 timedatectl 查同步状态

timedatectl status 只告诉你 “synchronized: yes/no”，掩盖真实问题：
• chronyc tracking 显示当前偏移（Offset）、估计误差（Root delay）、频率漂移（Skew），这才是判断是否真同步的依据
• chronyc sources -v 列出所有源状态：* 是当前主用源，+ 是备用，? 表示无法访问（常见于云环境防火墙拦截或 DNS 不通）
• chronyc makestep 可手动触发一步校正——仅当配置中存在有效 makestep 行时才生效
• 注意：chronyc 默认只接受本地 socket 连接，远程调用需额外配 cmdport 0 并开防火墙，一般没必要

云服务器或容器里同步失败的典型原因

很多用户卡在 Leap status : Not synchronised，其实和配置无关，是环境限制：
• AWS EC2、阿里云 ECS 等公有云禁止直连公网 NTP，必须用内网地址，例如：
server 169.254.169.123 iburst（AWS）
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 校验等环节引发连锁故障。