为什么要做时间同步

服务器时钟只要偏差几十秒，就可能让证书校验、登录认证、日志排查和分布式系统同时出问题，所以每台服务器都应该配置自动时间同步。

常见的受影响场景：

• 日志排查：多台机器的日志时间对不上，故障时无法还原事件先后顺序。
• TLS/HTTPS 证书：系统时间超出证书有效期，会出现“证书无效”或“证书尚未生效”的报错。
• 双因素认证与签名：TOTP 动态口令、云厂商 API 签名、JWT 过期判断都依赖准确时间，一般只容许几十秒到几分钟的误差。
• 分布式系统与数据库：集群选主、事务时间戳、主从复制都对时钟偏移敏感。
• 定时任务与计费：cron 触发时间、流量和计费周期都以系统时间为准。

服务器的硬件时钟会随温度、负载慢慢漂移，虚拟机和 VPS 的漂移通常更明显，因此不能只在装机时校准一次。

基本概念与方案选择

大多数 Linux 服务器用 chrony 就够了；只需要简单对时的轻量机器用 systemd-timesyncd；Windows 用自带的 Windows Time 服务（w32tm）。

另外要分清几个容易混淆的概念：

• NTP：网络时间协议，通过 UDP 123 端口向上游时间源校准系统时钟。
• UTC 与时区：系统内部以 UTC 计时，时区只决定显示方式。服务器建议内部保持 UTC 时间，业务展示再转换，设置时区不会影响时间同步的准确性。
• 硬件时钟（RTC）：主板上的时钟，开机时用来给系统时钟赋初值。系统时钟同步后，内核会定期回写 RTC。
• stratum（层级）：时间源离原子钟的跳数。stratum 1 直连时间基准，每经过一级加 1，数字越小越权威。

Linux：用 chrony 配置时间同步

安装 chrony、指定几个可靠的时间源、启动服务，三步即可完成同步。

1. 安装并启用

# Debian / Ubuntu
sudo apt update && sudo apt install -y chrony
sudo systemctl enable --now chrony

# RHEL / Rocky / AlmaLinux / CentOS Stream
sudo dnf install -y chrony
sudo systemctl enable --now chronyd

注意服务名：Debian 系是 chrony，RHEL 系是 chronyd。如果系统里同时运行着 ntpd 或 systemd-timesyncd，先停用它们，避免多个程序争抢调整时钟。

2. 配置时间源

配置文件在 Debian 系是 /etc/chrony/chrony.conf，RHEL 系是 /etc/chrony.conf。把默认的 pool 或 server 行替换为下面的内容（按机房位置选择，国内机器可优先用前几个）：

# 国内常用源
server ntp.aliyun.com iburst
server ntp.tencent.com iburst
server cn.pool.ntp.org iburst

# 海外或备用源
server time.cloudflare.com iburst
server time.google.com iburst

# 开机后若偏差超过 1 秒，前 3 次更新允许直接跳变校正
makestep 1.0 3

# 把校准结果同步回硬件时钟
rtcsync

driftfile /var/lib/chrony/chrony.drift

iburst 的作用是启动时快速连发几个请求，让首次同步更快完成。建议配置至少 3 个时间源，这样其中一个出错时 chrony 能通过多数判断剔除异常源。

3. 重启并验证

sudo systemctl restart chrony    # RHEL 系用 chronyd
chronyc sources -v               # 查看时间源，前面带 ^* 的是当前选中的源
chronyc tracking                 # 查看偏差、层级和最后一次校准信息
timedatectl                      # 确认 System clock synchronized: yes

chronyc tracking 输出里重点看两项：System time 表示当前时钟与 NTP 时间的偏差，Leap status 应为 Normal。如果需要马上校正而不等自然收敛，可以执行 sudo chronyc makestep。

轻量方案：timedatectl 与 systemd-timesyncd

只需要基本对时、不想多装软件时，用 systemd 自带的 timesyncd 就行，同时 timedatectl 也是设置时区和查看状态的通用入口。

# 查看当前状态（时区、是否已同步、RTC 时间）
timedatectl

# 设置时区，例如上海或东京
sudo timedatectl set-timezone Asia/Shanghai

# 开启 NTP 自动同步
sudo timedatectl set-ntp true

# 让硬件时钟使用 UTC（Linux 推荐）
sudo timedatectl set-local-rtc 0

如果要指定时间源，编辑 /etc/systemd/timesyncd.conf：

[Time]
NTP=ntp.aliyun.com ntp.tencent.com
FallbackNTP=time.cloudflare.com time.google.com

保存后执行 sudo systemctl restart systemd-timesyncd，再用 timedatectl timesync-status 查看当前连接的服务器和偏差。

timesyncd 只是 SNTP 客户端，不能充当 NTP 服务端，也不会评估多个源的质量。需要自建内网时间服务器或对精度有要求时，请改用上一节的 chrony。装了 chrony 之后，timesyncd 会自动让位，不需要手动同时管理。

自建内网 NTP 服务器

机器多或不能直接访问外网时，选一台能上外网的服务器做内网时间源，其余服务器都向它同步，既省外网流量，也能保证全网时间一致。

服务端：在上一节 chrony 配置的基础上，增加允许内网访问的规则。

# /etc/chrony/chrony.conf（RHEL 系为 /etc/chrony.conf）
server ntp.aliyun.com iburst
server ntp.tencent.com iburst

# 允许这个网段的客户端同步（按实际内网修改）
allow 192.168.1.0/24

# 外网不可用时，用本机时钟继续对内提供服务
local stratum 10

放行 UDP 123 端口，只对内网开放：

# Ubuntu / Debian（ufw）
sudo ufw allow from 192.168.1.0/24 to any port 123 proto udp

# RHEL 系（firewalld）
sudo firewall-cmd --permanent --add-service=ntp
sudo firewall-cmd --reload

客户端：把时间源改成这台内网服务器即可。

server 192.168.1.10 iburst

验证：在服务端执行 sudo chronyc clients 能看到各客户端的请求记录；在客户端执行 chronyc sources -v，看到内网服务器前面带 ^* 就说明同步成功。

注意不要把 NTP 服务对公网全开放，否则可能被用于反射放大攻击。allow 只写需要的内网网段，防火墙也只放行这些来源。

Windows Server：用 w32tm 配置时间同步

独立（非域）的 Windows Server 用管理员权限的命令提示符或 PowerShell 指定外部时间源即可；加入域的服务器默认从域控制器同步，不要手动改。

# 设置时区（以中国标准时间为例）
tzutil /s "China Standard Time"

# 指定外部时间源并立即生效（0x8 表示使用客户端模式）
w32tm /config /manualpeerlist:"ntp.aliyun.com,0x8 ntp.tencent.com,0x8" /syncfromflags:manual /reliable:yes /update

# 重启时间服务并强制同步
net stop w32time
net start w32time
w32tm /resync /force

用下面的命令验证：

w32tm /query /status   # 看 Source 是否为刚才设置的时间源，Last Successful Sync Time 是否是最近
w32tm /query /peers    # 查看各时间源的状态

域环境里的规则不同：成员服务器和工作站从域控制器同步，域控制器沿域层级向上，最终由拥有 PDC 模拟器角色的域控制器去同步外部时间源。所以只需要在 PDC 模拟器上执行上面的外部源配置，其他机器保持默认。

同步失败时先检查防火墙是否放行了出站 UDP 123，以及 Windows Time 服务是否在运行。

云服务器、VPS 与虚拟机的注意事项

云主机和虚拟机的时钟依赖宿主机，除了正常配置 NTP，还要留意下面几点。

• 优先用云厂商的内网时间源：延迟低、不占公网带宽。常见的有 AWS 的 169.254.169.123、Google Cloud 的 metadata.google.internal、腾讯云的 ntp.tencentyun.com，阿里云也提供内网 NTP 地址。具体地址以各厂商当前文档为准，用前先确认。
• 别让两套同步互相打架：VMware、Hyper-V 等虚拟化工具的“宿主机时间同步”和 chrony/NTP 同时开着时，时钟可能来回跳。选定一种方式，把另一种关掉。
• 容器不用单独同步：Docker 等容器与宿主机共用内核时钟，只需要保证宿主机同步正常，容器内通常无权也不应修改系统时间。
• 确认出站 UDP 123 没被拦：云安全组、系统防火墙、部分小厂商的网络策略可能默认限制出站 UDP。同步失败时先在服务器上用 chronyc sources 看时间源是否一直显示 ? 或无法访问。
• 休眠或快照恢复后立即校时：虚拟机从暂停或快照恢复时，时钟可能落后很多，可执行 sudo chronyc makestep 立即校正。
• 同步后再重启依赖时间的服务：数据库、证书续签程序等在时钟大幅跳变前启动，可能留下异常状态，建议在时间稳定后再检查。

常见问题排查与最佳实践

同步异常时，按“服务是否运行、网络是否通、时间源是否可用”的顺序排查，大多数问题都能定位。

建议的做法：

• 每台服务器都启用自动同步，并配置 3 个以上独立的时间源。
• 服务器系统时间和日志统一使用 UTC，或者全公司统一一个时区，避免混用。
• 同一台机器只运行一种时间同步程序。
• 机器较多时自建内网时间服务器，客户端统一指向它。
• 在监控里加一项时钟偏差告警，例如偏差超过 1 秒就报警，而不是等业务出问题才发现。
• 重要操作（证书续签、数据库主从切换、系统升级）前，先用 chronyc tracking 确认时间正常。