chronyc tracking Root delay / dispersion 异常大的 NTP 源更换方案

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 里带 *，但 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 行，防止服务重启后重新加载坏源

注意：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 导致故障源可能被客户端长时间复用（尤其容器或云主机）

生产环境建议明确指定 3–4 个已验证的优质源（优先选中科院、阿里、腾讯、华为云等有公开 SLA 的 NTP 服务），并定期用 chronyc sourcestats 检查它们的 Skew 和 Update interval 是否合理。真正的难点不在换源，而在持续监控哪些源开始“悄悄变慢”。