VPS 时间不准，看起来像小问题，实际很容易把排障方向带偏。
证书明明没过期，程序却报 TLS 校验失败；cron 任务“没按点执行”；日志顺序前后跳；JWT、Cookie、OAuth 登录突然失效；数据库写入的时间戳比真实时间差几个小时。很多时候，根因不是应用坏了，而是系统时间、时区或 NTP 同步出了问题。
这篇按排查顺序讲：先确认系统时间和时区，再看 NTP 是否启用，然后分别检查 systemd-timesyncd、chrony、网络连通性和业务侧影响。
先看当前时间状态：
timedatectl
重点看这几行：
Local time: ...
Universal time: ...
Time zone: ...
System clock synchronized: yes/no
NTP service: active/inactive
这里要区分两个问题：
- 时区不符合你的预期：例如系统使用 UTC，但你以为是 Asia/Shanghai。
- 系统时间本身不准：UTC 时间已经和真实时间差了几十秒、几分钟甚至几小时。
时区不一致不一定是故障。很多生产系统统一用 UTC，反而更清晰。真正危险的是系统时钟漂移，尤其是超过几分钟时。
如果你是在排查定时任务，可以同时看这篇：VPS 定时任务不执行怎么办：cron、crontab、systemd timer。
查看可用时区：
timedatectl list-timezones | grep Shanghai
设置为上海时区：
sudo timedatectl set-timezone Asia/Shanghai
如果你更习惯用 UTC：
sudo timedatectl set-timezone UTC
我更建议：服务器内部统一 UTC，面向用户的显示层再转换成本地时间。但如果你的团队、日志系统和维护窗口都按北京时间沟通，使用 Asia/Shanghai 也可以，关键是全链路一致。
不要把“时区改对了”当成“NTP 修好了”。改时区只影响显示和本地时间解释，不会解决系统时钟漂移。
开启 NTP：
sudo timedatectl set-ntp true
再看状态：
timedatectl status
如果看到：
System clock synchronized: yes
NTP service: active
说明系统层面已经认为时间同步正常。
如果是 no 或 inactive，继续查后面的服务。不同发行版默认用的时间同步组件不一样：
- Ubuntu / Debian 常见：
systemd-timesyncd - RHEL / Rocky / AlmaLinux 常见：
chronyd - 有些镜像会安装传统
ntp或ntpsec
不要同时启多个时间同步服务，容易互相冲突。
Debian / Ubuntu 上先看：
systemctl status systemd-timesyncd
如果没启动：
sudo systemctl enable --now systemd-timesyncd
查看同步详情：
timedatectl timesync-status
常见异常包括：
- 没有可用 NTP Server
- 网络无法访问 UDP 123
- DNS 解析失败
- 本机时间偏差太大，需要先手动校准一次
看日志：
journalctl -u systemd-timesyncd --since "2 hours ago"
如果日志里有 DNS 解析问题，可以参考：VPS DNS 解析失败怎么办。
很多服务器更适合用 chrony，尤其是虚拟化环境、时间可能跳变的 VPS。
安装：
sudo apt install chrony -y
或：
sudo dnf install chrony -y
启用：
sudo systemctl enable --now chrony
有些系统服务名是 chronyd：
sudo systemctl enable --now chronyd
查看同步源：
chronyc sources -v
查看追踪状态：
chronyc tracking
你要重点看：
- 是否有带
*的同步源 Last offset是否很大Leap status是否正常Stratum是否合理
如果所有源都是 ^?，通常表示 NTP 源不可达或没有响应。
NTP 默认使用 UDP 123。VPS 出站 UDP 被限制时，时间同步可能一直失败。
先确认 DNS 能解析：
getent hosts pool.ntp.org
再看防火墙规则：
sudo ufw status
sudo iptables -S
sudo nft list ruleset
大多数情况下，普通 VPS 不会拦出站 UDP 123。但某些云防火墙、安全组、企业网络策略或极简镜像里的防火墙规则可能会拦。
如果你用的是自建防火墙规则，先允许出站 UDP 123，再重启同步服务：
sudo systemctl restart systemd-timesyncd
sudo systemctl restart chrony
只需要重启你实际使用的那个服务。
如果系统时间差了很多，NTP 服务有时不会立刻平滑拉回。可以先手动校准，再交给 NTP 维持。
使用 chrony：
sudo chronyc makestep
然后看：
chronyc tracking
timedatectl
如果没有 chrony，也可以临时设置时间，但要谨慎：
sudo date -s "2026-05-24 10:00:00"
手动设置只适合临时救急。最终还是要让 NTP 服务持续同步，否则过几天又会漂。
时间同步不是“运维洁癖”，它会直接影响业务。
TLS 证书有明确的 Not Before / Not After 时间。如果 VPS 时间比真实时间早太多，可能认为证书“还没生效”；如果晚太多，可能认为证书“已经过期”。
证书续期和校验问题可以参考：VPS 上 Let’s Encrypt 证书续期失败怎么办。
cron、systemd timer、备份脚本、证书续期、报表任务都会依赖系统时间。时区错了，会让任务看起来“提前/延后”；时间漂移，会让任务行为更难判断。
JWT、OAuth、SAML、Cookie 过期时间都依赖服务器时间。时间差几分钟，就可能出现：
- 刚签发的 token 被认为还没生效
- 用户刚登录就过期
- 双因素认证验证码不匹配
- API 请求签名校验失败
日志时间不准，会让事故复盘变得很痛苦。尤其是多台 VPS、数据库、CDN、对象存储一起排查时，时间线错乱会直接误导判断。
如果你正在做故障复盘，先确保所有机器时间同步，再看日志链路。
如果你有多台机器，不要一台 UTC、一台 Asia/Shanghai、一台默认服务商时区。至少要统一下面几件事：
- 所有服务器启用 NTP
- 日志系统统一使用 UTC 或明确记录时区
- 应用层时间存储统一用 UTC
- 展示给用户时再按地区转换
- 监控告警和定时任务文档写清楚使用哪个时区
多机架构里，时间差会让数据库复制、缓存过期、队列延迟、分布式锁和审计日志都变得难排查。
遇到 VPS 时间不准，按这个顺序查：
timedatectl看时区、NTP 状态和同步状态。- 确认是时区问题，还是 UTC 时间本身漂移。
sudo timedatectl set-ntp true启用 NTP。- Debian / Ubuntu 查
systemd-timesyncd。 - RHEL / Rocky / AlmaLinux 查
chrony/chronyd。 - 用
chronyc sources -v和chronyc tracking看同步源。 - 检查 DNS 和 UDP 123 出站是否可用。
- 时间偏差太大时，用
chronyc makestep先校准。 - 校验 HTTPS、cron、日志、JWT、数据库时间戳是否恢复正常。
- 多台机器统一时区和 NTP 策略。
VPS 时间不准，表面是 date 显示不对，实际会牵连证书、定时任务、登录状态、API 签名、日志审计和数据库时间戳。
先用 timedatectl 分清时区和时间漂移，再确认 NTP 服务是否真的在同步。单机排查时看 systemd-timesyncd 或 chrony，多机环境则要统一时间策略。时间线对了，后面的故障排查才不会越查越乱。