几台机器的日志对不上时间、HTTPS 突然报证书尚未生效、定时任务是空的、数据库主从报时间偏移——这些现象看着毫不相干但相当一部分的根因是同一个某台机器的系统时钟偏了。时间这件事在单机上几乎没人注意一旦涉及证书、分布式、跨机排查日志它就会变成那种查一天查不出来的问题。这篇讲清楚三件事Linux 的时间到底由几部分构成、时间不对会具体怎么坏事、以及一次配好不再管的做法。一、先分清Linux 上有两套时间这是所有校准操作的前提搞混了会改错地方。叫什么谁在维护怎么看系统时钟软件时钟内核date、timedatectl硬件时钟RTC主板上的电池hwclock -r开机时系统从 RTC 读一个初始值之后就由内核自己走。断电重启才会再用一次 RTC所以 RTC 准不准决定了冷启动那一刻准不准平时的精度靠软件时钟的同步机制。还有第三个变量——时区。内核里存的始终是从 1970 年算起的秒数UTC显示出来的本地时间是用时区换算的。所以本地时间变了可能是时区变了也可能是时钟真的偏了这两种情况的处理完全不同。一条命令能看到全部状态timedatectl status输出里重点看这几行Time zone、NTP service、System clock synchronized、RTC in local TZ。最后这行如果不是no建议改回来——硬件时钟保持 UTC 是通用做法阿里云对镜像的要求里也明确写了这一点。原因不难理解如果 RTC 按本地时区存遇到夏令时切换或者跨时区迁移时间戳会出现重复或跳过的区间日志顺序会彻底乱掉。统一用 UTC 就没这个问题什么时候显示都交给时区去换算。二、时间不准会连带出哪些事按被发现的概率排现象为什么会这样HTTPS 报证书无效、尚未生效证书有效期完全依赖本地时间偏了几年直接连不上多台机器日志串不起来排查跨服务问题时只能靠猜顺序定时任务是空的cron 按时间触发时间点被跳过去就不会补数据库主从、分布式选举异常复制位点、租约、心跳都带时间窗口API 签名、一次性口令验证失败这类签名通常带 ±5 分钟的有效窗口监控图出现断点或画到未来时间戳回跳会让数据被判定为过期或直接落到时间轴外这里面有一条特别值得记住时间往回跳比往后再跳更危险。一个正在跑的程序如果依赖单调时间做超时判断突然发现现在比刚才还早行为就可能错乱。这也是后面选 chrony 的一个理由——它默认就不会用跳变的方式调整时间。三、云平台镜像其实多半已经配好了在动手改配置之前先确认一下是不是真的需要改。这几家的公共镜像都预置了时间同步阿里云官方明确说明公共镜像中包含了默认的时间同步配置基于公共镜像创建的 ECS 会默认运行 Chrony 或 NTP 服务阿里云的 NTP 服务器不收费。华为云官方文档写明使用 x86 类型公共镜像创建的云服务器默认使用 chronyd 进行时间同步无需配置 NTP 服务器。腾讯云新购实例同样是配好的但官方文档专门列了一条常见问题——用自定义镜像创建的云服务器时间不对。也就是说一台刚开的机器时间不准常见原因是下面这几种而不是没有配置 NTP用了自定义镜像制作过程中同步配置被还原。腾讯云对此有明确解释这是 Cloud-Init 初始化导致的需要在制作镜像前处理掉cloud.cfg里的 NTP 相关配置。改过 DNS。内网 NTP 域名依赖内网 DNS 解析改了 DNS 同步就断了——这条下面第六节会展开。只是时区不对看着像差了 8 小时。服务没开机自启动重启之后就再没同步过。先过一遍这四条能省掉很多无谓的配置改动。四、先排除差 8 小时那是时区不是时间date出来的时间和你手机上的差整 8 小时第一步应该怀疑时区而不是同步服务。timedatectl list-timezones | grep Shanghai # 确认名称 timedatectl set-timezone Asia/Shanghai hwclock -w # 把当前系统时间写回硬件时钟linux服务器修改时区这件事用一条命令就能完成不需要动同步服务。改完再date一次。这一步做对了很多看着像时间不对的工单到这儿就结束了。判断方法其实很直接偏移量是整小时尤其是整 8 小时优先查时区偏移量是不规则的几分钟到几小时才是同步问题。五、chrony 还是 ntpd看数据说话这一节回答工具选型。chrony 官方网站上有一份对比测试数据是把两台机器放在模拟 Linux 环境里跑出来的单位微秒100 次模拟的均值与标准差详见 chrony 官方 comparison 页测试场景网络抖动chronyntpd长期联网 时钟稳定10 μs35 ± 8234 ± 46长期联网 时钟不太稳10 μs14 ± 0165 ± 17间歇联网每 24 小时只有 30 分钟能连10 μs7273 ± 1744608803 ± 510468前两行是chrony 更准的量级差距第三行是真正的关键同样是每天只有半小时能联网chrony 把误差控制在毫秒级ntpd 已经跑到 0.6 秒量级。chrony 官方原话列出了它更适合的场景可以直接对照自己的机器只有几分钟时间联网网络经常拥塞机器经常关机或挂起时钟本身不太稳温度变化快或者是虚拟机需要在没有硬件参考钟的隔离网络里用 NTP另外几条跟运维实践直接相关的差异chrony 默认不以跳变方式调整时间避免打断正在运行的程序ntpd 要配成不跳变的话得换另一种校时方式代价是精度下降。chrony 能适应的时钟频率偏移范围更大某些虚拟机里抽风的时钟也能拉回来。这条对云服务器尤其重要——虚拟机的时钟本来就不如物理机稳。chrony 体积更小、按需唤醒 CPU对省电也有好处。还有一个趋势方面的理由ntp 这个老实现基本已经不再被维护阿里云官方文档直接给出建议——如果 ECS 实例使用的是 NTP 服务且业务不依赖 NTP 服务建议升级为 Chrony。顺带回答一个常被问到的问题Ubuntu 上有自带的systemd-timesyncd能不用 chrony 吗chrony 官方 FAQ 的建议是可以但优先选 chrony。原因是 timesyncd 不能同时轮询多个服务器也就无法识别出时间本身是错的那个服务器NTP 术语叫 falseticker用它配公共 NTP 池是有风险的。六、一次配好chrony 的最小可用配置# Debian / Ubuntu apt update apt install -y chrony # RHEL / CentOS / Rocky / AlmaLinux yum install -y chrony systemctl enable --now chronyd配置文件位置要注意RHEL 系是/etc/chrony.confDebian 系是/etc/chrony/chrony.conf。chrony 官方 FAQ 给出的最小可用客户端配置是这四行照抄就够用pool NTP服务器域名 iburst driftfile /var/lib/chrony/drift makestep 1 3 rtcsync每一行都不是摆设指令作用pool/server指定时间源。chrony 官方建议至少配三个少于三个就无法通过交叉比对识别出时间错误的源iburst启动时连发一串请求加速首次同步不用等默认的轮询间隔driftfile记录本机时钟的漂移速率每天快多少秒下次启动直接在这个基础上收敛省掉重新测量的时间makestep 1 3偏差超过 1 秒时允许前 3 次更新直接跳变。不加这条偏差大时 chrony 会慢慢追可能要追很久rtcsync定期把系统时间写回硬件时钟这样下次冷启动从 RTC 起步时就已经比较准了改完重启服务然后用这两条看结果chronyc sources -v # 某行前面出现 ^* 表示已选中这个源并同步成功 chronyc tracking # 看 Reference ID、Last offset、Leap status首次同步需要几分钟别刚配完就下结论。华为云文档里也专门提醒了这一点chronyc sources -v要等一会儿才会出^*。如果偏差很大又不想等可以强制校正一次chronyc -a makestep上面这几条连同第六节的配置文件基本就是日常会用到的 linux服务器时间校准命令全集了——实际操作里不需要记更多。七、各家云平台的 NTP 服务器地址做 linux服务器时间同步ntp服务器的配置时三家的地址都要区分内网和公网详见阿里云时间同步、腾讯云 NTP 服务概述、华为云 NTP 服务器配置内网地址公网地址阿里云 ECSntp.cloud.aliyuncs.comntp.aliyun.com、ntp1~ntp7.aliyun.com腾讯云 CVMtime1~time5.tencentyun.comntp.tencent.com、ntp1~ntp5.tencent.com华为云 ECS各区域统一ntp.myhuaweicloud.com同上需配合华为云 DNS四条使用注意一、优先用内网域名。阿里云ntp的地址分为内网ntp.cloud.aliyuncs.com和公网ntp.aliyun.com两组官方文档明确推荐 ECS 使用 VPC 内网域名“以获得更低的网络延迟”。这不是客气话——NTP 的精度直接受网络抖动影响第三节那张表里的第一列就是网络抖动10μs 和 10ms 的结果差了一个数量级。二、腾讯云的内网域名拼写要照抄。是tencentyun.com不是tencent。这是腾讯云ntp服务器官方文档上给出的地址手打很容易写错写错了的现象是 DNS 解析失败、一个源都连不上。腾讯云另外标注time1~time5.cloud.tencent.com是旧的外网地址仍可用但建议改用新的。三、NTP 域名依赖 DNS。这条最容易在大扫除时被踩到华为云文档明确要求使用华为云提供的 NTP 服务器时需和华为云 DNS 服务器配套使用腾讯云在改 DNS 的影响说明里也写着影响服务器的时间同步 NTP 功能该功能依赖内网域名。所以自己改了/etc/resolv.conf之后发现时间不同步第一反应应该是查 DNS 而不是查 chrony 配置。四、华为云不区分区域各区域都是同一个域名不需要按 Region 去找对应关系。如果想知道当前到底同步到哪个源chronyc tracking输出里的 Reference ID 会告诉你。八、UDP 123 端口什么时候才真的需要放行NTP 用 UDP 123阿里云文档里有一句需要在实例安全组的入方向添加安全组规则并放行 UDP 123 端口。这句话容易被执行过头它其实要分角色看只作为客户端绝大多数情况机器主动向外发起连接走的是出方向。主流云厂商的默认安全组对出方向一般是放开的通常什么都不用配。作为服务给别的机器校时才需要入方向放行 UDP 123。看到要开 123 端口就去改安全组之前先确认这台机器扮演的是哪种角色。给内网其他机器做校时汇聚点的那台需要入方向规则其余机器不用。验证端口排除不了的话可以从时间序列上看chronyc sources里源显示?或x不可达先查 DNS 能不能解析再查出方向 UDP 123 通不通。九、linux服务器怎么和另外一台服务器时间校准这是集群内网场景的常见问法解法和单机不一样。要的是机器之间的一致不是每台都各自对准外网。正确做法是指定一两台时间源机器让它正常同步到外网或云内网 NTP其余机器的 chrony 配置指向这台机器配成server 内网IP iburst时间源机器上需要加allow 内网网段chronyd 默认不对外提供校时服务必须显式允许才会打开服务端端口这么做的好处是两台机器之间的偏差只受内网抖动影响通常能压到亚毫秒级比各自同步外网稳定得多。顺带说一句跨机房的场景如果两边之间延迟高且抖动大别指望靠 NTP 把偏差压到微秒级。这种时候要考虑 PTP精确时间协议它靠硬件时间戳实现是另一个量级的方案。十、时间对不上时的排查顺序把前面串起来实际排查就按这五步走每步结论明确1. timedatectl status 看 NTP service 是否为 active、System clock synchronized 是否为 yes 2. timedatectl status 看 Time zone偏移是整小时先改时区 3. chronyc sources -v 看有没有 ^*没有则往下查 4. getent hosts NTP域名 看 DNS 能不能解析内网域名 5. chronyc tracking 看 Last offset 有多大判断是否要 makestep一、二两步能解决掉绝大部分看着不对的情况。真正卡住的是第三步之后而那几步的根因通常集中在 DNS 和出方向端口两处。这也是 linux服务器时间校准这件事里唯一值得记住的顺序——先分现象再动配置。回到开头那些现象。linux服务器时间校准这件事本身不难难的是它出问题时总伪装成别的故障——证书错误、任务不跑、日志顺序离谱。把顺序记牢就行先分是时区还是时钟再看同步服务有没有在跑最后才去翻配置文件。新开的机器默认多半已经配好了真正需要动手的是那些用自定义镜像创建的、迁移过来的、或者改过 DNS 的。chrony 装上之后基本就不需要再管它driftfile会帮它记住这台机器走快还是走慢重启也能很快收敛。日常只需要偶尔看一眼chronyc sources -v里那个^*还在不在。各家提供的 NTP 服务器地址和配置方式会随时调整实际使用时以官网当期公示的文档为准。