为什么服务器时间会漂移，以及它带来的麻烦
服务器时间一旦不准，影响往往比想象中严重。HTTPS 证书校验、日志时间戳、数据库事务、定时任务调度，全都依赖系统时钟。如果时间偏差超过几分钟，证书可能被判定为过期，日志排障会错乱，cron 任务可能在错误的时间点执行。这篇文章会教你如何搭建一台内网时间服务器，用 NTP 与 chrony 统一管理多台服务器的时钟，并给出部署、配置与验证的完整方法。与单纯讲解单机排障不同，这里重点解决的是内网多机时间不一致的问题，帮助你从源头避免时间偏差引发的各类故障。无论你用的是云服务器（即 VPS，虚拟专用服务器）还是物理机，时间同步都是上线前必须做好的基础配置。
NTP 与 chrony：先搞清楚两者的区别
NTP（网络时间协议）是让服务器与时间源服务器保持同步的标准协议，它通过 UDP 123 端口与上游时间服务器交换时间戳，把本地时钟校准到毫秒级精度。chrony 则是 NTP 协议的现代实现，相比传统的 ntpd 守护进程，chrony 在启动时能更快完成同步，对网络抖动和间歇性断网的容忍度更高，因此成为主流 Linux 发行版的默认时间同步方案。
两者最直观的差异体现在同步速度上。ntpd 在刚启动时往往需要几分钟甚至更久才能把时间校准到位，而 chrony 通常能在几十秒内完成首次同步。对于经常重启的云服务器（即部署在云端、按需租用的服务器），或者网络环境不稳定的场景，chrony 的优势非常明显。如果你的系统是 CentOS 8、Ubuntu 20.04 及更新版本，默认安装的就是 chrony，无需额外替换。关于服务器基础配置的更多内容，可以参考我们整理的服务器配置与优化专题。
内网时间服务器部署：从安装到配置的完整步骤
在开始之前，请确认你的服务器能访问外网，并且防火墙放行了 UDP 123 端口。下面以 CentOS 和 Ubuntu 两个主流发行版为例，演示完整的部署流程。
第一步：安装 chrony
CentOS 系列使用 yum 安装，Ubuntu 系列使用 apt 安装：
# CentOS / RHEL sudo yum install -y chrony # Ubuntu / Debian sudo apt update sudo apt install -y chrony
安装完成后，chrony 服务会自动启动，你可以用 systemctl status chronyd 确认服务状态为 active。
第二步：配置时间源
chrony 的主配置文件位于 /etc/chrony.conf。默认配置已经包含了一组公共时间服务器，但为了更稳定，建议根据服务器所在区域选择就近的时间源。以中国大陆服务器为例，可以配置阿里云或腾讯云提供的公共 NTP 服务器：
# /etc/chrony.conf server ntp.aliyun.com iburst server ntp1.aliyun.com iburst server ntp.tencent.com iburst
iburst 参数表示在启动时快速发送多个时间请求，帮助 chrony 更快完成首次同步。配置完成后，重启服务使配置生效：
sudo systemctl restart chronyd sudo systemctl enable chronyd
第三步：验证同步状态
使用 chronyc tracking 查看当前同步状态，重点关注 Leap status 是否为 Normal，以及 System time 显示的偏差值：
chronyc tracking
如果输出中 Stratum 为 2 或 3，说明服务器已经通过上游时间源完成同步。再用 chronyc sources -v 查看时间源列表，确认每个源的状态标记为 ^*（当前选中的同步源）或 ^+（可用的候选源）。时间同步是服务器稳定运行的基础，配合合理的网站性能优化策略，能显著提升整体服务质量。
第四步：让 chrony 作为内网时间服务器
如果公司内部有多台服务器需要统一时间，可以让其中一台作为内网时间源，其余机器从它同步。在作为时间源的服务器上，编辑 /etc/chrony.conf，添加允许内网网段访问的规则：
# 允许 192.168.1.0/24 网段访问 allow 192.168.1.0/24
其他内网机器则把时间源指向这台服务器，例如 server 192.168.1.10 iburst。这样既能减少对外部公共时间源的依赖，也能保证内网所有机器时间一致，避免因各机器时间不同步导致日志对不上、任务调度错乱等问题。需要注意的是，内网时间源服务器本身仍要持续与外部公共时间源同步，否则一旦它自身漂移，整个内网都会跟着出错。
时钟漂移排障：常见问题与定位方法
即使配置正确，服务器时间仍可能出现偏差。下面梳理几个最常见的故障场景，以及对应的排查思路。
场景一：时间始终无法同步
如果 chronyc sources 显示所有时间源都是 ^?（不可达），优先检查网络连通性。用 chronyc sources -v 查看具体错误，再用 ping 或 nc -u -v 时间源IP 123 测试 UDP 123 端口是否可达。很多云厂商的安全组默认只放行 80 和 443 端口，需要手动放行 UDP 123。
场景二：时间偏差很大，同步缓慢
当服务器时间偏差超过几分钟时，chrony 默认的步进策略可能不会立即大幅调整，而是缓慢校准。此时可以临时允许大步进，在配置文件中加入 makestep 1 3，表示在前三次同步中允许一次性步进调整，之后则采用平滑微调。修改后重启服务，通常能快速把时间拉回正确值。
场景三：重启后时间又漂移
如果服务器每次重启后时间都会跳变，很可能是硬件时钟（RTC）本身不准。可以用 timedatectl 查看硬件时钟状态，并执行 sudo hwclock --systohc 把系统时间写回硬件时钟，让重启后也能保持准确。对于承载关键业务的独立服务器，建议把时间同步纳入自动化巡检脚本，避免人工遗漏。
时间同步的运维建议与总结
时间同步看似基础，却是最容易在排查时被忽略的环节。建议你在服务器上线时就把 chrony 配置好，并定期用 chronyc tracking 检查偏差值。如果发现偏差持续增大，优先排查网络连通性和时间源配置，而不是盲目重启服务。
对于需要高精度时间同步的业务，比如金融交易或分布式数据库，可以考虑配置多个时间源并启用 NTP 认证，进一步提升可靠性。如果你需要一台稳定、网络配置灵活的服务器来承载这些业务，可以了解一下 Hostease 的 VPS 主机（虚拟专用服务器）方案，它提供了完整的 root 权限，方便你自由配置 chrony 等系统服务。总结来说，把时间同步纳入日常巡检清单，能帮你避免大量由时间偏差引发的隐性故障。