时间不对先别急着改系统时间：用 timedatectl、chrony 和 NTP 把时间同步讲清楚

服务器上的时间错了几分钟，很多人第一反应是直接用 date 命令把时间改回来。改完当时看着是对了，可过几天时间又慢慢跑偏，证书报错、日志时间对不上、定时任务在奇怪的时间点触发，问题一个接一个冒出来。手动改时间只是把表拨正了一次，并没有解决“时间为什么会错”这个问题。真正要做的是先搞清楚系统时间的来源，再让它自己保持准确：timedatectl、chrony 和 NTP，就是干这件事最顺手的三个工具。

第一步是先用 timedatectl 看清现状。timedatectl 不带参数会把本地时间、世界协调时、时区、系统时钟是否同步、NTP 服务是否开启一并列出来。排查时先看三件事：一是时区对不对，时区错了，本地时间看着永远差几个小时；二是 RTC 时间和系统时间是否一致，虚拟机重启后时间跳变，往往是硬件时钟和系统时钟打架；三是 NTP 服务到底开没开，没有同步源，时间只能靠机器自己的晶振慢慢漂移，越走越偏。

第二步是分清两种时间同步服务。老系统上常见的是 ntpd，新系统上主流是 chronyd，名字不一样，但干的活一样：定期向 NTP 服务器对时，并根据每次的偏差调整本地时钟的走速。它们的区别在于调整方式：ntpd 更倾向于一次性把时间跳变到正确值，而 chronyd 更擅长渐进式微调，让时钟一点点追上正确时间，不会让系统时间突然跳变。后者对正在跑的服务更友好——时间突然跳回去几秒，数据库事务、日志顺序和定时任务都可能出问题。

第三步是检查同步源本身通不通。服务在跑不代表同步成功：chronyc sources 或者 timedatectl 的同步状态会告诉你，系统正在向哪台服务器对时、最近一次同步是什么时候、偏差有多大。如果所有源都显示不可达，多半是网络层面的问题——NTP 走的是 UDP 123 端口，防火墙或者安全组没有放行，服务再正常也拿不到时间。云上服务器还有一个特殊情况：很多云厂商提供了内网 NTP 地址，走内网对时比走公网更稳，换一个源就能解决反复同步失败的问题。

第四步是理解“时间漂移”这件事。即使同步正常，虚拟机在宿主机调度、快照恢复、挂起再唤醒之后，时间也可能出现跳变。遇到这种情况，不要急着手动改时间：先让 chronyd 自己追一段时间，它会通过加快或放慢时钟走速把偏差消化掉；如果偏差已经大到几分钟甚至几小时，再考虑用 chronyc makestep 之类的方式一次性校准。手动用 date 改时间最大的问题是它不留痕迹，之后再出问题，连“时间是什么时候开始错的”都查不出来。

最后提醒一个常见误区：不要把时区问题和时间同步问题混在一起治。时区错了，改 date 只能骗过眼睛，换一个时区的用户看到的还是错的；时间本身错了，改时区也只是换个数字安慰自己。先用 timedatectl 把时区定对，再用 chrony 把时钟同步到 NTP 源上，最后用 chronyc tracking 确认偏差已经收敛到毫秒级。时间准了，日志、证书和定时任务才有共同的基准，排查其他问题时才不会被时间本身带偏。