VPS 时间不准怎么排查：双源实测拆开上游 NTP 源

VPS 时间不准怎么排查，按本机服务、时区偏差、上游 NTP 源可达性三层定位，换 server 行前先验证这个源从本机出口连不连得上。证书提示「尚未生效」、定时任务莫名不跑、日志时间线前后对不上，多数人第一反应却是重装 chrony、换个公共 NTP 地址。有台跑了一年多的业务机改了三四轮 server 行，时间还是不同步，问题不在本机。这篇配一组可复现的双源数据，把第三层单独拎出来讲。

口径：表里的数是从中国大陆两个不同运营商出口到公共 NTP 主机的 ICMP 往返延迟，采样 2026-11-12 09:15:22，命令 ping -c 20 -i 0.2 -W 2 <目标>，路由 tracepath -n -m 20 <ip>。cn-probe-1 是 103.39.226.31，中国广东电信 AS4816 单线；cn-probe-2 是 8.140.30.240，中国北京阿里云 AS37963 BGP 多线，两台都在中国大陆，全程只读。口径上先钉一句：ICMP 往返延迟不等于 NTP 授时精度，也不等于在售机器业务延迟；ping 通不代表 UDP 123 可达，ping 不通也不代表 NTP 授时服务连不上，ICMP 只作路径可达性旁证。

时间不准分三层，换个出口测同一个 NTP 源会得到相反答案

时间不准看着是一个症状，其实分三层：本机同步服务在不在、时区与时钟偏差有没有搞混、上游 NTP 源从这台机器的出口连不连得上。前两层教程讲得多，第三层很少验证，却是换了 server 行还不同步的根因。判断时间不准卡在哪层，先对上号再动手。

表 1 是核心：五台公共 NTP 主机、两台源、每台 20 个包，收/发、丢包、min/avg/max/mdev 全摊开，全丢包行用破折号留空。五个目标都是公共 NTP 主机（阿里云公共 NTP、NTP Pool 池域名、Google Public NTP、中国科学院国家授时中心），这里只当被测目标，清单以各家官方说明为准，不引用厂商文档里的延迟数字。

表 1　五台公共 NTP 主机 × 两源 ICMP 对照（2026-11-12 09:15:22，ping -c 20 -i 0.2 -W 2）

横着读有四个发现。同一家服务商两个域名，两源快慢关系反过来：ntp.aliyun.com 北京 11.503 比广东 40.171 快，ntp1.aliyun.com 反倒是广东 30.186 比北京 33.638 快，两域名解析 IP 也不同（广东 118.31.40.99、北京 118.31.3.89）。cn.pool.ntp.org 本次两源解析到不同实例、结果不同：广东 139.199.215.251、avg 7.148、0% 丢包，北京 108.59.2.24、20 发 0 收。time.google.com 两源各 20 发 0 收，两个源均未收到 ICMP 回应。ntp.ntsc.ac.cn 两源都通，北京 17.250 比广东 31.456 快，mdev 0.145 与 1.466。所以时间不准这件事，换个出口测同一个源，答案可能反过来，从哪测得写进结论里；对时间不准做分层，得有这张表垫着。

症状对根因：一张判定表

把报错词和该查哪层对上号，时间不准就不用从头翻命令。

表 2　时间不准的症状 → 根因判定

时间不准里，双源结果不一致这行把问题从本机配错，指向这个出口到那个源不通，修法完全不同。

时间不准会坏什么事：为什么「差几秒」比「差 8 小时」更危险

差整数小时一眼能看出来，反倒好办。日志时间线平移、证书校验提示还没生效或已过期、定时任务踩空、分布式锁和 Token 过期判断提前或延后，才是时间不准真正咬人的地方。差几秒尤其阴：证书按秒校验，机器快出一点，刚签的证书在它眼里就是没生效；各偏各的机器日志一合并顺序就乱。所以时间不准别只盯现在几点，要盯和 UTC 差多少、稳不稳。

第一层：本机时间同步服务有没有在跑

时间不准先查最里面这层。一条 timedatectl 够用，看 Time zone、System clock synchronized、NTP service 三个字段，含义见 systemd timedatectl 手册。一台机器只留一个同步服务，chrony、systemd-timesyncd、ntpd 选一个，用 systemctl is-active 确认。见过 chrony 和 ntpd 一起起，两边抢着写时钟，时间不准反而更没规律，停掉一个就顺了。

timedatectl
systemctl is-active chronyd systemd-timesyncd ntp

要把时间不准这么来回换着测，手上得有台随时能复跑的机器，按线路归过历史读数的评测页 可以对着挑。

timedatectl 输出怎么读

示意输出，字段对得上就行：

     Time zone: Asia/Shanghai (CST, +0800)
 System clock synchronized: yes
               NTP service: active

System clock synchronized: no 配 NTP service: inactive 是服务没起；active 却仍 no，多半上游没选上，往下走第三层。

第二层：时区 vs 时钟偏差，别把「差 8 小时」当同步失败

NTP 同步的是 UTC 绝对时刻，不是本地显示规则。date -u 正确、date 差整数小时，是时区没设，不是同步失败；东八区按 UTC 加一个整时区偏移显示，跟 chrony 无关。混在一起，时间不准就会查成同步坏了，白折腾。

本轮两台探测源机器的系统信息能当旁证：两台 date_local 都是 +0800 CST，www.tkvps.com 的 HTTP Date 是 Thu, 12 Nov 2026 01:15:26 GMT 和 Thu, 12 Nov 2026 01:17:20 GMT。同一时刻一个写成东八区本地、一个写成 GMT，差的是显示规则。这是探测源机器的只读信息，不是商家产品标称。

有台机器 date 比同事慢了整整一个时区的小时数，运维把 chrony 卸了装、装了卸，server 行换了三四个地址，date -u 一直是对的。这种我一般先敲 date -u 再敲 date，两个一对，时间不准当场就分开了。查时间不准先这两条。

timedatectl set-timezone 与 hwclock

改时区不写时钟，只改显示；hwclock 管主板硬件时钟，和系统时钟两码事。校准后再在合适时机 hwclock -w 写回，免得重启又偏。

timedatectl set-timezone Asia/Shanghai
hwclock -w

改完 date -u 复核 UTC 没动，就说明没碰时钟。

第三层：你配的上游 NTP 源，从这台机器的出口到底连不连得上

教程写加一行 server ntp.aliyun.com iburst 就收尾，默认这个域名一定连得上。时间不准真正的坑常在这：server 行规规矩矩，源却从这台机器出口不回包。表 3 是表 1 按目标重排，数字来自同一批 2026-11-12 探测，不是另测一次，看两源快慢和抖动。

表 3　逐目标两源 avg 与 mdev 对照（数字均来自表 1）

同一家服务商两个域名，两源结论相反

ntp.aliyun.com 北京 11.503 对广东 40.171，ntp1.aliyun.com 广东 30.186 对北京 33.638，快慢调了个个儿。同一批探测、同一条命令，只换域名排名就反，只能按本次两源口径陈述，推不出哪个源对谁都最快。

tracepath -n 路径旁证更直观：到 203.107.6.88，广东电信 15 跳到达、末跳 40.266ms reached，中间 202.97.43.74（173.526ms）、218.30.53.47（157.607ms）；北京阿里云 8 跳到达、末跳 12.219ms reached，前几跳 11.247.233.54（1.722ms）、45.112.219.17（12.690ms）、8.140.30.240（13.135ms）。本次两源到同一 IP 的跳数分别为 15 与 8，仅此而已，不往哪边网络更好上推。

高延迟、抖动和丢包的源怎么用

mdev 比 avg 更说明稳不稳：ntp.aliyun.com 广东 1.984、北京 0.153，ntp.ntsc.ac.cn 广东 1.466、北京 0.145，差一个量级。cn.pool.ntp.org 广东解析到 139.199.215.251 时 avg 7.148、0% 丢包，北京解析到 108.59.2.24 却 20 发 0 收，只能写本次两源解析到不同实例、结果不同，不下别的判断。池域名落到哪台实例不固定，只吊在这一个池上，时间不准就容易时好时坏。time.google.com 两源各 20 发 0 收，两个源均未收到 ICMP 回应，这是本次两源的结果，不反推 NTP 服务出了什么问题。

chronyc sources 全 ^? / Reach 0 时，按三层查（解析 → 路径 → 端口）

时间不准查到 chronyc sources -v 满屏 ^?、Reach 一直 0，是这个源一次没选上。逐列读法见 chrony 官方文档，这里只讲顺序。

chronyc sources -v
chronyc tracking
chronyc activity

按三层走：域名解析对没有，属 DNS 解析慢怎么排查；解析没问题看路径；最后才是 UDP 123 出站通不通，归 VPS 端口不通怎么排查，出站策略、云安全组不展开。服务起不来有时是机器自己喘不上气，负载高怎么排查、磁盘空间不足排查、延迟怎么测才准 这几篇讲过，都不重复。时间不准查到 ^? 时最容易在这一层反复改配置。

有台机器 chronyc sources 一直 ^?，server 行从 ntp.aliyun.com 换成 ntp1.aliyun.com、又加一串 ntp.cloud.aliyuncs.com，Reach 还是 0。对上游验证才看清：这台机器出口到那个源根本不回 ICMP 包，换哪个域名都白搭。时间不准卡在第三层时改配置是原地打转。区分源不可达和源太慢太抖，看双源 avg 和 mdev：两源都大延迟、mdev 高是抖动，可留做冗余不宜当主源；一个出口 20 发 0 收、另一个通，回表 3 分流。

同步状态正常但偏差一直追不上：makestep 与硬件时钟

System clock synchronized: yes、源也选上了，偏差却慢慢追，是另一类时间不准。chrony 默认靠 slew 一点点拨；makestep 1.0 3 只在前 3 次调整里、偏差超过 1.0 秒允许跳一步，之后回到慢慢追。头几次没跳过来，后面就别指望它自己跳。

chronyc makestep
hwclock -w

chronyc makestep 强制跳有业务风险：时间回跳，定时任务可能跳过一轮或重复跑，日志顺序、Token 过期判断都受影响，生产机挑低峰或让它慢慢追。改完 chronyc tracking 看 Last offset、Frequency 确认偏差在收窄，再决定要不要 hwclock -w 写回。

VPS 时间不准怎么排查：一套能抄的顺序（7 步 + 可复现命令）

把三层收成能照着敲的线，时间不准按序走，每步有判据：

1. timedatectl，看 System clock synchronized 与 NTP service，定服务在不在。
2. date -u 和 date 各跑一次，UTC 对、本地差整数小时就停这层，去设时区。
3. systemctl is-active chronyd systemd-timesyncd ntp，确认只有一个同步服务。
4. chronyc sources -v，看有没有 ^*、Reach 是不是 0。
5. 对上游源做可达性验证：换第二个源复跑同一目标，对照表 1 的收/发、avg、mdev，分清本机配置还是出口链路。
6. chronyc tracking，看 Last offset、Frequency、有没有在同步。
7. 改 chrony.conf 的 server 行并复测：换源前后各留一份 chronyc sources -v，确认 Reach 从 0 起来。

第 5 步是这条线和多数教程分岔处，也是时间不准反复修不好的常见原因：不先验证源可达，改 server 行就是碰运气。

公共 NTP 源怎么选：把双源实测结果翻译成配置建议

只从本次两源实测看，给时间不准挑源分三种配。两源都稳、mdev 小的，ntp.ntsc.ac.cn 广东 31.456、北京 17.250，mdev 1.466 与 0.145；ntp.aliyun.com 两源 0% 丢包，广东 40.171、北京 11.503，适合当主源。方向反转的 ntp1.aliyun.com 按自己出口实测挑。cn.pool.ntp.org 是 NTP Pool 项目 池域名，本次两源解析到不同实例、结果不同，适合做冗余、不宜当单一上游。两源均未收到 ICMP 回应的 time.google.com，这两个出口拿它当主源没依据，留着观察。

配置别只写一行 server，server / pool 多给两三个来源、都带 iburst，某条不回包还有别的顶上。本轮 cn-probe-2 的 /etc/chrony.conf 配了 server ntp.cloud.aliyuncs.com、ntp.aliyun.com、ntp1.aliyun.com、ntp1.cloud.aliyuncs.com、ntp10.cloud.aliyuncs.com 等共 21 行 server，均带 minpoll 4 maxpoll 10 iburst，/etc/ntp.conf 另有 server 127.127.1.0 与同样一组上游；cn-probe-1 上两个配置文件都未取得，只能写该源未取得配置文件，不能反推没跑同步服务。这是两台探测源机器自身的只读配置，不是商家产品标称。

挑商家时，能不能自助改 NTP 上游、出口干不干净，直接影响时间不准好不好修；按机房和网络可达性归过的商家清单 可以对着筛。

FAQ 与数据说明：六个常见问题和这份数据的边界

问：ping 通，时间不准还是没修好，问题在哪？ ping 通只说明 ICMP 有回应，NTP 走 UDP 123，两码事。按三层往下查，多半卡在端口出站或源没选上。

问：为什么我测和别人测的时间不准结果不一样？ 同一批公共源，换出口结论可能反过来，表 1 里两个阿里云域名快慢调了个个儿就是例子。连探测源写进结论才对得上。

问：容器里时间不对，要在容器里装 chrony 吗？ 容器共享宿主机内核时钟，改的是宿主机那份时刻，容器里再装同步服务多半白折腾。时间不准先回宿主机查。

问：改完 server 行立刻测，怎么还是不通？ chrony 选源要等几个轮询周期，iburst 只加快头几次。留一份 chronyc sources -v 过一阵再看 Reach。

问：查时间不准，只有两个源够不够下结论？ 手上就这两个源，判断不了更远的事，照实写。结论只覆盖这两个出口，不往更多出口、更多地区上推。

问：时间往回跳会怎样？ 定时任务可能跳过一轮或重复跑，日志顺序、Token 过期判断跟着乱。生产机用 chronyc makestep 强制跳要挑低峰，或让 slew 慢慢追。

数据说明：表 1、表 3 的数字都来自 2026-11-12 09:15:22 这一批，命令 ping -c 20 -i 0.2 -W 2，路由 tracepath -n -m 20，两台源 cn-probe-1（103.39.226.31，中国广东电信 AS4816 单线）与 cn-probe-2（8.140.30.240，中国北京阿里云 AS37963 BGP 多线）都在中国大陆，可逐条回溯。全丢包行一律写两个源均未收到 ICMP 回应或该源未收到 ICMP 回应，不补数、不估算。再说明一次：ICMP 往返延迟不等于 NTP 授时精度，也不等于在售机器业务延迟；ping 通不代表 UDP 123 可达，ping 不通也不代表 NTP 授时服务连不上，ICMP 只是路径可达性的旁证。

VPS 时间不准怎么排查，说到底就一句：先分清是本机服务、时区显示，还是上游源从这台机器的出口连不上，再动手改配置。前两层照教程走，第三层得拿双源数据验；换了出口结论会反过来，是这份对照表最该记住的一格。把源、时间、命令写在结论旁边，时间不准才修得明白、复现得了。

真到了排障无果、想换台能自助配 NTP 的机器那一步，优惠券与在售套餐 可以按预算对着挑。