服务器时间不准会带来哪些麻烦
个人站长买了服务器之后，很少有人会专门去检查系统时间，直到某一天问题集中爆发：凌晨三点该跑的备份脚本没跑，查 crontab 发现配置没错，看日志才发现服务器时间比真实时间慢了两个小时；网站日志和 CDN 访问日志对不上，排查问题的时候时间线完全错乱；更严重的是，如果网站启用了 HTTPS 证书校验，本机时间错误会导致 TLS 握手直接失败，浏览器报出"证书无效"的错误，访客全部被拦在门外。这些坑的根源只有一个：服务器时间没有做同步。
云服务器厂商在创建实例的时候一般会预装时间同步服务，但很多低价 VPS、自建机房服务器、以及重装过系统的机器，时间同步往往是缺失的。系统运行时间越长，时钟漂移越明显，一块普通的 PC 主板时钟一天漂移几秒很正常，一个月就能差出几分钟。
一、先分清时区和时间同步
时区（Timezone）和网络时间同步（NTP）是两件不同的事。时区决定的是"显示成几点"，比如北京时间是 UTC+8；时间同步决定的是"绝对时间准不准"。很多站长把两者混为一谈，改完时区就以为时间准了，其实系统时钟的漂移一点没解决。正确的做法是：用 timedatectl 设置好时区，同时用 NTP 服务持续校准系统时钟，两个都要做。
Linux 系统里有两套时钟：硬件时钟 RTC（就是主板上的电池时钟）和系统时钟（内核维护）。开机时内核读取 RTC 作为初始时间，运行期间以系统时钟为准。NTP 同步的是系统时钟，关机状态下 RTC 继续走，所以 RTC 也需要定期校准，否则每次开机都会带着误差启动。
二、主流时间同步方案怎么选
目前 Linux 上常见的时间同步方案有四个。systemd-timesyncd 是 systemd 自带的轻量客户端，只做简单的客户端同步，配置最少，适合要求不高的场景，Debian/Ubuntu 默认就启用它。chrony 是目前最推荐的专业方案，它是 ntpd 的现代替代品，同步速度快、精度高，对网络抖动有更好的适应性，CentOS 8 之后的 Red Hat 系发行版默认使用它。老牌的 ntpd 功能完整但启动慢、配置繁琐，已经逐渐被 chrony 取代。ntpdate 只是一个一次性同步命令，同步完就退出，适合手动校准或者写进开机脚本，不建议作为常驻方案。
个人站长的服务器，无脑选 chrony 就对了。下面以 Debian/Ubuntu 为例演示完整配置流程。
三、chrony 安装与配置详解
apt install chrony
systemctl enable --now chronyd安装完成后编辑 /etc/chrony/chrony.conf，关键配置项如下：
# 时间源服务器，iburst 表示启动时快速连发请求完成初次同步
pool 2.debian.pool.ntp.org iburst
pool 0.cn.pool.ntp.org iburst
# 本地漂移率记录文件
driftfile /var/lib/chrony/drift
# 允许本机作为时间服务器，为内网其他机器提供同步
allow 192.168.1.0/24
# 如果长时间无法联网同步，允许本机宣布自己为权威时间源
local stratum 10
# 首次同步时，如果系统时间偏差超过 5 秒，立即大步校正
makestep 5 3几个参数要重点解释一下。makestep 5 3 的意思是：如果时间偏差超过 5 秒，在前 3 次更新时直接跳变校正；平时偏差小，则采用缓慢的微调方式，避免时间跳变影响日志和数据库。allow 是给内网其他机器提供 NTP 服务的白名单，单机部署可以不要。local stratum 10 在断网时会自动降级使用本机时钟，保证内网时间不混乱，但要注意配置了它之后要配合 firewall 放行 UDP 123 端口。
改完配置执行 systemctl restart chronyd 生效。国内服务器建议把时间源换成国内 NTP 服务器，比如阿里云的 ntp.aliyun.com、腾讯云的 ntp.tencent.com，或者 2.cn.pool.ntp.org，延迟更低，同步更稳定。
四、时区设置与状态查看
时区用 timedatectl 管理，几个常用命令：timedatectl list-timezones 列出所有可用时区，timedatectl set-timezone Asia/Shanghai 设置北京时间，timedatectl status 查看当前状态。输出里的 System clock synchronized: yes 表示 NTP 同步成功，NTP service: active 表示同步服务在运行，这两个字段是判断时间同步是否正常的最快方式。
查看同步质量用 chronyc 命令。chronyc sources -v 列出时间源及状态，^ 开头的行表示该源可用；chronyc tracking 显示当前系统时间与参考源之间的偏差，其中 System time 一行的值就是当前误差，单位是纳秒，正常情况应该在几百微秒以内；chronyc sourcestats 可以查看每个时间源的统计信息。如果发现某个时间源频繁报错，可以直接在配置文件里删掉它换一个。
五、常见问题排查清单
第一，同步状态一直是 no。先检查 UDP 123 端口是否被防火墙拦截：iptables -L -n 或者 firewall-cmd --list-all，确认放行 udp 123；再确认能连上时间服务器：chronyc sources -v 里如果全部是问号，说明网络不通，可以试试 nc -u -z ntp.aliyun.com 123 探测端口。第二，时间偏差非常大，比如差了几天。这种要手动先校正一次：先 timedatectl set-ntp false 关掉同步，用 date -s 设置一个接近的时间，再重新开启同步，让 chrony 逐步收敛，避免直接大步跳变引起日志混乱。第三，虚拟化环境时钟漂移特别快。KVM 虚拟机建议安装 virtio 时钟驱动，VMware 虚拟机装 open-vm-tools，这些驱动能显著改善时钟漂移。第四，容器环境里要挂载宿主机的 /etc/localtime 并共享时钟，Docker 默认继承宿主机内核时钟，容器里改时间会直接影响宿主机，千万别在容器里手动 set date。
六、常见问题答疑
问：执行 timedatectl set-ntp true 报错 Failed to set ntp: NTP service: inactive 怎么办？答：这个错误说明系统里没有可用的 NTP 服务，通常是 systemd-timesyncd 和 chrony 都没安装或者都被禁用了。先确认 chrony 已经安装并启用：systemctl enable --now chronyd，然后重新执行 timedatectl set-ntp true，一般就能恢复正常。
问：重启服务器后时间又乱了，明明同步过？答：这是 RTC 硬件时钟的问题。NTP 只校准系统时钟，关机后靠 RTC 维持走时，如果 RTC 本身偏差大，每次开机都会带着旧误差启动。解决办法是校完系统时间后执行 hwclock --systohc，把系统时间写回硬件时钟；也可以用 timedatectl 确认 RTC 使用的是 UTC 标准。如果服务器主板电池没电了，RTC 每次开机都会归零，这种只能换电池解决。
问：日志里的时间和当前时间对不上怎么办？答：先执行 date 看系统时间本身是否正常，再执行 timedatectl 确认时区配置，日志记录用的是系统时间，时区错误会导致所有日志时间整体偏移八个小时。修正时区后执行 journalctl --rotate 让日志按新时区重新归档，新的日志就会落在正确的时间点上。
问：多台服务器时间不一致有什么影响？答：影响最大的场景是数据库主从复制和集群日志分析：主从之间时间差太大会导致复制冲突判断出错，日志时间线对不上会让人误判故障的先后顺序。建议所有服务器统一使用同一组 NTP 时间源，并在监控系统里加上时间偏移告警，偏移超过阈值就提醒人工处理，把问题消灭在早期。
问：怎么确认 chrony 一直在正常工作？答：除了定期看 chronyc tracking 之外，可以检查 chrony 自己的日志：journalctl -u chronyd 会记录启动信息、时间源切换和重大校正动作。更主动一点的做法是把 chronyc tracking 输出的 System time 绝对值接入监控曲线，如果长期稳定在毫秒级以内，说明同步链路是健康的。
时间同步看起来是小事情，却是服务器运维里最基础的稳定性保障。花十分钟把 chrony 配好、时区设对、UDP 123 放行，备份、日志、证书校验、监控告警这些依赖时间的功能才能各司其职，网站出问题的时候你才能靠日志快速定位到真正的原因。