Root delay 或 Root dispersion 异常大说明上游 NTP 源不可靠,可能因过载、拥塞、防火墙干扰或自身未同步;常伴 Leap status: Not synchronised 等报错,导致系统时间漂移或跳变。

chronyc tracking 显示 Root delay 或 Root dispersion 异常大,说明什么
chronyc tracking 中 Root delay(通常应 Root dispersion(理想值 500 ms 或几秒),基本意味着当前 NTP 源已不可靠:可能是上游服务器过载、网络路径拥塞、中间防火墙干扰,或该源本身未良好同步(例如它自己也只连了单个不稳定的上游)。这不是 chrony 配置错误,而是源头质量崩了。
这类异常往往伴随 Leap status: Not synchronised 或 System clock wrong by 报错,系统时间会缓慢漂移甚至跳变。
如何用 chronyc 快速识别问题 NTP 源
chronyc sources -v 和 chronyc sourcestats -v 是关键命令:
-
sources -v 看每个源的状态:* 表示当前选中的主源,+ 是候选源,? 或空白表示被拒绝(通常是抖动过大或离群)
-
sourcestats -v 查看每个源的长期统计:Offset 偏移量是否稳定、RMS offset 是否持续升高、RTT(往返时延)是否忽高忽低——这些比单次 tracking 更能暴露问题
- 特别注意
Source state 字段:若长期显示 Offline 或 Lost,说明 chrony 已主动弃用该源,但配置里还留着,容易误导
sources -v 看每个源的状态:* 表示当前选中的主源,+ 是候选源,? 或空白表示被拒绝(通常是抖动过大或离群)sourcestats -v 查看每个源的长期统计:Offset 偏移量是否稳定、RMS offset 是否持续升高、RTT(往返时延)是否忽高忽低——这些比单次 tracking 更能暴露问题Source state 字段:若长期显示 Offline 或 Lost,说明 chrony 已主动弃用该源,但配置里还留着,容易误导如果某个源在 sources 里带 *,但 sourcestats 显示其 RTT 波动剧烈、RMS offset > 100 ms,基本可以判定它是“假主源”——chrony 因缺乏更好选择而被迫用它。
更换 NTP 源的实操步骤(不重启 chronyd)
更换不是简单改 /etc/chrony.conf 再 systemctl reload chronyd,要避免时间跳变和短暂失同步:
- 先用
chronyc add server 加入新源(例如国内可用 ntp.ntsc.ac.cn 或阿里云 ntp.aliyun.com),加 iburst 和 prefer(仅对可信源):chronyc add server ntp.ntsc.ac.cn iburst
- 等 2–3 分钟,运行
chronyc sources -v 确认新源状态变为 + 或 *,且 sourcestats 中 RMS offset 开始收敛(
- 再用
chronyc delete 移除旧源(不是注释配置文件!):chronyc delete 2001:db8::1
(填实际 IP 或域名)
- 最后更新配置文件,删掉对应
server 行,防止服务重启后重新加载坏源
chronyc add server 加入新源(例如国内可用 ntp.ntsc.ac.cn 或阿里云 ntp.aliyun.com),加 iburst 和 prefer(仅对可信源):chronyc add server ntp.ntsc.ac.cn iburst
chronyc sources -v 确认新源状态变为 + 或 *,且 sourcestats 中 RMS offset 开始收敛(
chronyc delete 移除旧源(不是注释配置文件!):chronyc delete 2001:db8::1(填实际 IP 或域名)
server 行,防止服务重启后重新加载坏源注意:iburst 只在初始同步时加速,不会影响后续行为;prefer 要慎用——仅当新源是组织内高精度本地 NTP 服务器时才加,否则可能压制更稳定的公网源。
为什么不能只依赖 public NTP pool(如 pool.ntp.org)
pool.ntp.org 是 DNS 轮询机制,每次解析返回不同 IP,看似冗余,实则隐患不少:
- 某些子域名(如
0.pool.ntp.org)在部分地区解析到海外高延迟节点,Root delay 直接破秒
- 部分 pool 成员未启用
ntpd -g 或未正确配置 stratum,导致自身同步质量差,chrony 会误判为可用源
- DNS 缓存 + TTL 导致故障源可能被客户端长时间复用(尤其容器或云主机)
0.pool.ntp.org)在部分地区解析到海外高延迟节点,Root delay 直接破秒ntpd -g 或未正确配置 stratum,导致自身同步质量差,chrony 会误判为可用源生产环境建议明确指定 3–4 个已验证的优质源(优先选中科院、阿里、腾讯、华为云等有公开 SLA 的 NTP 服务),并定期用 chronyc sourcestats 检查它们的 Skew 和 Update interval 是否合理。真正的难点不在换源,而在持续监控哪些源开始“悄悄变慢”。










