有效server行必须含iburst参数，如server ntp1.aliyun.com iburst，且需搭配至少两个不同源、避免混用pool/server；域名须dns可解析，内网推荐固定ip加server，多源防单点失效。
chrony.conf 里怎么写 server 行才有效
直接填 server ntp1.aliyun.com iburst 是最常见也最容易出错的写法。关键不是“能不能连上”，而是 chrony 是否真把它当有效源参与投票和校准。
必须带 iburst —— 它让 chrony 在初始同步时发 8 个包而不是 1 个，大幅缩短首次收敛时间；不加的话，第一次同步可能卡住几十秒甚至失败。
-
server后面跟域名或 IP 都可以，但域名需确保 DNS 可解析（dig ntp1.aliyun.com +short要能返回地址） - 国内推荐优先级：国家授时中心
ntp.ntsc.ac.cn> 阿里云ntp1.aliyun.com> 腾讯云time1.tencentyun.com - 至少写 2 个不同源，避免单点失效；最多别超 6 个，太多反而增加调度开销
- 不要混用
pool和server——pool是自动解析多个子域名，适合公网环境；内网固定 IP 场景一律用server
为什么 chronyc sources -v 显示 SYNCED 却 tracking 里 offset 还有 ±50ms
这不代表配置错了，而是 chrony 的渐进式校准策略在起作用。它默认不跳变时间，而是靠微调系统时钟频率来“追”回来，所以 offset 短期内存在是正常的。
真正要关注的是 chronyc tracking 输出里的 Offset、Root dispersion 和 System clock 三列：
-
Offset持续大于 ±100ms，说明上游不准或网络抖动大 -
Root dispersion超过 1000ms，意味着整个 NTP 树链路延迟过高，得换更近的源 -
System clock显示OK才算真正稳住；如果是NOT SYNCED或UNRELIABLE，说明没选中任何可用源
内网部署时 allow 指令写错会彻底拒绝客户端
如果你打算让这台机器当内网时间服务器，allow 不是可选项，是必填项。漏写或写错网段，客户端发来的 NTP 请求会被静默丢弃，chronyc sources 在客户端查不到这个服务端。
- 语法必须是
allow 192.168.10.0/24，不能写成allow from 192.168.10.0/24或allow 192.168.10.* - 如果允许所有内网，写
allow 0.0.0.0/0风险太大，建议严格限定到实际业务网段 - 修改后必须
sudo systemctl restart chronyd，reload 不生效 - 防火墙也要放通 UDP 123 端口：
sudo ufw allow 123/udp或sudo firewall-cmd --add-port=123/udp --permanent
systemd-timesyncd 和 chronyd 冲突时谁该让位
systemd-timesyncd 是轻量客户端，chronyd 是完整实现，二者不能共存。一旦 chronyd 启动，systemd-timesyncd 必须停用，否则会抢着改系统时钟，造成反复震荡。
- 检查是否运行：
systemctl is-active systemd-timesyncd，输出active就得关 - 停用并屏蔽：
sudo systemctl disable --now systemd-timesyncd - 确认没残留进程：
ps aux | grep timesync，有就 kill 掉 - 某些 Ubuntu 发行版默认启用它，装完 chrony 后这步最容易被跳过
真正麻烦的不是配置本身，而是不同服务之间对硬件时钟（RTC）的写入节奏不一致——chronyd 默认启用了 rtcsync，而 systemd-timesyncd 不写 RTC，混用会导致重启后时间倒退或跳跃。
