证书明明没过期，浏览器却报不安全，点开详情写着证书尚未生效；或者用户投诉下午三点打不开，翻访问日志那个时间点干干净净。这两个现象看起来毫无关系，根子往往是同一个，机器时间不对。时间这件事在服务器上分三层，容易混：一层是系统时钟本身准不准，靠NTP和上游对时；一层是这台机器认为自己在哪个时区，决定日志里写出来的钟点；还有一层是应用自己的时区设置，PHP和数据库各有一份。三层里任何一层偏了，表现出来的都是时间错乱，但改的地方完全不同。
证书校验对时间的敏感度超出很多人预期。证书里写着生效时间和失效时间，客户端拿本地时间去比，比出界就直接判不合法。机器时间慢了几小时，新签发的证书会被当成还没生效；快了一两年，没到期的证书会被当成已过期。Let's Encrypt签发的证书有效期就是九十天，时间偏上一周，自动续费那一步也容易踩坑。
查时间先看timedatectl，它一次给出三项：本地时间、是否同步、NTP服务是否在跑。同步那一项显示no，就说明这台机器在自己走，不跟上游对，偏差会一点点累积。date只给出当前时间，看不出有没有在同步。
时区这三层要分别确认。系统层看timedatectl里的Time zone；PHP层看date.timezone配置项，它决定程序里date()函数输出什么；MySQL层看time_zone变量，它影响NOW()和存储的时间。三层不一致时，同一次操作在日志里会留下两个不同的钟点。
对时用chrony或者systemd-timesyncd，两个都是现在发行版自带的，装好之后开启服务并确认状态是已同步，不需要自己写定时任务。chronyc tracking里的System time一行就是当前偏差，单位是秒，正常是很小的小数。
系统时钟改好之后，硬件时钟可能还是旧的。重启时如果从硬件时钟回读，时间又会被拽回去，所以要用hwclock把系统时间写回硬件，这一步容易被跳过。
容器里跑的服务要单独看。容器和宿主机共用同一个内核时钟，但时区是从镜像里带过来的，镜像时区和宿主机不一致时，两边日志的钟点从一开始就对不上，排查时先确认两边报的是不是同一个时间。
时间偏了不会报错，只会让别的结论全部失真。证书、日志、定时任务、缓存过期，全都依赖它，时间不对的时候，后面查什么都可能得出相反的结论。对时这件事值得先做完再查别的，它花的时间比换一台机器少得多。
申请创业报道，分享创业好点子。点击此处，共同探讨创业新机遇！
