chrony sources 显示 unreachable 的最常见原因是 UDP 123 端口被防火墙拦截，尤其在启用 firewalld 的 CentOS/RHEL 8+ 或 Fedora 系统中；需确认 active zone、正确添加永久 ntp service 并重载，且注意 default zone 与 chronyd 绑定接口 zone 一致。
chrony sources 显示 unreachable 的常见原因
chrony sources 输出中出现 unreachable，不等于时间服务器真的宕机或网络不通，更多是 chrony 无法收到 NTP 响应包。UDP 端口 123 被防火墙拦截是最高频原因，尤其在 CentOS/RHEL 8+、Fedora 或启用 firewalld 的系统上。注意：即使你执行了 firewall-cmd --add-service=ntp，也不代表一定生效——该命令只对默认 zone 生效，且未加 --permanent 时重启 firewalld 就会丢失。
检查并放行 UDP 123 的正确步骤
先确认当前 active zone：
firewall-cmd --get-active-zones
再检查该 zone 是否已允许 ntp 服务：
firewall-cmd --zone=public --list-services
如果输出不含 ntp，需补全两步（缺一不可）：
firewall-cmd --zone=public --add-service=ntp --permanentfirewall-cmd --reload
不要只用 --add-port=123/udp 替代 --add-service=ntp：后者还隐含了 helper 模块支持（如 conntrack 对 NTP 的状态跟踪），对 NAT 或复杂路由场景更可靠。
chrony 自身配置与防火墙的协同要点
chrony.conf 中若用了 pool 或 server 指向公网地址（如 pool pool.ntp.org iburst），chrony 默认以客户端身份发请求，只需本机出站 UDP 123 放行（即上述 ntp service），无需开入站端口。但如果你启用了 allow 指令（例如 allow 192.168.1.0/24），那是为让本机 chrony 充当 NTP 服务器供局域网其他机器同步——此时才需要额外开放入站 UDP 123，并确保 allow 规则与实际客户端网段匹配。误配 allow 会导致本地 chronyc sources -v 正常，但其他机器始终显示 unreachable。
验证是否真通：绕过 chrony 直接测连通性
用 nc 或 timeout + echo 手动发一个最小 NTP 请求包（仅检测链路层可达性）：
printf '\x1b' | nc -u -w 2 2.centos.pool.ntp.org 123 | hexdump -C
若无输出或超时，说明防火墙或中间网络仍阻断；若有类似 00000000 1c 00 04 e9 00 00 00 00 00 00 00 00 00 00 00 00 |................| 的响应，则问题不在链路层，需查 chrony 日志（journalctl -u chronyd -n 50）或 DNS 解析（dig +short pool.ntp.org）。别依赖 ping ——NTP 是 UDP，ICMP 通不代表 UDP 123 通。
真正容易被忽略的是：firewalld 的 default zone 可能不是 public（比如是 trusted 或自定义 zone），而 chronyd 进程启动时绑定的接口可能落在另一个 zone 下；这种情况下，光配 public zone 的 ntp service 毫无作用。
firewall-cmd --get-active-zones再检查该 zone 是否已允许 ntp 服务：
firewall-cmd --zone=public --list-services如果输出不含
ntp，需补全两步（缺一不可）：
firewall-cmd --zone=public --add-service=ntp --permanentfirewall-cmd --reload
--add-port=123/udp 替代 --add-service=ntp：后者还隐含了 helper 模块支持（如 conntrack 对 NTP 的状态跟踪），对 NAT 或复杂路由场景更可靠。
chrony 自身配置与防火墙的协同要点
chrony.conf 中若用了 pool 或 server 指向公网地址（如 pool pool.ntp.org iburst），chrony 默认以客户端身份发请求，只需本机出站 UDP 123 放行（即上述 ntp service），无需开入站端口。但如果你启用了 allow 指令（例如 allow 192.168.1.0/24），那是为让本机 chrony 充当 NTP 服务器供局域网其他机器同步——此时才需要额外开放入站 UDP 123，并确保 allow 规则与实际客户端网段匹配。误配 allow 会导致本地 chronyc sources -v 正常，但其他机器始终显示 unreachable。
验证是否真通：绕过 chrony 直接测连通性
用 nc 或 timeout + echo 手动发一个最小 NTP 请求包（仅检测链路层可达性）：
printf '\x1b' | nc -u -w 2 2.centos.pool.ntp.org 123 | hexdump -C
若无输出或超时，说明防火墙或中间网络仍阻断；若有类似 00000000 1c 00 04 e9 00 00 00 00 00 00 00 00 00 00 00 00 |................| 的响应，则问题不在链路层，需查 chrony 日志（journalctl -u chronyd -n 50）或 DNS 解析（dig +short pool.ntp.org）。别依赖 ping ——NTP 是 UDP，ICMP 通不代表 UDP 123 通。
真正容易被忽略的是：firewalld 的 default zone 可能不是 public（比如是 trusted 或自定义 zone），而 chronyd 进程启动时绑定的接口可能落在另一个 zone 下；这种情况下，光配 public zone 的 ntp service 毫无作用。
nc 或 timeout + echo 手动发一个最小 NTP 请求包（仅检测链路层可达性）：
printf '\x1b' | nc -u -w 2 2.centos.pool.ntp.org 123 | hexdump -C若无输出或超时，说明防火墙或中间网络仍阻断；若有类似
00000000 1c 00 04 e9 00 00 00 00 00 00 00 00 00 00 00 00 |................| 的响应，则问题不在链路层，需查 chrony 日志（journalctl -u chronyd -n 50）或 DNS 解析（dig +short pool.ntp.org）。别依赖 ping ——NTP 是 UDP，ICMP 通不代表 UDP 123 通。
真正容易被忽略的是：firewalld 的 default zone 可能不是 public（比如是 trusted 或自定义 zone），而 chronyd 进程启动时绑定的接口可能落在另一个 zone 下；这种情况下，光配 public zone 的 ntp service 毫无作用。
