stratum 16 表示 chronyd 明确拒绝使用该源，源于响应超时、校验失败、显式禁用或网络路径异常；ntpdate 因单次强制校准且无状态校验而能通，chronyd 则要求稳定双向通信与多轮验证。
chrony sources 显示 stratum 16 是什么信号
chrony sources 中看到 stratum 16，代表 chronyd 认为该源当前不可用——这不是“还没同步成功”，而是明确拒绝使用它。NTP 协议中 stratum 16 是“未同步”（unsynchronized）的保留值，chronyd 在以下情况会主动标为 16：
• 源响应超时（默认 3 秒无应答）
• 源返回的 NTP 包校验失败（如 MAC 不匹配、时间戳异常）
• 源被显式禁用（offline 或 burst 失败后退避）
• 网络路径存在 ICMP 重定向、TTL 截断或中间设备丢弃 NTP UDP 包（尤其在容器/云环境里很常见）
为什么 ntpdate 能通而 chronyd 不行
ntpdate 是单次强制校准工具，不依赖持续连接或状态机：它发一次包、等一次回包、算一次偏移、直接写系统时钟。chronyd 则是守护进程，要求稳定双向通信和多轮测量才能进入同步状态。
• ntpdate 默认用 -u（无特权端口），chronyd 默认用 123 端口（需 root + 防火墙放行）
• ntpdate 不检查 stratum 或 root delay，chronyd 会严格过滤高延迟、高离散度、低可信度源
• 某些 NTP 服务器（如 pool.ntp.org 子集）会限速或丢弃高频请求，chronyd 的默认轮询间隔（64–1024 秒）可能触发限流，而 ntpdate 只打一次就走
排查 delay 极大但 ntpdate 正常的关键点
先确认是不是网络层问题而非 chrony 配置错误：
• 用 chronyc tracking 查看 Last offset 和 RMS offset 是否持续为 0 或 NaN
• 运行 chronyc -n sources -v，观察 ^*（当前选中的源）是否存在；若全是 ^- 或 ^? ，说明没一个源通过初始筛选
• 手动测试连通性：nc -uz <source_ip> 123</source_ip>（UDP 连通性）、tcpdump -i any port 123 -c 4（确认收发包是否对称）
• 检查 /etc/chrony.conf 中是否误加了 offline、iburst 缺失、或 maxdelay 设得过小（如 maxdelay 0.1 会直接踢掉所有公网源）
chronyd 同步失败但 ntpdate 成功的典型修复操作
不要直接删 chrony 改用 ntpdate——后者已废弃且破坏系统时间稳定性。优先做这些：
• 在 /etc/chrony.conf 中为公网源显式添加 iburst（加速初始同步）和放宽容忍：
server time1.google.com iburst maxdelay 1.0 server time2.google.com iburst maxdelay 1.0
• 若在 Docker 或 WSL 中运行，加上
makestep 1 -1 允许大步进校正，并确保宿主机没禁用 UDP 123• 临时关闭防火墙测试：
sudo ufw disable（Ubuntu）或 sudo systemctl stop firewalld（RHEL）• 换用更稳定的源：避免
pool.ntp.org（DNS 轮询不可控），改用具体 IP 或 time.cloudflare.com（支持 NTS）
chronyd 的 stratum 16 和巨大 delay 往往不是配置写错了，而是它比 ntpdate 更早、更严格地暴露了网络路径或服务端的隐性问题——比如某台 NTP 服务器只响应单次查询、某个云厂商安全组悄悄限 UDP 包速率、或者本机 iptables 有 OUTPUT 链规则干扰了 NTP 包的源端口复用。 
