服务器时间不准确怎么办？

服务器时间看起来不准确，常见原因有两种：一种是时区不同，另一种是系统时钟确实存在偏差。

例如，服务器显示UTC时间，与北京时间相差8小时，并不一定说明校时失败。应先判断问题类型，再进行调整。

本文适用于使用systemd的常见Linux服务器。生产环境时间偏差较大时，启动或调整校时服务可能引起时间跳变，应先评估数据库、定时任务等业务的影响。

1. 查看当前时间、时区和同步状态

登录服务器后执行：

date '+%F %T %z'
date -u '+%F %T %z'
timedatectl status

其中：

• 第一条显示当前环境下的本地时间及UTC偏移。

• 第二条显示UTC时间。

• 第三条查看系统时区、时钟及网络校时状态。

重点关注以下字段：

如果系统时区是 Etc/UTC，时间比北京时间少8小时，应先按第2节检查时区。

如果与可靠时间参考相比，UTC时间本身也相差几分钟甚至几小时，则需要继续检查校时服务。

NTP service: active 不等于已经同步成功。 还需要结合实际校时服务的状态判断。

2. 按需要设置北京时间显示

如果业务需要使用北京时间，可以执行：

sudo timedatectl set-timezone Asia/Shanghai

然后检查：

timedatectl show -p Timezone
date '+%F %T %z'
date -u '+%F %T %z'

正常情况下，系统时区应显示：

Timezone=Asia/Shanghai

本地时间的UTC偏移应为：

+0800

修改时区主要改变本地时间的显示和解释方式，不会把系统的Unix时间戳直接增加8小时。因此，不要为了补齐时差再手动把时钟向后调整8小时。

如果服务器原本统一使用UTC记录日志，可以继续保持UTC，无需强制改为北京时间。

调整系统时区后，应核对依赖本地时间的定时任务。应用如果单独设置了时区，也需要在应用中检查。

3. 确认服务器使用哪一种校时服务

常见校时服务包括chrony和systemd-timesyncd。先查看现有服务：

systemctl status chrony chronyd systemd-timesyncd --no-pager

部分服务提示不存在属于正常情况，应以实际已安装、已配置的服务为准。如果使用的是ntpd等其他实现，应检查对应服务。

常见对应关系如下：

根据现有配置选择对应的一条，不要把表中的命令全部执行。 同一系统不应同时运行多个互相竞争的校时程序。

如果确认没有安装任何校时服务，Ubuntu或Debian可以安装chrony：

sudo apt update
sudo apt install chrony
sudo systemctl enable --now chrony

已有正常运行的校时服务时，无需为了排查问题再安装另一套。

如果服务处于 failed 状态，应先查看日志，不要只反复重启。

4. 检查是否真正完成同步

使用chrony的服务器

执行：

chronyc tracking
chronyc sources -v

重点查看：

服务刚启动时，需要一定时间获取样本，不应因为短暂出现 ^? 就立即判断故障。

也不能只看见 Normal 就认定绝对准确，还应确认选中的时间源可信、参考时间持续更新，并检查偏差。

使用systemd-timesyncd的服务器

执行：

timedatectl timesync-status
timedatectl status

查看当前时间服务器、最近同步信息和系统同步状态。

timesync-status 是针对systemd-timesyncd的命令。服务器使用chrony时，应使用前面的 chronyc 命令检查。

5. 长期无法同步时，检查日志和网络

查看相关服务日志：

sudo journalctl \
  -u chrony -u chronyd -u systemd-timesyncd \
  -n 60 --no-pager

重点排查：

• 时间源域名是否能够正常解析。

• 配置的时间服务器是否可达。

• 防火墙是否允许必要的出站请求和返回流量。

• 配置文件是否有语法错误。

• 服务是否缺少调整系统时钟的权限。

• 是否有其他程序同时修改时间。

常规NTP通常访问时间服务器的 UDP 123端口。如果启用了NTS安全校时，还需要检查密钥协商所使用的端口，通常是 TCP 4460。

作为普通校时客户端，不需要为了同步时间就向全网开放本机的UDP 123入站服务。

chrony常见配置位置包括：

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

部分系统还会通过 conf.d、sources.d 或DHCP引入配置。修改前应确认实际加载的位置，不要只改一个未被使用的文件。

优先检查系统已有时间源。确需更换时，应使用运维确认可信、可达的时间服务器，不要把教程中的示例地址直接作为时间源。

如果已经取得可靠测量，但系统仍有较大偏差：

chrony通常会逐渐调整时钟。确需立即校正时，可以在确认业务允许时间跳变后执行：

sudo chronyc makestep

该命令会把剩余调整量直接应用到系统时钟。它不能解决时间源不可达的问题，也不应被加入高频定时任务反复执行。

6. 验证时间和业务是否恢复正常

处理完成后，再次检查：

date '+%F %T %z'
date -u '+%F %T %z'
timedatectl status

使用chrony时，再执行：

chronyc tracking
chronyc sources -v

使用systemd-timesyncd时，再执行：

timedatectl timesync-status

隔一段时间复查，确认参考测量继续更新，偏差保持在业务可以接受的范围内。

随后检查原本异常的业务，例如：

• 日志时间是否符合预期。

• 登录令牌或接口签名是否仍提示时间错误。

• 定时任务是否按照预期时区执行。

• 原本因时钟偏差产生的证书有效期错误是否消失。

如果系统时间正常，但某个网站或容器仍显示错误时间，应继续检查应用自己的时区设置，而不是再次修改服务器时钟。

常见问题

1. 为什么服务器时间总是差8小时？

常见原因是服务器显示UTC，而用户按北京时间理解。先查看时区和UTC偏移，不能仅凭8小时差值认定系统时钟错误。

2. 修改系统时区后，网站时间为什么没变化？

应用可能使用独立的时区配置，例如PHP的 date.timezone、数据库会话时区或程序环境变量。应检查实际运行的应用配置，必要时按应用要求重新加载。

3. Docker容器里没有timedatectl怎么办？

普通Docker容器通常没有运行systemd。应先在宿主机检查校时，再检查容器内的时区数据和应用设置。不要为了修改显示时间就给容器增加系统时钟管理权限。

4. 重启后时间又不准确怎么办？

检查校时服务是否设置为开机启动、启动后是否成功同步，以及虚拟机恢复或宿主机相关设置是否影响了时钟。单纯反复手动设置时间，通常无法解决持续漂移的问题。

注意事项

时区调整与系统时钟校正是两件不同的事。不要反复使用手动设时命令代替持续校时，也不要同时启用多个校时程序。

如果服务器时间持续漂移，或每次重启后都出现较大偏差，可向莱卡云提交工单，提供操作系统版本、偏差情况、timedatectl status 输出、校时服务状态及相关日志，便于协助核查。