Linux服务器时间不准怎么办？Chrony时间同步排查教程

Linux服务器时间不准确，可能导致HTTPS证书校验失败、日志顺序混乱、定时任务错过执行、数据库主从异常、集群节点认证失败，以及监控数据无法正确对齐。

“时间不准”也不一定都是NTP同步故障。系统时间、时区、硬件时钟、应用显示格式和容器环境属于不同层次：服务器可能已经正确同步UTC时间，只是时区设置错误；也可能时区正确，但Chrony没有选中任何可用时间源。

本文介绍如何使用timedatectl、date、chronyc tracking、chronyc sources和journalctl判断问题所在，并排查NTP端口、DNS、虚拟机暂停、硬件时钟和多个时间同步服务冲突等常见问题。

一、先区分系统时间、时区和硬件时钟

Linux服务器常见的时间概念包括：

系统时钟：内核运行期间使用的时间。
UTC：全球统一时间标准。
时区：将UTC转换为本地时间的规则。
RTC硬件时钟：服务器关机后仍继续运行的时钟。
NTP时间源：通过网络提供参考时间的服务器。
应用时区：Java、PHP、数据库和容器可能单独设置时区。

先执行：

timedatectl

再查看：

date
date -u

典型输出会包含：

Local time
Universal time
RTC time
Time zone
System clock synchronized
NTP service
RTC in local TZ

如果UTC时间正确，但本地时间差8小时，通常是时区问题，不应通过手动调整系统时间解决。

二、设置正确的服务器时区

查看可用时区：

timedatectl list-timezones

搜索上海时区：

timedatectl list-timezones | grep Shanghai

设置为中国标准时间：

sudo timedatectl set-timezone Asia/Shanghai

设置后确认：

timedatectl
date

建议服务器内部、数据库和分布式系统尽量统一使用UTC存储时间，再由展示层转换为用户所在时区。如果业务明确依赖本地时间，也应保证所有节点使用一致的时区数据库和配置。

不要直接修改date来修复时区差异。时区变化不会改变真实时间点，只会改变本地显示方式；手动调整系统时钟则可能让时间突然向前或向后跳变。

三、确认系统使用哪一种时间同步服务

常见时间同步服务包括：

chronyd
systemd-timesyncd
ntpd
云厂商提供的时间同步代理
虚拟化平台的宿主机时间同步

检查相关服务：

systemctl list-unit-files |
  grep -E 'chrony|chronyd|systemd-timesyncd|ntpd'

检查正在运行的进程：

ps -ef | grep -E '[c]hronyd|[n]tpd|systemd-timesyncd'

不同时间同步服务不应在没有明确设计的情况下同时控制系统时钟。多个服务同时校时可能造成频率反复调整、时间跳变或状态判断混乱。

如果系统使用Chrony，应以chronyc的输出为主要诊断依据。timedatectl可以提供系统层面的概览，但某些专用于systemd-timesyncd的详细命令不能替代Chrony自身状态。

四、检查Chrony服务是否正常

Ubuntu和Debian常见服务名：

sudo systemctl status chrony --no-pager

RHEL、Rocky Linux、AlmaLinux等系统常见服务名：

sudo systemctl status chronyd --no-pager

查看日志：

sudo journalctl -u chrony -b --no-pager -n 100

或：

sudo journalctl -u chronyd -b --no-pager -n 100

如果服务没有启动：

sudo systemctl enable --now chrony

或：

sudo systemctl enable --now chronyd

服务启动失败时，应先查看日志和配置，而不是反复重启。

五、使用chronyc tracking判断同步状态

执行：

chronyc tracking

常见字段包括：

字段	含义	排查重点
`Reference ID`	当前参考时间源	是否已经选中有效来源
`Stratum`	当前时间层级	0通常表示未正常同步
`Ref time`	最近一次有效更新	是否长时间没有更新
`System time`	系统时间剩余校正量	偏差是否持续收敛
`Last offset`	最近一次测量偏差	是否异常增大
`RMS offset`	偏差的均方根	长期稳定性参考
`Frequency`	系统时钟频率误差	是否出现异常漂移
`Leap status`	闰秒与同步状态	`Not synchronised`表示未同步

快速查看关键字段：

chronyc tracking |
  grep -E 'Reference ID|Stratum|Ref time|System time|Last offset|Leap status'

判断时不要只看一个字段。如果Leap status仍是Not synchronised、Stratum为0或者Ref time长期不更新，应继续检查时间源。

六、使用chronyc sources检查时间源

执行：

chronyc sources -v

典型状态标记：

标记	含义
`^*`	当前选中的NTP时间源
`^+`	可参与组合的有效时间源
`^-`	可用但未被选中的时间源
`^?`	当前不可用、不可达或测量不足
`^x`	被判断为异常时间源
`^~`	时间波动过大

重点关注：

是否至少存在一个^*。
Reach是否逐渐增加。
LastRx是否持续更新。
偏差是否在合理范围内。
所有来源是否都显示^?。

Reach使用八进制显示最近八次轮询的响应情况。稳定连接一段时间后，常见值为377。如果长期为0，通常表示没有收到有效响应，可能是UDP 123端口、防火墙、路由或时间源本身的问题。

查看源统计：

chronyc sourcestats -v

查看在线状态：

chronyc activity

七、检查Chrony配置文件

常见配置位置：

/etc/chrony.conf
/etc/chrony/chrony.conf

查找时间源和关键配置：

sudo grep -R -E '^(server|pool|peer|makestep|rtcsync|offline|minsources)' \
  /etc/chrony.conf /etc/chrony/ 2>/dev/null

基础示例：

pool pool.ntp.org iburst
driftfile /var/lib/chrony/drift
makestep 1.0 3
rtcsync

各项含义：

pool：从时间服务器池中解析多个来源。
iburst：启动后快速发送一组请求，加快首次同步。
driftfile：记录系统时钟频率偏差。
makestep 1.0 3：启动后的前三次更新中，偏差超过1秒时允许直接校正。
rtcsync：在支持的平台上让内核定期将系统时间同步到RTC。

生产环境应优先使用云厂商提供的内网NTP、企业内部可信时间源或多个可靠公共时间源。不要只配置一个长期不稳定的服务器。

修改后重启服务：

sudo systemctl restart chrony

或：

sudo systemctl restart chronyd

随后等待一段时间再检查：

chronyc tracking
chronyc sources -v

八、时间偏差很大但Chrony校正很慢

Chrony默认会尽量通过加快或减慢系统时钟逐步修正偏差，这称为slew。这样可以避免时间突然倒退或跳跃，但偏差很大时可能需要较长时间。

查看剩余校正量：

chronyc tracking

如果确认可以接受时间跳变，可以执行：

sudo chronyc makestep

该命令可能让系统时间立即向前或向后跳变。生产环境使用前必须评估：

数据库和分布式锁是否依赖单调时间。
日志和监控是否能处理时间回退。
Kerberos、令牌和证书是否受到影响。
定时任务是否可能重复或跳过。
集群选举和租约是否依赖时间。

更稳妥的做法是在配置中仅允许启动初期执行较大幅度校时：

makestep 1.0 3

对于已经运行的核心生产系统，不应在不了解业务影响的情况下反复执行makestep。

九、检查NTP网络和UDP 123端口

NTP通常使用UDP 123端口。检查防火墙：

sudo nft list ruleset

使用firewalld的系统：

sudo firewall-cmd --list-all

使用UFW的系统：

sudo ufw status verbose

抓包检查是否发出请求并收到响应：

sudo tcpdump -ni any udp port 123

如果可以看到请求发出，但没有响应返回，检查：

云安全组或云防火墙是否限制UDP。
出口网关是否允许UDP 123。
企业网络是否要求使用内部NTP。
时间服务器是否可达。
返回数据包是否被主机防火墙丢弃。

如果chronyc sources -v中的Reach长期为0，网络连通性应作为重点排查方向。

十、DNS解析失败导致时间源不可用

配置中使用域名时，Chrony必须先解析时间服务器地址。

测试解析：

getent ahosts pool.ntp.org

查看Chrony活动状态：

chronyc activity

如果显示存在unknown address来源，应检查：

cat /etc/resolv.conf
resolvectl status

系统时间偏差特别大时，DNSSEC证书有效期判断也可能失败，形成“时间不准导致DNS失败，DNS失败又导致NTP域名无法解析”的循环。

此时应通过云控制台确认网络和DNS，必要时临时使用可信时间源的固定IP完成首次校时，再恢复正常的域名配置。不要长期依赖未经维护的固定公网IP。

十一、时间源处于offline状态

查看：

chronyc activity

如果来源被标记为离线，可以执行：

sudo chronyc online

然后加快测量：

sudo chronyc burst 4/4

某些网络管理脚本会在接口断开时执行chronyc offline，但网络恢复后没有正确执行online。这种情况常见于网络脚本、VPN、休眠恢复和自定义自动化配置。

不应通过定时任务频繁重启Chrony来代替正确的网络状态管理。

十二、虚拟机暂停、迁移后时间异常

虚拟机暂停、宿主机休眠、快照恢复或热迁移后，客户机时钟可能出现明显跳变。

检查：

uptime
chronyc tracking
chronyc sources -v
journalctl -u chronyd --since '1 hour ago'

可能的处理方法：

确认Chrony在恢复后仍能访问时间源。
清除不再有效的旧测量：

sudo chronyc reset sources

重新使来源上线：

sudo chronyc online

在评估业务影响后进行一次makestep。
检查虚拟化平台时间同步是否与Chrony同时调整时钟。

虚拟机中的时钟漂移可能明显高于物理机，应该持续监控偏差、频率和同步状态，而不是只在部署时检查一次。

十三、检查RTC硬件时钟

查看：

sudo hwclock --show
timedatectl

通常建议Linux服务器的RTC使用UTC。查看：

timedatectl | grep 'RTC in local TZ'

设置RTC使用UTC：

sudo timedatectl set-local-rtc 0

将当前系统时间写入硬件时钟：

sudo hwclock --systohc

如果使用Chrony的rtcsync，系统会通过内核机制定期让RTC接近系统时间。不要同时使用多个脚本频繁写RTC。

如果服务器每次重启后时间都明显错误，但联网一段时间后恢复，应检查：

RTC电池或虚拟RTC。
BIOS/UEFI时间。
rtcsync配置。
系统启动时读取RTC的方式。
云平台是否在启动时注入时间。

十四、应用显示时间仍然不对

系统时间正确并不代表所有应用显示都正确。

PHP

php -i | grep 'date.timezone'

Java

java -XshowSettings:properties -version 2>&1 |
  grep 'user.timezone'

MySQL

SELECT NOW(), UTC_TIMESTAMP(), @@global.time_zone, @@session.time_zone;

PostgreSQL

SHOW timezone;
SELECT now();

容器

docker exec container_name date

应用可能使用：

独立时区配置。
JVM启动参数。
数据库会话时区。
容器镜像中的时区数据。
前端浏览器所在时区。

应先确认时间戳本身是否正确，再检查展示层的时区转换，避免把应用配置问题错误归因于NTP。

十五、容器时间不准怎么办

普通Linux容器通常共享宿主机内核时钟，容器本身不能独立运行一套真正不同的系统时间。

如果容器显示时间不同，常见原因是：

容器时区文件与宿主机不同。
镜像没有安装时区数据库。
应用内部设置了其他时区。
宿主机时间本身不正确。

检查宿主机和容器：

date
docker exec container_name date

不要在普通容器中同时运行Chrony来调整系统时钟。应在宿主机或节点层统一同步时间，再按应用需要配置容器时区。

Kubernetes环境还应检查所有节点的时间。只修复单个Pod不能解决节点间的时间偏差。

十六、时间跳变可能造成哪些业务问题

大幅调整系统时间前需要了解风险：

定时任务重复执行或跳过。
日志时间倒退，排障顺序混乱。
TLS证书被判断为尚未生效或已经过期。
登录令牌和验证码立即失效。
Kerberos认证失败。
分布式锁、租约和选举异常。
数据库复制和备份时间线混乱。
监控出现数据断层或覆盖。

对重要生产系统，建议：

在业务低峰处理。
先保存Chrony和系统状态。
确认数据库与集群组件的时间要求。
优先渐进校时。
必须跳变时提前暂停敏感任务。
校时后检查日志、认证、数据库和集群状态。

十七、建立时间同步监控

建议监控：

Chrony是否存在选中的^*来源。
Leap status是否为正常同步状态。
系统剩余偏差。
最后一次更新时间。
Reach是否持续下降。
可用时间源数量。
时钟频率偏差。
NTP UDP 123网络可达性。
所有集群节点之间的时间差。
服务重启、虚拟机迁移和暂停恢复事件。

自动检查示例：

chronyc tracking
chronyc sources -v

对于证书、认证、数据库集群和分布式系统，告警阈值应根据业务容忍度设置，不能只判断“Chrony进程是否运行”。

十八、推荐的完整排查顺序

Linux服务器时间不准时，可以按下面的顺序处理：

使用date、date -u和timedatectl区分时间错误与时区错误。
确认系统使用Chrony、timesyncd还是其他同步服务。
检查chrony或chronyd服务状态和日志。
使用chronyc tracking检查同步层级、参考源和剩余偏差。
使用chronyc sources -v确认是否存在^*时间源。
检查Reach、LastRx和来源在线状态。
检查Chrony配置中的server、pool、iburst和makestep。
使用抓包和防火墙规则检查UDP 123。
检查时间源域名的DNS解析。
确认来源没有被错误设置为offline。
检查虚拟机暂停、迁移和宿主机同步冲突。
检查RTC、启动时间和rtcsync。
如果系统时间正确，继续检查应用、数据库和容器时区。
偏差较大时评估渐进校时与makestep的业务风险。
修复后持续监控偏差、来源和集群节点时间差。

总结

Linux服务器时间异常必须先区分系统时钟、时区、RTC和应用显示。UTC正确但本地显示错误，应调整时区；Chrony服务正在运行但没有选中^*来源，则仍然不能认为时间同步正常。

排查Chrony时，应结合chronyc tracking、chronyc sources -v和chronyc activity查看参考源、偏差、Reach及在线状态，再检查UDP 123、防火墙、DNS和配置文件。

时间偏差较大时，Chrony默认的渐进校时更有利于保持业务连续性。makestep可以快速修正时间，但可能造成时间跳变，应优先限制在启动初期，并在生产环境执行前评估数据库、认证、定时任务和分布式系统的影响。

最终目标不仅是让某一台服务器显示正确时间，而是让所有节点使用可信来源、保持稳定偏差，并建立持续的时间同步监控。

Linux服务器时间不准怎么办？Chrony时间同步、时区配置与故障排查教程