内网ntp服务器需确保时区正确、上游时间源稳定、客户端访问权限开放；否则ntpq -p显示no association，ntpstat提示unsynchronised。
内网NTP服务器不是装上ntpd就能用的，关键在三点：时区对、上游源稳、客户端权限开对；否则ntpq -p永远显示no association，ntpstat一直提示unsynchronised。
确认系统时区和硬件时间是否一致
很多同步失败根本不是NTP配置问题，而是本地时钟基准错了。Linux有两套时间：系统时间（由内核维护）和硬件时间（CMOS里存的）。如果两者偏差大，ntpd启动时会拒绝同步，直接退出。
- 检查当前时区：
timedatectl | grep "Time zone"，确保是Asia/Shanghai这类合法值，不是UTC或空 - 强制设为上海时区：
ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime，再执行hwclock --systohc把系统时间写入硬件时钟 - 别信
date命令输出——它只显示系统时间，hwclock --show才能看到BIOS里实际存的时间；两者差超过15分钟，ntpd大概率不干活
ntp.conf里server和restrict必须配对生效
restrict规则不是“加了就放行”，它和server条目是独立解析的。常见错误是只写了restrict 192.168.100.0 mask 255.255.255.0 nomodify notrap，却忘了让本机也能作为时间源——结果客户端能连上UDP 123端口，但收不到有效响应。
- 服务端必须显式声明本地时钟源：
server 127.127.1.0+fudge 127.127.1.0 stratum 10，stratum值要大于上游服务器（比如pool.ntp.org通常是stratum 2），否则客户端会拒收 -
restrict default kod nomodify notrap nopeer noquery这行是默认拒绝，后面加的restrict 10.0.0.0 mask 255.255.255.0 nomodify notrap才真正放行内网段——顺序不能颠倒 - 防火墙必须放UDP 123：
iptables -I INPUT -p udp --dport 123 -j ACCEPT，用-I插到最前，避免被其他REJECT规则拦截
客户端不能只靠crontab跑ntpdate
用ntpdate + crontab看似简单，但每次都是“跳变”校时：如果系统时间快了3分钟，ntpdate一执行，所有cron任务可能重复触发，日志时间戳断裂，Kafka或ZooKeeper这类对时钟敏感的服务直接报session expired。
- 生产环境客户端应统一用
ntpd服务，而非ntpdate脚本；启动前先手动同步一次：ntpdate -u 10.0.0.111 && hwclock --systohc，再systemctl start ntpd - 客户端
/etc/ntp.conf只需保留一行server 10.0.0.111 iburst，iburst参数能让首次同步更快建立关联 - 验证是否真同步：
ntpq -p输出中，*号指向的行才是主用源，且reach列应为非零（如377），delay和offset值稳定在毫秒级才算可靠
ntpd和chrony不能共存，选型要看场景
RHEL/CentOS 7+ 默认预装chronyd，如果你强行yum install ntp并启用ntpd，两个服务会争抢UDP 123端口，systemctl start ntpd直接失败，报错Address already in use。
- 查清当前用的是谁：
systemctl list-unit-files | grep -E "(ntp|chrony)"，若chronyd.service是enabled，先systemctl disable chronyd && systemctl stop chronyd -
chrony更适合虚拟机、笔记本等网络不稳定的环境；ntpd在物理机局域网内延迟更稳，ntpq -p生态也更成熟 - 别混用：客户端用
ntpd，服务端却用chronyd，虽然协议兼容，但stratum传递、makestep行为差异会导致部分客户端同步失败
真正卡住人的往往不是配置语法，而是ntpq -p里那个没星号的空行，或者journalctl -u ntpd里一句不起眼的kernel reports TIME_ERROR: 0x41: Clock Unsynchronized——这意味着硬件时钟本身已失准，得先修底层，再调NTP。
