chrony 显示 stratum 16 表示主动拒绝同步，非网络不通，而是因严格校验 stratum、leap 状态、refid 自引用或 maxdistance 超限；ntpdate 则无视协议规则直接跳变时间。
chrony 显示 stratum 16 但 ntpdate 成功：根本原因不是“谁更准”，而是“谁更宽容”
chrony 拒绝同步并标记为 stratum 16，通常不是服务器坏了，而是它严格遵守 NTP 协议的分层规则和质量阈值；而 ntpdate 是个“粗暴但有效”的一次性工具，不校验 stratum、不检查 leap 状态、也不管 refid 是否循环或异常——只要 UDP 包能来回，就硬算偏移量然后跳变时间。
典型现象：chronyc sources -v 中看到 ^? 172.42.12.35（问号表示 rejected），stratum 16，leap 11（意味着告警+未同步），而同一台机器上执行 ntpdate -d 172.42.12.35 却显示 offset 0.108391 sec 并返回成功。
stratum 16 的真实含义：chrony 已判定该源“不可信”，不是“没连上”
NTP 协议中 stratum 16 表示“未同步状态”，是 chrony 主动赋予的“拒绝标签”，常见触发条件包括：
-
server返回的stratum ≥ 16（如 Windows W32Time 默认返回stratum 16，除非显式配置AnnounceFlags=5） - 响应中
leap字段为11（clock unsynchronized）且 chrony 未启用trust选项 - 参考 ID（
refid）指向自身（如[172.42.12.35]），被识别为“自引用”或“虚假层级” -
maxdistance超限（默认 1.0 秒），而实测delay达到几十甚至上百毫秒（跨境链路常见）
注意：stratum 16 不代表网络不通——日志里能看到连续的 transmit/receive，只是 chronyd 主动丢弃了这些响应。
为什么 ntpdate 能过，chrony 却卡住？关键在三处配置开关
chrony 默认行为比 ntpdate 保守得多，要让它接受“非标”或“高延迟”源，必须显式打开对应宽容机制：
将提醒同步至 Windows/Outlook 日历。用户提及「提醒我」「设置提醒」「加到日历」「同步到日历」「日程」「calendar」「日历」时触发。支持Microsoft Graph API 设备代码流认证，无需 Web 服务器，直接写入用户 Outlook 日历。
- 加
trust参数：在/etc/chrony.conf中写server 172.42.12.35 iburst trust，绕过stratum和leap校验（适用于 W32Time 或老旧 NTP 设备） - 调高
maxdistance：例如maxdistance 16.0，允许更大网络抖动（海外 VPS 同步时必备） - 禁用
makestep干扰：若已用makestep 1.0 -1强制跳变，反而可能让 chronyd 在首次同步失败后拒绝后续尝试；建议先注释掉，确认源可用后再启用
对比命令行为：ntpdate -q 172.42.12.35 只做单次测量 + 跳变，chronyd 则需持续观测 offset、delay、jitter 的稳定性，任一指标越界即降级。
延迟极大（delay > 100ms）却仍不同步？别只盯 minpoll/maxpoll
看到 filter delay: 0.23456（234ms）还稳如泰山？那大概率是 chrony 认为这个延迟“不可靠”，直接放弃滤波计算。此时调整 minpoll 6（64 秒）或 maxpoll 9（512 秒）没用——轮询再勤快，数据质量不过关也白搭。
真正该查的是：
-
chronyc tracking输出中的Root dispersion是否持续 >maxdistance - 防火墙是否对 UDP 123 做了速率限制（尤其云厂商安全组）
- 目标服务器是否启用了
ntpd -n -u ntp:ntp -p /var/run/ntpd.pid -g类似参数导致响应异常 - 用
tcpdump -i any port 123 and host 172.42.12.35看 response 包里stratum字段原始值
chrony 的“慢”不是缺陷，是它把协议校验、网络适应、时钟建模全包进去了；而 ntpdate 只干一件事：算完就跳。选哪个，取决于你要的是“一次准”，还是“一直稳”。
