为什么服务器时间必须保持同步
服务器时钟一旦出现漂移，很多看似无关的故障会陆续浮现：日志时间戳与真实事件对不上，SSL（Secure Sockets Layer，安全套接层）证书因”时钟超出有效期”校验失败而报错，数据库复制因时间戳冲突中断，cron（定期执行的定时任务）在错误的时刻触发。这篇指南教你用 chrony 为 Linux 服务器建立稳定的时间同步，并在时钟漂移出现时快速找到原因。
时间同步指的是让服务器本地时钟持续对齐到一个可信的时间源。现代系统绝大多数场景采用 NTP（Network Time Protocol，网络时间协议）方案：客户端周期性向时间服务器请求标准时间，再按往返延迟与偏移量修正本地时钟。正确配置后，服务器时钟偏差可以稳定控制在毫秒级。
需要先明确一点：时间同步不是”装个软件就万事大吉”。源服务器可达性、防火墙 UDP 端口、服务器负载、硬件电池老化，都会影响同步效果。下文围绕这些维度给出可落地的检查方法，帮助你一次性把时间同步配置到位。
理解 chrony 与时钟漂移
chrony 是广泛用于现代 Linux 发行版的时间同步守护进程，设计目标是替代老牌的 ntpd，尤其适合虚拟化环境、间歇性联网主机以及需要快速收敛的场景。Debian 系、RHEL 系以及众多云镜像都默认随 chrony 一起安装。
时钟漂移（clock drift）源自硬件振荡器频率的微小偏差。即便是质量不错的服务器主板，石英晶振每天也可能产生数百毫秒到数秒的累计偏差，温度、供电稳定性、CPU 负载都会放大这一偏差。漂移持续累积，若长时间不同步，偏差会从毫秒级涨到分钟级。
chrony 针对漂移做了两点优化：一是持续估算本地时钟的漂移速率并纳入修正；二是支持平滑步进（slewing），偏差较大时逐渐调快时钟而非瞬间跳跃，避免数据库等实时服务因时间骤变出错。这两点让 chrony 在虚拟机热迁移、网络抖动严重的场景下表现优于传统方案。
安装并启用 chrony 服务
在多数主流发行版上，chrony 的安装与启用都很直接。以 Ubuntu / Debian 为例：
sudo apt update sudo apt install -y chrony sudo systemctl enable --now chrony
以 CentOS / RHEL / AlmaLinux 为例：
sudo dnf install -y chrony sudo systemctl enable --now chronyd
安装完成后先确认服务处于 active 状态：
sudo systemctl status chrony sudo chronyc tracking
chronyc tracking 是 chrony 的命令行客户端，会显示当前同步状态、与源的偏差（offset）以及估计漂移率。看到 Leap status : Normal 且 System time 偏差合理，说明基础同步已建立；若报错或显示未同步，请看下面的配置部分。
配置可靠的时间源
chrony 的配置文件通常位于 /etc/chrony/chrony.conf（Debian 系与 RHEL 系路径一致）。核心通过 pool 或 server 指令声明时间源。
编辑配置文件，把时间源替换为你所在区域可达的源。以下是以阿里云、腾讯云常用 NTP 服务器以及公共源为例的写法：
pool ntp.aliyun.com iburst pool ntp1.aliyun.com iburst server time.cloudflare.com iburst
iburst 表示启动时快速发送多个请求，在几秒内完成首次同步，而不是等默认轮询周期。配置完成后重启服务并检查同步：
sudo systemctl restart chrony sudo chronyc sources -v
chronyc sources -v 会列出每个时间源的应答状态。^* 前缀表示该源被选为当前有效同步源，^* 出现说明同步链路正常；^? 则代表源不可达。面向国内业务时，优先使用阿里云、腾讯云的 NTP 源能获得更低往返延迟；面向海外业务，time.cloudflare.com 等公共源往往更合适。
需要留意，NTP 使用 UDP 123 端口。若启用了防火墙，请放行 UDP 123 的出站与入站流量，否则客户端发不出请求、服务端也收不到应答，chronyc sources 会持续显示 ^?。关于访问控制与限流的做法，可参考 Nginx limit_req 限流防护。
处理显著的时间跳跃
如果你确认当前没有重要的实时事务在跑，可以通过 makestep 指令允许大偏差时立即步进。在配置文件里加入：
makestep 1 3
makestep 1 3 的含义是：当偏差超过 1 秒（示例区间，可按需调大），且在前 3 次时钟更新尝试中允许步进。默认配置通常已包含类似的 makestep 1 -1（-1 表示不限制次数），若自行覆盖该行，务必确认语义。手动强制即时同步可执行：
sudo chronyc makestep
执行后再次查看 chronyc tracking，确认 System time 和 Last offset 回落。对于时间偏差极大的机器，这是最快的恢复手段。
持久化与硬件时钟
服务器拥有两套时钟：系统时钟与硬件时钟（RTC，Real-Time Clock，实时时钟）。chrony 只管系统时钟，但开机瞬间系统时钟需要从硬件时钟读取初始值；若硬件时钟长期没被校正，重启后时间又会被带偏。
在配置文件中加入 rtcsync 指令，让 chrony 周期性把系统时间写回硬件时钟：
rtcsync
多数发行版默认带 rtcsync。若服务器频繁断电重启，建议显式确认这行存在。硬件时钟的纽扣电池一般能维持数年，一旦电量耗尽，重启后时间会回到出厂值——这类故障往往表现为”每次重启时间都错”，需要更换 CMOS 电池，软件配置无法根治。
时钟漂移的常见排障路径
时间同步出问题的原因可归为几类，可按下面顺序排查。
时间源不可达。 先看 chronyc sources -v 是否出现 ^?。可能原因：UDP 123 被防火墙拦截、时间源域名解析失败、源服务器故障。换一个源再试，可排除单个源的问题。若站点同时存在证书异常，可参考 Certbot SSL 证书排障。
本地时钟漂移过大。 如果 chronyc tracking 显示的 Estimated drift 数值异常大，说明本地振荡器偏差明显，可能受高温或高负载影响。可在服务器空载时段重新校准，观察漂移率是否回落。
虚拟机时间跳跃。 在 KVM、VMware 等虚拟化环境里，宿主机时钟抖动会传导给虚拟机。可尝试改用 TSC（Timestamp Counter，时间戳计数器）时钟源，并在配置中避免频繁 makestep，改用平滑校准。
DNS 解析失败。 NTP 源通常用域名配置，若服务器的 DNS（Domain Name System，域名解析系统）异常，域名解析不到 IP，同步同样失败。可临时改用 IP 形式的 server 指令验证是否为 DNS 问题，确认后再恢复域名写法。把根因先定位清楚再动手，这一排障思路与 MySQL 慢查询分析 强调的方法论一致。
监控同步状态的长期做法
时间同步不是一次性操作，而是需要持续观察的指标。建议把”时钟偏差”纳入服务器基础监控，与 CPU、内存、磁盘等指标一同巡检。可以写一个简单的健康检查脚本，周期读取 chronyc tracking 的输出，当 System time 绝对值超过设定阈值（例如 100 毫秒，示例区间）时触发告警。
对于已经跑着数据库、缓存的机器，时间偏差过大可能引发数据一致性问题。MySQL 慢日志的时间戳若失真，会干扰排障结论（详见 MySQL 慢查询分析）；Redis 的过期策略依赖时间戳，时钟跳跃会导致部分键提前或延后过期，进而影响缓存命中率（可参考 Redis 持久化与恢复机制）。
把这些依赖时间的服务串起来看，时间同步是它们共同的地基。建议定期用 chronyc tracking 抽查，或在监控面板中加入时间偏差曲线。
总结与行动建议
服务器时间同步是运维里成本最低、收益却很高的基础工程。部署 chrony、配置可靠的时间源、允许必要时的 makestep、保持 rtcsync 持久化，四步即可构建稳定的时间同步链路；再结合 chronyc tracking 与 chronyc sources -v，绝大多数时钟漂移问题都能在几分钟内定位。
建议你先把时间源配置与 makestep、rtcsync 落到测试服务器上验证，再推广到生产环境。生产变更前务必备份 /etc/chrony/chrony.conf，变更后通过 chronyc sources -v 确认 ^* 源出现。如果你需要一台拥有完整 root 权限、便于自主配置时间同步与各类基础服务的服务器，可以了解 Hostease 的 独立服务器 方案；若希望以较低成本启动并逐步扩展，VPS（虚拟专用服务器，即在一台物理机上隔离出的独立运行环境）主机方案 也是合理的选择。