当业务从单台服务器扩展到多台服务器时，时间不一致的问题会成倍放大。日志时间对不上、HTTPS 证书突然报错、数据库主从复制出现异常、定时任务重复执行，这些看似无关的故障，往往都指向同一个根源：各节点系统时钟没有对齐。这篇文章会教你如何在多台 Linux 服务器上配置 chrony 集群时间同步，并给出验证各节点时间一致性的可落地方法。无论你用的是 VPS（虚拟专用服务器）还是独立服务器，这套方案都适用，相关概念也可以参考我们的服务器运维分类文章。
为什么服务器时间会漂移
服务器主板上的晶振会受温度、电压和负载影响，导致系统时钟每天产生几毫秒到几秒的偏差。对普通网站来说，几秒的偏差可能无感；但对依赖时间戳的日志分析、HTTPS 证书有效期校验、数据库主从复制和定时任务调度来说，偏差会直接造成误判。例如证书校验依赖客户端与服务器时间一致，一旦服务器时间超前或滞后，浏览器就会提示证书无效，用户访问直接中断。
要解决这个问题，就需要让服务器定期与权威时间源对齐。NTP（网络时间协议）就是为此设计的标准协议，它通过 UDP 123 端口与上游时间服务器通信，把本地时钟校准到毫秒级精度。chrony 是 NTP 的现代实现，相比传统 ntpd，它在网络抖动、虚拟机暂停和开机启动时收敛更快，因此成为主流 Linux 发行版的默认时间同步工具。
部署前需要确认的前提
在动手之前，先确认三件事，避免后面排障时走弯路。
第一，确认系统发行版。chrony 在 CentOS、Rocky、Ubuntu、Debian 上都有官方软件源，安装命令略有差异，但配置思路一致。第二，确认 UDP 123 端口出站可用。chrony 需要访问上游时间服务器，如果服务器启用了防火墙或安全组，必须放行 UDP 123 出站，否则同步会一直失败。第三，确认时区设置。时间同步解决的是“绝对时间”的准确性，而时区决定你看到的时间显示，两者要分开处理。
安装并启动 chrony
以 CentOS 系为例，安装命令如下：
yum install -y chrony systemctl enable --now chronyd
Ubuntu 系则使用 apt：
apt install -y chrony systemctl enable --now chronyd
安装完成后，用 chronyc tracking 查看同步状态。如果输出中 Leap status 为 Normal，说明已与上游时间源建立同步；如果显示 Not synchronised，则说明还没有成功对齐，需要继续排查。
配置上游时间服务器
chrony 的配置文件默认位于 /etc/chrony.conf。默认配置会使用发行版内置的公共时间服务器，但为了更稳定，建议手动指定一组可靠的上游源。编辑配置文件，把 server 行替换为以下内容：
server 0.pool.ntp.org iburst server 1.pool.ntp.org iburst server 2.pool.ntp.org iburst server 3.pool.ntp.org iburst
iburst 参数让 chrony 在启动时快速发送多个请求，缩短首次同步的收敛时间。修改后重启服务使配置生效：
systemctl restart chronyd
如果你所在地区访问公共 NTP 池延迟较高，也可以改用国内的时间服务器，例如阿里云或腾讯云提供的 NTP 地址，通常延迟更低、同步更稳定。
验证时间同步是否生效
配置完成后，用三个命令交叉验证，避免只看单一输出就下结论。
chronyc sources -v 查看上游源的同步状态，^* 表示当前选中的同步源，^+ 表示可用的候选源。如果所有源都显示 ^?，说明请求没有成功返回，需要检查网络和防火墙。
chronyc tracking 查看本地时钟与上游的偏差，System time 字段会显示当前偏差值，正常应保持在毫秒级。
timedatectl 查看系统时间、时区和 NTP 服务状态，确认 NTP service: active 且 System clock synchronized: yes。
常见时钟漂移排障
即使部署完成，仍可能遇到同步失败或偏差过大的情况。下面按症状给出对应的排查路径。
症状一：chronyc sources 全部显示问号
这说明 chrony 无法与任何上游源通信。优先检查 UDP 123 出站是否被防火墙或安全组拦截。用 firewall-cmd --list-all 查看防火墙规则，必要时放行 UDP 123。同时用 chronyc sources -v 确认没有配置错误的服务器地址。
症状二：同步成功但偏差仍然很大
如果 chronyc tracking 显示偏差达到秒级，通常是服务器负载过高或网络抖动剧烈导致。可以增加 maxsamples 参数让 chrony 采样更多数据点，或者更换延迟更稳定的上游源。对虚拟机来说，还要确认宿主机没有强制覆盖客户机时钟。
症状三：重启后时间又跳回错误值
这通常是因为硬件时钟（RTC）与系统时钟不一致。用 hwclock --systohc 把当前系统时间写回硬件时钟，并确认 /etc/chrony.conf 中 rtcsync 指令存在，它会让 chrony 定期把系统时间同步到硬件时钟。
时间同步对业务的实际影响
时间一致性不是运维的“锦上添花”，而是多服务器架构稳定运行的前提。日志分析依赖统一的时间戳，如果各节点时间不一致，跨节点排查问题时日志顺序会错乱，定位故障要花数倍时间。HTTPS 证书校验依赖时间一致性，服务器时间偏差超过证书有效期窗口，就会导致证书被判定为无效。数据库主从复制和定时任务调度同样依赖时间基准，偏差过大会造成数据不一致或任务重复执行。如果你正在排查网站加载缓慢的问题，可以结合网站性能优化指南一起排查，时间偏差有时也会间接影响缓存与请求处理。
对运行在 VPS 或独立服务器上的业务来说，把时间同步纳入日常巡检清单，能显著减少这类“隐性故障”。如果你正在规划服务器架构，建议在部署阶段就把 chrony 配置写进初始化脚本，避免后续逐台手工配置。
总结与行动建议
本文介绍了在多台 Linux 服务器上配置 chrony 集群时间同步的完整流程，包括安装、配置上游源、验证各节点时间一致性，以及针对常见时间偏差问题的排障方法。核心结论是：多服务器场景下，时间一致性要作为架构初始化的标准步骤，而不是出了问题再补救。
如果你需要，可以先把 chronyc tracking 加入监控脚本，当偏差超过阈值时自动告警。对于多台服务器的场景，建议统一使用同一组上游时间源，并定期检查各节点的时间偏差。如果你正在评估服务器方案，可以参考 Hostease 的 VPS 主机与独立服务器产品，结合自身业务规模选择合适配置，并在部署时一并完成时间同步设置。