麒麟V10SP3内网NTP时间同步实战：chrony配置与故障排查

服务器集群跑了两年多，最近一次故障排查差点把我逼疯。业务方报“登录偶尔失败”，开发查了一圈觉得是认证超时，最后翻日志才发现，这批机器的系统时间前后差了快三分钟，证书校验直接失效。从那天起我就明白了，内网里跑着的数据库、容器、日志采集、消息队列看着各干各的，其实全都在悄悄依赖同一套时间基准。谁要是慢了半拍，故障只是早晚的区别。

麒麟服务器操作系统V10SP3自带的工具链里，NTP服务器配置这件事其实不复杂，但要做好、做稳、能在生产环境里扛住，有不少细节值得单独聊聊。这篇主要分享我实际配置NTP服务端和客户端的过程，包括选chrony而不是纯ntpd的理由、配置文件每行的含义、常见坑的排查方法，以及一些常规文档里不会写的小经验。

1. 场景分析与方案选型：为什么内网需要自建NTP服务器

1.1 时间不同步到底会引发什么问题

很多人觉得时间同步是小事，系统装完默认就能走网络时间，何必自己搭一台NTP服务器。但真正上了规模的内网环境，你会发现时间误差带来的连锁反应非常磨人。

第一类是日志审计问题。多台机器的日志汇聚到集中平台之后，如果时间轴对不上，同一个用户操作在A机器上是10点02分，在B机器上却显示10点04分，追踪一次越权访问要来回比对半天，效率极差。安全部门做审计时，时间不一致基本等于日志不可信。

第二类是数据库和分布式系统问题。MySQL主从复制靠时间戳判断事务顺序，Redis哨兵选主时也要比较候选节点的时钟偏移，Kafka消息的时间戳错乱会直接影响窗口计算逻辑。业务上的表象延迟，底层往往就是时钟漂移。

第三类是证书和票据相关的问题。HTTPS证书的有效期校验、Kerberos票据的生成与验证，都严格依赖两端时间一致。一旦偏移超过允许范围，轻则访问报错，重则整个集群内互相不认账，表现就是“明明账号密码都对，却一直认证失败”。

还有一类容易被忽略的，就是定时任务调度。内网很多服务器的crontab是在凌晨某个固定时间点批量执行，如果机器间时间差异大，同一批次任务的实际执行顺序和预期不一致，容易引发资源竞争和数据覆盖。

内网机器访问外网NTP服务器往往受网络策略限制，或UDP 123端口被防火墙拦掉。就算能出网，公网授时链路延迟和抖动也不稳定。所以在内网部署一台层级较高的本地NTP服务器，让所有机器向它同步，是最标准、最可控也最好排查的做法。

1.2 chrony与ntpd的取舍

麒麟V10SP3默认支持两种主流的NTP实现：传统ntpd和chrony。新装系统一般默认带chrony，但很多从老版本升上来的机器还在跑ntpd。我个人的建议是：新配置环境优先选chrony，除非业务上有特殊约束必须用ntpd。

从同步效果上看，chrony的明显优势在于启动后同步速度快。传统ntpd启动时要先花几分钟甚至更久来逐步调整，期间系统时间可能一直不准确；而chrony可以在数秒内完成大幅调校，对“开机即需要正确时间”的业务非常友好。

从抗干扰能力看，chrony对网络延迟抖动和丢包的处理更聪明。它不急于死磕某一次测量结果，而是综合多个样本做统计，能自动识别并忽略异常值。实际内网环境里偶尔出现网络拥塞，chrony的稳定性明显更好。

从代码维护状态看，chrony是当前Linux发行版的主流方向，RHEL、Debian这些上游都在推chrony替代ntpd，安全修补更及时。麒麟V10SP3的软件源里chrony版本也比较新，用起来更省心。

当然ntpd也有它的场景：某些第三方监控工具或老版本Oracle集群强制依赖ntpd的某些行为，那就不得不保留。但如果你没有这种历史包袱，直接选chrony。

2. 配置前的环境准备与初始化检查

2.1 确认系统版本与基础状态

进到一台麒麟V10SP3机器上，我习惯先做一轮基础检查，确保系统状态干净再动手。注意有些机器可能是ARM架构（海光、鲲鹏、飞腾）或x86架构，命令上没有太大区别，但软件源和内核特性稍有不同。

bash复制cat /etc/os-release
uname -m
timedatectl status

第一次配置时务必先确认操作系统版本是V10SP3，不同SP版本之间仓库软件版本有差异。再用timedatectl看看当前的系统时间、时区、RTC（硬件时钟）设置。NTP配置只是让系统时间与标准源保持一致，如果时区本身就是错的，同步出来的绝对时间也会错，所以这步一定要先处理。

2.2 时区设置与硬件时钟处理

服务器时区常见问题是UTC还是CST混乱。生产环境里我建议把业务机器统一设置为Asia/Shanghai，避免排查日志时还要做UTC转换。

bash复制timedatectl set-timezone Asia/Shanghai

执行后建议再看一眼，确认“Time zone”那一行已经变成Asia/Shanghai。有些基础的运维同学只会date命令，改完软件包重启之后发现时间又不对，其实就是漏了硬件时钟的设置。

麒麟系统里的RTC通常默认使用UTC作为基准，而Windows早期用的是本地时间。如果这台机器有双系统需求，就要额外注意RTC的localtime设置。纯Linux场景直接保持默认即可，不会对NTP产生直接影响。

bash复制# 查看硬件时间
hwclock -r
# 同步系统时间到硬件时钟
hwclock -w

在NTP服务正常运行的情况下，系统时间最终会由chrony维护，硬件时钟就只负责开机引导阶段提供一个初始值。所以先让系统时间正确，再把正确的系统时间写入硬件时钟，这样重启后即使NTP网络暂时不通，机器也基本不会跑偏。

2.3 安装与确认NTP相关软件包

麒麟V10SP3默认可能没有安装chrony，需要先从软件源安装。

bash复制dnf install -y chrony
systemctl enable chronyd --now

有一点要提醒：如果你之前手动装过ntpd，建议及时停用并mask掉，避免两个时间服务同时运行互相抢占123端口。chronyd和ntpd同时跑起来，日志里会出现端口被占用的报错，系统时间也可能被两边反复拉扯。

bash复制systemctl stop ntpd
systemctl disable ntpd
systemctl mask ntpd

有些机器还装了NetworkManager的时间同步功能。麒麟桌面版默认开启，服务器版不一定，但保险起见还是检查一下，避免NetworkManager在网卡重连时偷偷用DHCP下发的NTP服务器覆盖你的配置。可以临时关掉nmcli的网络时间同步，或者直接通过配置NetworkManager禁用。

bash复制nmcli connection show
# 如果自动同步开启，可以设置
nmcli con mod <连接名> ipv4.ignore-auto-dns yes  # 这只是示例，时间同步通过config禁用

更常见的做法是直接编辑NetworkManager配置文件，把NTP相关的自动设置关闭。这块不是所有场景都会遇到，但我在桌面版麒麟V10SP3上确实踩过坑：明明把chrony的server指向内网服务器，网卡一重启又跳到外网源去了，折腾半天才发现是NetworkManager在捣乱。

3. 服务端配置：搭建内网授时源

3.1 主配置文件逐行拆解

服务端的核心工作就是把/etc/chrony.conf改好。这个配置文件不算长，但每一行都很关键。下面这份是我在一套生产环境用的配置，比较通用，逐行说明一下。

bash复制# 上游时间服务器，这里用的是国内公共NTP
server ntp.aliyun.com iburst
server ntp1.aliyun.com iburst

# 允许内网网段访问本机NTP服务
allow 192.168.10.0/24
allow 10.10.0.0/16

# 本地时钟作为兜底
local stratum 10

# 记录本机与上游的漂移率
driftfile /var/lib/chrony/drift

# 让系统时钟逐渐调整，而不是突然跳变
makestep 1 -1

# NTP客户端访问端口
port 123

# 允许的客户端数量日志
logdir /var/log/chrony

先解释最核心的几行。

server ntp.aliyun.com iburst这一行设置了本机上游时间服务器。作为内网NTP服务器的这台机器，自身还是要从更权威的公共源获取标准时间，然后再对内提供服务。iburst表示客户端在启动后的前四次同步请求会快速连续发出，让初次同步能秒级完成。如果内网这台服务器本身无法访问外网，那这一行也可以替换成本地其他可靠时间源，或者干脆不配置上游，只用local兜底。

allow 192.168.10.0/24这行决定了哪些客户端能访问本机的NTP服务。格式是allow <网段/掩码>，注意这里不是NTP协议里标准的restrict写法，而是chrony自己的allow语法。allow后面跟的是客户端源地址范围，要让哪个网段的机器能同步，就写哪个网段。一个常见的误区是写成allow 0.0.0.0/0，虽然也能通，但等于对所有主机开放时间查询，内网里最好收敛到具体网段。

local stratum 10是给本机一个本地层的兜底。当所有上游服务器都不可达时，chrony会对外宣告本机的stratum级别为10，让客户端仍然可以从它同步到时间。注意这个数字不是随便定的，它表示本机时间层级。真实上游时间源层数为0，从公网NTP服务器同步后本机层数为2左右，如果上游丢失就用本地时钟兜底，层数定为10是一种常见做法。客户端看到这个层级时，会认为时间源仍然可用，但优先级会低于其他正常同步源。

makestep 1 -1是控制时间调整方式的。说明当系统时间与实际时间偏差超过1秒时，直接步进调整，且没有任何限制条件（最后一个-1表示仅有第一次步进限制，实际上不限制）。如果配置成makestep 1 3，意思是只有前三次同步允许步进调时间，之后只能靠微调一点点磨。内网服务器刚启动时可能偏差比较大，用这个配置可以让它在启动后快速校准，不至于花几十分钟慢慢爬。

接着启动服务：

bash复制systemctl restart chronyd
systemctl enable chronyd

重启后查看启动状态：

bash复制systemctl status chronyd

如果服务是running状态，再进一步验证：

bash复制chronyc sources -v
chronyc tracking

chronyc sources -v能列出每个上游源的同步情况，正常状态应该是^*或^+。^*表示当前选中的同步源，^+表示可作为备选同步源。如果显示^?或者一直停在^?不动，说明源不可达，优先排查网络和防火墙。

3.2 防火墙与SELinux处理

麒麟服务器操作系统默认开启firewalld和SELinux，这两个若不处理干净，服务端配置再对客户端也会失败。

NTP服务使用UDP 123端口，需要在防火墙放行：

bash复制firewall-cmd --permanent --add-service=ntp
firewall-cmd --reload

或者更直白的按端口放行：

bash复制firewall-cmd --permanent --add-port=123/udp
firewall-cmd --reload

检查是否放行成功：

bash复制firewall-cmd --list-all

看到services里包含ntp或ports里包含123/udp就算成功。注意必须reload之后才生效，有些人改了永久配置却忘了reload，以为是配置无效，其实是还没加载。

SELinux方面，chronyd在麒麟V10SP3上通常有对应的SELinux策略，默认允许绑定NTP端口并读写配置文件。但如果你用自定义端口，或修改了日志目录，就可能触发SELinux拒绝。排查SELinux日志时，可以先看看：

bash复制ausearch -m avc -ts recent

如果出现chronyd相关的avc denied记录，可以通过调整布尔值或放行策略解决。生产环境我一般建议先确认SELinux状态，如果是Enforcing模式且出现拦截，再决定放开还是加策略，不要一上来就setenforce 0，安全基线还是要保留的。

3.3 服务端自检与本地同步验证

服务端配置完成后，先在本机验证一下能不能正常从上游同步时间。这一步很重要，本机都同步不了，后面客户端配置无从谈起。

bash复制timedatectl status
chronyc tracking

正常时chronyc tracking里能看到类似这样的输出：

text复制Reference ID    : 8F1D3D03 (ntp.aliyun.com)
Stratum         : 3
Ref time (UTC)  : Thu Mar 06 09:12:34 2025
System time     : 0.000042 seconds fast of NTP time
Last offset     : +0.000065 seconds
RMS offset      : 0.000089 seconds

这表示本机已经通过阿里云NTP服务器同步成功，当前机器自身层级为3。对外提供服务的本机，从上游同步到标准时间后再作为内网时间源，层级是上游+1。内网客户端从这台服务器同步后，层级还会再+1，只要层级不超过10，客户端一般都能正常接受。

再检查端口监听状态，确认123端口确实在监听：

bash复制ss -unlp | grep 123

输出中应该能看到chronyd进程在监听UDP 123。如果这里没有输出，前面firewalld放行就算白做了。这是服务端可用性最直接的判断依据。

4. 客户端配置：内网机器统一指向本地NTP服务器

4.1 客户端chrony配置

客户端配置相对简单，思路就是关掉公网NTP源，只指向内网NTP服务器。同样编辑/etc/chrony.conf：

bash复制# 指向内网NTP服务器
server 192.168.10.5 iburst

# 也允许被其他机器同步（可选）
# allow 192.168.10.0/24

# 本地兜底
local stratum 10

# 漂移记录文件
driftfile /var/lib/chrony/drift

# 快速调整
makestep 1 -1

配置中192.168.10.5换成你的NTP服务器地址。这里的客户端不再配置外网源，所有时间请求都走内网服务器。如果客户端本身也需要给其他机器提供同步服务，可以把allow解开，但大多数情况下客户端不需要。

保存后重启chronyd并设置开机自启：

bash复制systemctl restart chronyd
systemctl enable chronyd

接着立即检查同步状态：

bash复制chronyc sources -v
chronyc tracking

如果配置正确，chronyc sources里应该能看到指向192.168.10.5的记录，前面带^*表示当前在用这个源。如果是^?则表示尝试连接但没有成功，需要按第6章的排查思路去查。

4.2 客户端与server之间的单向时间修正

值得强调的是，客户端时间并不是机械地一下跳到服务器时间。chrony会根据多次往返测量计算出偏移量，然后既可以直接步进对齐，也可以慢慢调整时钟频率。普通业务机器用makestep 1 -1让它在偏差超过1秒时快速校准即可。但对于数据库集群这种对平滑性有要求的场景，更稳妥的做法是设置为makestep 1 3或者去掉快速步进，让时间通过微调逐渐逼近，避免时间瞬间跳变造成事务时间戳异常。

不少人在这一步会犯一个惯性错误：以为NTP配置完后，客户端时间会和服务器“随时保持一致”。其实NTP是一个周期性的轮询同步机制，不是实时镜像。默认轮询间隔在64秒到1024秒之间动态变化，客户端和服务器之间允许存在几十毫秒的合理偏差。真正需要毫秒级时间对齐的高频交易或分布式共识场景，还得上PTP，NTP不是干这个的。

4.3 客户端验证脚本与多机器批量部署

十几台机器手动改配置还行，几十台上百台再手动就太累了。我通常是写好一份配置模板，再用脚本批量分发并重启服务。要注意每台机器的主机名、静态IP、业务网段可能不同，模板里需要做对应的变量替换。

一个简单的批量部署思路，先准备好客户端配置文件模板chrony_client.conf：

bash复制server 192.168.10.5 iburst
driftfile /var/lib/chrony/drift
makestep 1 -1
local stratum 10
logdir /var/log/chrony

然后通过ansible或循环ssh分发过去。比如用ansible的copy模块和systemd模块批量下发，伪代码如下，具体可以根据自己的环境改：

yaml复制- name: 下发chrony客户端配置
  copy:
    src: chrony_client.conf
    dest: /etc/chrony.conf
    backup: yes
  notify: restart chronyd

- name: 启动并设置开机自启
  systemd:
    name: chronyd
    state: restarted
    enabled: yes

批量部署后，再批量执行一次chronyc sources -v收集关键行，检查有没有机器掉落。这里有一个非常好用的技巧：

bash复制for ip in $(cat server_list.txt); do
    echo "== $ip =="
    ssh root@$ip "chronyc sources -v | grep -E '\^\*|\^\?' | head -1"
done

只要每台机器都显示^* 192.168.10.5，基本就算全部到位。如果哪台显示^?，按第6章逐项排查。

5. 验证测试与效果评估：从命令到生产可用

5.1 timedatectl、chronyc、ntpq的配合使用

配置完成后光看服务状态还不够，建议从三个角度做交叉验证。

第一个看系统级状态，用timedatectl。重点关注：

text复制Local time: 四 2025-03-06 17:23:45 CST
Universal time: 四 2025-03-06 09:23:45 UTC
RTC time: 四 2025-03-06 09:23:44
Time zone: Asia/Shanghai (CST, +0800)
System clock synchronized: yes
NTP service: active

System clock synchronized: yes表示系统认为时钟已同步，NTP service: active表示NTP服务正常运行。这两项如果有一个不是预期状态，就要检查。

第二个看同步源状态，用chronyc sources -v。每列含义简单说一下：

• M列：^表示服务器，*表示当前选中的同步源
• S列：*表示正在使用的源，+表示可接受的备选源，?表示不可达或未同步
• 后面的Stratum列是源层级，Reachability为1表示最近8次轮询中成功了几次，8表示8次全部成功。

这两个命令配合基本能判断问题出在哪个环节。

第三个是兼容性验证，用ntpq -p。麒麟V10SP3通常也装了ntpdate工具，但chrony环境下ntpq不一定存在。如果某些老监控脚本要用ntpq，可以额外安装：

bash复制dnf install -y ntpstat ntpdate
ntpq -p 192.168.10.5

ntpq输出里的remote行会显示时间服务器地址，*或+表示正常候选源。如果报Connection refused，说明对方123端口不可达。

5.2 强制同步与手动校准的实战场景

有些机器首次接入NTP时，系统时间和标准时间偏差非常大，比如差了十几分钟甚至几个小时。这时即使配置了iburst，chrony也可能需要一段时间才能完成校准。如果希望立即生效，可以手工做一次强制同步。

bash复制chronyc makestep

这个命令会立即执行步进校准，不需要等轮询周期。但注意，生产环境执行前要评估一下时间跳变对业务的影响，特别是数据库、分布式任务、日志系统，时间跳变可能导致事务时间戳异常或告警风暴。我通常在业务低峰期操作。

如果是手动希望做一次性校准，也可以直接用ntpdate，但用完之后要停掉ntpdate进程，否则会跟chronyd抢时间调整权。

bash复制ntpdate 192.168.10.5

这个命令在chrony运行时一般不建议再长期使用，只适合一次性应急校准。执行完确认系统时间正确之后，再启动chronyd接管后续维护。

5.3 同步效果的长期稳定性验证

配置完成当天一般看不出问题，真正考验的是长期稳定性。我是习惯部署一周后回头看统计数据。

bash复制chronyc tracking

重点看RMS offset，一般内网环境下应该在几百微秒到几毫秒之间。如果RMS offset经常跳到几十毫秒，说明网络质量或NTP服务器配置有问题，需要复查网络的UDP丢包情况。

再看Last offset是每轮同步结束后的瞬时偏移。如果这个值忽正忽负且幅度较大，可能是上游公共NTP服务器网络链路抖动严重，此时可以考虑换一组上游源，或者在本机与上游之间增加一层透明代理让链路更稳定。

长期运行中还要留意driftfile记录的变化。chrony通过漂移文件保存了本机晶振频率的偏差估计，开机后可以快速恢复频率校准。如果drift文件丢失，开机后chrony要重新测量频率偏移，这段时间内时间精度会差一些，这是正常的，不用慌。

另外建议对NTP服务本身做一个简单的监控。比如zabbix或prometheus里加上UDP 123可达性检查、System clock synchronized状态、chronyc tracking中的RMS offset三个指标。我实际排查过好几次故障，都是靠监控看到某台客户端offset逐渐变大才提前处理，比等到业务报障再查从容得多。

6. 常见问题与故障排查实录

6.1 客户端显示^?或等待连接却同步失败

这是配置NTP后最常见的故障现象。客户端执行chronyc sources -v后，看到时间源前面是^?，同步完全不生效。

排查顺序我建议从内到外，不要一上来就去改配置。

第一步确认网络连通性。很多人在客户端上ping NTP服务器IP能通，就以为网络没问题。但NTP走的是UDP 123，ping是ICMP，两者不是一回事。需要检查三层可达后，还要看UDP端口是否被丢弃。

bash复制nc -uvz 192.168.10.5 123

如果UDP端口测试不通，直接去查防火墙规则。注意不只是服务端firewalld，客户端本身如果有iptables规则也会拦截出方向UDP 123。麒麟系统的firewalld默认策略一般是允许出方向，但有些加固过的服务器会加出方向白名单。

第二步查服务端。在服务端用ss -unlp确认chronyd正在监听UDP 123。有些场景下服务端装了多个版本NTP服务，chronyd没起来，ntpd占着端口，那客户端看到的就是另一套数据。

第三步查allow网段是否覆盖客户端。客户端IP如果在allow范围之外，chronyd会静默丢弃请求，客户端看起来就是“发出去没回应”。这个现象非常误导人，因为抓包能看到客户端在发NTP请求，但服务端就是不回包。

第四步查本机时间偏差。如果本机时间和标准时间偏差太大超过1000秒，chrony可能不会自动步进，同步显示一直处于等待状态。用chronyc makestep手动校准后再看。

6.2 leafClock says Use this server却始终不同步

还有一种情况比较隐蔽：服务端日志里显示leafClock says Use this server，客户端能收到回包但时间就是不改变。这类多半和NTP本身的时间戳处理有关，常见原因有两个。

第一个是服务端和客户端时间差非常大，比如客户端已经快了一个多小时，chrony默认出于安全考虑不进行大幅步进，只能缓慢调整。在生产里我们发现这样的机器重启后chronyd会认为时间源不可信，需要先手动校一次。

第二个是客户端系统时间在同步前就被频繁手动改过，本地漂移文件已经失真。处理方法是清除旧的drift文件，重新让chronyd建立频率模型。

bash复制rm -f /var/lib/chrony/drift
systemctl restart chronyd
chronyc makestep

6.3 配置正确但重启后NTP服务未随机启动

麒麟V10SP3的systemd服务管理一般靠enable来确认开机自启。如果发现重启后chronyd没有运行，先检查enable状态：

bash复制systemctl is-enabled chronyd

如果没有enable，执行enable并确认创建了软链接：

bash复制systemctl enable chronyd
ss -unlp | grep 123

还有一种情况是服务因为SELinux或文件权限原因启动失败。查看journal日志：

bash复制journalctl -u chronyd -b

我遇到过chrony反复启动失败，最后发现是/var/lib/chrony目录的SELinux上下文不对。可以恢复默认上下文解决：

bash复制restorecon -Rv /var/lib/chrony

这个坑在手动创建目录或复制配置文件的时候非常容易出现。用系统包管理器安装的chrony自带正确上下文，但如果你自己用tar包解压部署，很容易踩到这个点。

6.4 内网NTP服务器本身无法同步上游

当NTP服务器这台机器自身就无法从公网源同步时，内网客户端全都跟着遭殃。常见原因：这台机器被安全策略限制只能访问特定端口，UDP 123出方向被拦。

如果网络策略确实不允许访问外网，服务端配置要从server 公网地址改成local stratum 10，让本机成为独立时间源。注意这样配置后，本机时间是否准确完全取决于硬件时钟质量，并不是一个理想状态，建议改用GPS授时设备或允许特定出口端口放行公网NTP。

如果产品经理给力，开放公网出方向UDP 123，那就在服务端多配几个公共NTP源，例如阿里云、腾讯云、国家授时中心，iburst参数保留。多源的好处是当一个源不可用时，chrony会自动切换到另一个可用源，不会让时间同步断掉。

6.5 时间回跳与日志时间倒退

这个问题的本质是chrony用步进方式修正了大偏差，会导致时间瞬间前后跳动。日志系统如果依赖本地时间戳，会出现某个时间点日志突然跳回过去的诡异现象。对于日志一致性要求严格的环境，可以考虑调整makestep参数，让时间通过slew（慢慢调整）方式改变，而不是直接步进。

配置改成：

bash复制makestep 0 0

或者完全去掉makestep相关行。代价是同步收敛时间会变长，无法快速修正大偏差。具体取舍根据业务决定。我之前维护过一套交易系统，时间回跳影响很大，后来就选择了slew模式，并配合监控提前发现偏差，避免走到需要大步进的地步。

6.6 防火墙放行UDP 123后客户端仍连不上

排查到这一步，先把服务端、客户端本地的iptables规则都看一遍，注意firewalld和iptables可能同时存在。用实际规则列表判断：

bash复制iptables -L -n -v | grep 123
firewall-cmd --list-all

有一种特殊情况是麒麟自带的networkmanager在管理网卡时，会给接口额外应用一套策略，看起来firewalld已经允许了，但实际报文在进入netfilter之前就被网络策略丢弃。遇到这种情况，把NetworkManager策略先停掉再验证。我记得自己在麒麟V10SP3上遇到过一次很别扭的现象：服务器端ss -unlp能看到123，本机chronyc sources也正常，但从另一网段的客户端连过来就是不通。最后发现是客户端自身linux路由策略问题，源IP被路由到错误的网卡，NTP回包发不回去。这种问题用普通ping和curl根本查不出来，要在客户端抓包看有没有应答。

6.7 常用排查命令速查表

7. 一点实际运维经验

在我维护过的麒麟V10SP3内网环境里，时间同步出问题几乎都不是配置不会写，而是忽略了一些细节。比如服务端allow网段写错、客户端防火墙没放行UDP 123、时区没有先统一、NetworkManager自动同步和chronyd抢占控制权。这些坑一个个踩过来以后，我现在部署NTP服务时按固定节奏来：先看时区，再定服务端，验证服务端同步，再批量推客户端，最后用监控盯RMS offset。流程固定下来之后，新的服务器加进来基本几分钟就能搞定。

最后分享一个实用小技巧：如果内网规模不大，完全可以把NTP服务器和DNS服务器放在同一台机器上，既省资源，也方便网络策略统一管理。规模更大之后，再考虑为每个机房或每个VPC单独部署一台聚焦时间同步的服务器。目前这台麒麟V10SP3服务器已经稳定运行了大半年，内网几十台机器的时间偏差基本保持在几毫秒以内，之前那些稀里糊涂的业务故障也没再出现过。