服务器时间不对，先别急着重装：用 timedatectl 与 chrony 三步对准时间

服务器时间差几分钟，看起来是小事，实际能连锁惹出不少麻烦：HTTPS 证书校验失败、登录态刚签发就过期、定时任务在错误的时间跑、日志时间戳对不上，排障时两台机器的日志根本拼不到一起。遇到这类症状，先别急着重装系统或重启服务，按下面三步把时间对准，往往问题就消失了。

第一步，先看清现在到底差多少。执行 timedatectl，重点看三行：Local time 是系统当前时间，Universal time 是对应的 UTC 时间，System clock synchronized 是 yes 还是 no。如果显示 no，说明系统根本没有在同步时间，后面调什么服务配置都是白搭。再用 date 和 date -u 对照看一次，确认本地时区是不是你想要的；很多云服务器默认是 UTC，如果业务按北京时间跑，时区不对会让“时间差了 8 小时”的假象出现。用 timedatectl set-timezone Asia/Shanghai 可以改时区，改完再跑一次 timedatectl 确认。

第二步，让 chrony 接管同步，而不是手动 date 改时间。手动用 date -s 改时间只管一时，重启或漂移后还会歪，而且往回调时间可能让数据库、证书和定时任务出现“时间倒流”的怪现象。正确做法是装好并启动 chrony：Debian/Ubuntu 用 apt install chrony，RHEL 系用 dnf install chrony，然后 systemctl enable --now chronyd。再跑 chronyc tracking 看同步状态，Reference ID 有值、Stratum 在合理范围、System time 的偏差在毫秒到秒级，就说明已经跟上时间源了。如果 chronyc sources 里所有源都显示问号或 unreachable，先别怀疑 chrony 本身，八成是出方向的 UDP 123 端口被安全组或防火墙挡住了，放行后再等一两分钟看。

第三步，对准后做一次业务级验证。时间同步显示正常还不够，要回到最初的故障点验证：重新访问之前报证书错误的地址，看握手是否恢复；重新登录一次，看 token 是否不再“刚发就过期”；跑一次 journalctl --since “5 minutes ago”，确认新日志的时间戳与手表一致。顺手再看一眼 timedatectl 里的 RTC time，如果硬件时钟与系统时间差得离谱，关机重启后还会漂移，可以用 timedatectl set-local-rtc 0 明确让硬件时钟走 UTC，避免双系统或重启后反复错乱。

还有两个容易踩的坑值得单独记下来。一是不要在同一台机器上同时跑 chronyd 和 systemd-timesyncd 或 ntpd，两个同步服务抢时间源会互相打架，表现为时间一会儿准一会儿歪，留一个、停掉并禁用另一个才干净。二是容器和虚拟机的时间一般跟宿主机走，容器里再装一套同步服务往往改不动，时间不对要先去宿主机上查，而不是在容器里反复调。

总结成一句口诀：先用 timedatectl 看清差多少、再用 chrony 持续同步、最后回到业务故障点验证一次。时间准了，证书、登录、定时任务和日志这些“玄学问题”会少一大半，排障也能从对时间戳开始，而不是从重装开始。