服务器时间一旦漂移，日志时间戳错乱、证书校验失败、数据库主从复制中断，这些故障往往在深夜悄悄出现，排查起来却要花掉大半天。这篇文章教你如何在 Linux 服务器上配置 chrony 完成时间同步，从安装、时间源配置到校准验证给出完整步骤，帮助你在一台新服务器上十分钟内把时间校准到位，并建立可持续的同步机制。
为什么服务器时间会漂移，以及它带来哪些麻烦
服务器主板上的晶振并非绝对精确，温度、负载和硬件老化都会让系统时钟逐渐偏离真实时间，这就是时钟漂移。单台机器每天漂移几毫秒看似无害，但累积到几个月后可能偏差几十秒甚至几分钟。对依赖时间戳的业务来说，这种偏差会引发一连串问题。
以最常见的场景为例：HTTPS 证书（SSL，安全传输协议）在握手时会校验服务器时间，如果本地时间比真实时间早或晚太多，浏览器会直接判定证书无效，用户访问网站时看到”连接不安全”的警告。数据库主从复制同样依赖时间戳排序，主库和从库时间不一致时，复制日志的先后顺序会被打乱，轻则同步延迟，重则复制中断。日志审计系统按时间戳关联事件，时间错乱会让安全分析完全失效。如果你正在排查网站访问异常，可以先从网站性能与稳定性优化入手，时间同步往往是其中容易被忽略的一环。
要解决这些问题，核心思路是让服务器定期向权威时间源校准。NTP 协议就是为此设计的，它通过 UDP 123 端口与上游时间服务器通信，把本地时钟逐步调整到与标准时间一致。相比老旧的 ntpdate 一次性对时，NTP 守护进程会持续跟踪时钟偏差并平滑校正，不会因为一次网络抖动就把时间跳变一大截。
chrony 与 ntpdate 的差异，以及为什么推荐 chrony
在 Linux 生态里，时间同步工具主要有 ntpdate、ntpd 和 chrony 三类。ntpdate 是早期的对时命令，它只在执行那一刻把时间强制设置为上游值，不做持续跟踪，一旦网络延迟波动就会产生明显跳变，如今多数发行版已不再默认安装。ntpd 是传统守护进程，功能完整但启动收敛慢，在虚拟化环境里对时钟跳变的响应也不够灵敏。
chrony 是较新的实现，它由两个组件构成：chronyd 守护进程负责持续同步，chronyc 命令行工具用于查询和配置。chrony 的优势在于收敛速度快，即使网络抖动频繁也能在几十秒内把时间校准到毫秒级；它还能在服务器离线时记录时钟漂移速率，恢复联网后快速追平。对运行在虚拟化环境中的云服务器（VPS，虚拟专用服务器）来说，chrony 对时钟跳变的处理明显更稳，这也是它成为主流发行版默认时间服务的原因。如果你正在为服务器性能与稳定性做整体规划，可以参考我们整理的服务器配置与优化指南，把时间同步纳入基础运维清单。
在 Linux 服务器上部署 chrony 的完整步骤
下面以 Debian/Ubuntu 和 CentOS/Rocky 两类主流系统为例，给出从安装到验证的完整流程。操作前请确认你有 root 权限，并保证服务器能访问外网的 UDP 123 端口。
第一步：安装 chrony
Debian/Ubuntu 使用 apt 安装：
apt update
apt install -y chrony
CentOS/Rocky 使用 dnf 安装：
dnf install -y chrony
安装完成后，先确认服务已随系统启动。Debian/Ubuntu 执行 systemctl enable --now chrony，CentOS/Rocky 执行 systemctl enable --now chronyd。注意两个发行版的服务名不同，写错会导致启动失败。
第二步：配置时间源
chrony 的主配置文件位于 /etc/chrony/chrony.conf（Debian/Ubuntu）或 /etc/chrony.conf（CentOS/Rocky）。默认配置已经包含一组公共时间服务器，但你可以根据服务器所在区域调整，减少网络延迟。以国内服务器为例，可以改用国内时间源：
pool cn.pool.ntp.org iburst
pool ntp.aliyun.com iburst
iburst 参数让 chrony 在启动时快速发送多个请求，缩短首次同步时间。如果你希望服务器同时为内网其他机器提供时间服务，还需要在配置中允许对应网段访问：
allow 192.168.1.0/24
第三步：启动并验证同步状态
修改配置后重启服务，然后用 chronyc 查看同步状态：
systemctl restart chrony
chronyc tracking
chronyc tracking 输出的 Stratum 表示当前层级，数值越小越接近权威源；Last offset 表示最近一次校正的偏差，单位是秒，数值越小说明时间越准。再执行 chronyc sources -v 可以查看每个时间源的同步状态，^* 前缀表示该源已被选为当前同步源，^? 表示不可达。
第四步：验证时间是否真正校准
用 date 命令查看系统时间，再与权威时间对比。更严谨的做法是执行 chronyc makestep 手动触发一次立即校正，然后再次运行 chronyc tracking 确认 Last offset 已经收敛到毫秒级。如果服务器时间偏差较大，chrony 默认的 makestep 策略可能不会自动跳变，需要你在配置中显式放开：
makestep 1 3
这行配置表示：如果偏差超过 1 秒，且在前 3 次更新内，就允许直接跳变校正，而不是缓慢调整。
时钟漂移排障：从现象定位到根因
即使部署了 chrony，时间同步仍可能失效。下面按”现象→原因→处理”的顺序，梳理最常见的几类问题。
现象一：chronyc sources 显示所有源都不可达
如果 chronyc sources -v 里所有源都显示 ^?，通常是网络层面被拦截。先检查防火墙是否放行了 UDP 123 端口，云服务器（VPS，虚拟专用服务器）还要确认安全组规则。用 ss -ulnp | grep 123 确认 chronyd 正在监听，再用 chronyc sources -v 观察源状态。若确认端口已放行仍不可达，可能是上游时间源本身故障，换一组时间源即可。如果你不确定当前服务器是否具备稳定的公网出口，可以参考虚拟主机与 VPS 的选型对比，选择网络质量更可控的方案。
现象二：时间同步后很快又漂移
这种情况多发生在虚拟化环境。宿主机与虚拟机的时间源互相干扰时，虚拟机时钟会反复跳变。处理方法是关闭虚拟机的硬件时钟自动同步，只保留 chrony 作为唯一时间源。在 KVM 虚拟机里，可以关闭 QEMU 的 rtc 时间同步特性，让 chrony 独占时间校准。物理服务器（独服，独立服务器）则要检查 BIOS 时钟是否异常，必要时更换主板电池。
现象三：日志时间戳与真实时间相差数小时
如果系统时间正确但日志时间戳仍错乱，问题往往出在时区配置，而不是时间同步。用 timedatectl 查看当前时区，执行 timedatectl set-timezone Asia/Shanghai 修正。注意 chrony 只负责同步 UTC 时间，时区由系统单独管理，两者不要混淆。
时间同步的日常巡检与最佳实践
部署完成后，建议把时间同步纳入日常巡检。可以写一个简单的定时任务，每天检查一次同步状态，异常时告警：
0 3 * * * chronyc tracking | grep -q "Leap status : Normal" || echo "chrony 异常" | mail -s "时间同步告警" admin@example.com
除了巡检，还有几个实践要点值得留意。第一，时间源不要只配一个，至少保留两个不同网络的时间源，避免单点故障。第二，iburst 参数在首次启动时能显著加快收敛，建议保留。第三，如果服务器同时承担 NTP 服务端角色，务必用 allow 精确限定可访问网段，不要开放给整个公网，否则容易被滥用放大流量。如果你希望进一步加固服务器安全，可以参考WordPress 主机安全加固建议，把时间同步与访问控制一起纳入安全基线。
总结与下一步建议
服务器时间同步看似基础，却是日志审计、证书校验和数据库复制共同依赖的底层能力。通过部署 chrony，你可以让服务器持续跟踪并校正时钟漂移，把时间偏差稳定控制在毫秒级。本文给出的安装、配置和排障步骤，覆盖了从新服务器初始化到故障定位的完整链路，你可以直接照着操作。
如果你需要一台开箱即用、网络稳定的服务器来承载这些运维实践，可以考虑 Hostease 的 VPS 主机方案，它提供独立公网 IP 和可自定义的系统环境，方便你按本文步骤完成 chrony 部署。如果你需要更高性能的物理资源，也可以参考 Hostease 独立服务器方案。建议你在部署完成后，把 chronyc tracking 的同步状态加入监控，并定期检查时间源可用性，这样时间漂移问题就能在影响业务之前被及时发现。