如果你管理过一台运行中的云服务器，大概率遇到过这样的怪事：某天突然收到邮件发送失败的告警，日志时间戳比真实时间晚了几分钟，甚至 HTTPS 证书无端报”未生效”。这些看似无关的问题，源头往往是同一个——服务器的系统时间悄悄发生了漂移。
时钟漂移是物理时钟不可避免的误差积累。一块普通的系统时钟，在没有外部校正的情况下，每天可能偏差数十秒，积累下来就会让日志、任务调度、会话校验全部错位。这篇指南会教你如何在 VPS（虚拟专用服务器）上安装并配置 chrony，利用 NTP 协议持续校准系统时间，再给出排查漂移的实战步骤，帮你彻底摆脱”时间不准”带来的连锁故障。
为什么服务器时间会漂移
理解漂移前，先要分清两个概念：系统时钟是操作系统维护的软件计时器，精度取决于硬件晶振的稳定性；硬件时钟（RTC）则是主板上的独立计时芯片。晶振受温度、电压影响，频率会有微小偏差，这就是漂移的来源。
以一台长期运行的服务器为例，如果硬件晶振的实际频率与标称频率相差百万分之五十，一年累计下来的偏差就可能接近 26 分钟。这样的误差会带来三类可见后果：
- 日志错乱：排障时按时间顺序追日志，跨服务器的时间戳对不上，事件因果关系被颠倒
- 安全机制失效：很多认证协议依赖时间窗口，SSL 证书的签名验证、票据有效期判断都会受系统时间影响
- 定时任务错乱：crontab 按本地时间触发，漂移后备份、报表、数据库归档的执行时间全部偏移
时间同步的意义就在于，用外部可信的时间源持续修正本地时钟，把漂移控制在毫秒级。作为服务器日常运维的一部分，这一步与我们整理过的服务器运维与性能优化教程体系相辅相成。
chrony 是什么，为什么选它
NTP（Network Time Protocol，网络时间协议）是服务器对时的事实标准，它通过分层的时间服务器结构，把权威时间逐级下发到每一台客户端。Linux 上最常用的 NTP 实现有两个：老牌的 ntpd 和新一代的 chrony。
chrony 之所以成为现代发行版（如 Ubuntu、Rocky Linux）的默认时间服务，核心优势在于它把”校正速度”和”同步精度”分得更细致。它有两种工作模式：slew 模式让本地时钟逐渐逼近时间源，适合偏差较小时平滑追平，避免日志时间出现跳变；step 模式则直接跳变时间，适合系统启动时那种数分钟的初始偏差。相比之下，ntpd 对时钟跳变的处理更保守，在偏差大时反而会被动等待。
chrony 还内置了 RTC 时钟跟踪能力，可以推算硬件时钟的漂移率。对使用无电池 RTC 的云服务器来说，这个特性让重启后的恢复对时更快、更准。考虑到多数站长都在云主机上跑业务，选择 chrony 是最稳妥的路线。
第一步：在 VPS 上安装 chrony
不同发行版安装命令略有区别，下面分别列出主流系统的做法。操作前请先以 root 或具备 sudo 权限的用户登录服务器。
- Debian / Ubuntu（使用 apt）：
sudo apt update && sudo apt install -y chrony - Rocky Linux / AlmaLinux / 其他 RHEL 系（使用 dnf）：
sudo dnf install -y chrony - 如果你在用托管型虚拟主机或面板环境，多数面板自带 NTP 同步开关，不一定需要手动装 chrony
安装完成后，先确认服务确实在运行：
systemctl status chronyd
正常情况下输出应显示 active (running)。随后可以用 chronyc sources -v 查看当前同步的时间源，* 表示已锁定主时间源，^ 表示该源可作为参考但尚未被选为主源。
第二步：配置时间源与同步参数
chrony 的主配置文件是 /etc/chrony/chrony.conf。开箱即用的默认配置通常已经指向了几个公共时间源，但如果你所在机房访问公共时间源不稳，可以换成离你更近的源，或直接使用阿里云、腾讯云提供的国内公共 NTP 地址。一个推荐的配置片段如下：
# 指定两个以上时间源，避免单点失效
pool ntp.aliyun.com iburst
pool ntp.tencent.com iburst
pool 0.debian.pool.ntp.org iburst
# 允许本地时钟作为最终兜底
local stratum 10
# 记录漂移率，重启后加速对时
driftfile /var/lib/chrony/drift
pool关键字会让 chrony 从该地址池中选取多个源，iburst表示首次同步时快速发送多组请求，缩短初始对时时间local stratum 10的作用是当所有外部源都不可达时，允许本机时钟继续对外提供服务，避免单机故障时整片主机失去时间参考driftfile用于持久化计算出的漂移率，重启后 chrony 能据此快速追平，而不是从头重新测量
改完配置后执行 sudo systemctl restart chronyd 让修改生效。多数情况下无需对外开 123/UDP 端口，因为本机作为客户端只需主动发出请求，不需要监听外部接入；只有当你要把这台机器当作时间服务器，给内网其他主机提供对时服务时，才需要在防火墙放行 123/udp。
第三步：验证同步是否生效
配置完成不代表万事大吉，需要验证三个层面：时间源是否可用、本地时钟是否在追踪、偏差是否收敛。
先看时间源状态：
chronyc sources -v
chronyc tracking
chronyc tracking 会输出当前追踪的时间源、System time（相对时间源的当前偏差）以及 Last offset（上一次校正的偏移量）。正常情况下，System time 会稳定在毫秒级甚至微秒级，比如 -0.000123456 seconds。
然后核对系统时间与真实时间：
timedatectl
输出中 System clock synchronized: yes 表示已成功同步，NTP service: active 表示 NTP 服务在运行。如果想强制立即与时间源对齐一次，可以用：
chronyc makestep
这个命令常用于刚部署完成时的快速校正，让本地时钟跳到权威时间，适合偏差较大的场景。对生产环境来说，校正动作建议放在业务低峰期执行，避免时钟跳变影响正在写入的日志和事务。如果你的业务页面响应同样受底层基础设施影响，也可以顺手对照我们的网站加速与 TTFB 优化指南，一并排查网络与主机层面的指标。
常见漂移问题排查
即使配置正确，仍可能遇到同步失效的情况。这里列出三种高频场景和对应排查思路。
场景一：同步状态显示 inactive，System clock synchronized: no
最常见的原因是时间源不可达。确认防火墙是否放行了出站 123/udp，再用 chronyc sources 观察源的状态：^? 表示连接失败，^* 表示已锁定。如果所有源都是问号，多半是机房禁用了对外 NTP 请求。
场景二：时间源可达，但偏差始终偏大
可能是 makestep 阈值配置得太保守。默认情况下，只有当偏差超过 1000 秒时 chrony 才会执行 step 跳变，0.1 秒到几十秒的偏差会走 slew 缓慢追平，这期间误差会被放大。可以调小 makestep 阈值，例如 makestep 1 3，表示前三次校正时偏差超过 1 秒就强制跳变。
场景三：重启后时间立即失准
这通常与 RTC 有关。用 hwclock -r 查看硬件时钟是否与系统一致，如果发现硬件时钟在掉电期间走偏，可以在配置里启用 rtcsync 选项，让 systemd 在系统运行期间定期把正确的系统时间回写到硬件时钟。
小结与建议
时间同步是服务器运维里不起眼却很关键的一环。部署 chrony 本身只需几步：安装、改配置、验证，但真正让它可靠运行，靠的是对时间源、driftfile 和校正策略的细致处理。建议你把同步状态纳入日常巡检，每周用 chronyc sources 和 timedatectl 各检查一次，就能在故障发生前把漂移扼杀在萌芽里。
如果你正在规划或维护一台对时间精度敏感的服务器，比如跑证书轮换、多节点日志聚合或定时备份的任务，建议你先确认自己的 VPS（虚拟专用服务器）环境是否已启用可靠的时间同步。需要一台网络稳定、底层时钟管理可靠的基础设施时，可以考虑了解 Hostease VPS 主机方案，把更多精力放在业务上。更多服务器运维与性能优化的实战内容，也可以参考我们整理的 服务器相关教程 和 网站加速与 TTFB 优化指南。