凌晨两点，某台 VPS 的日志比实际时间晚 47 秒，证书校验、订单回调和定时任务挤进同一窗口。重启未必治本，因为漂移可能来自宿主机晶振、KVM 计时器与客机校时策略，而非客机 NTP 故障。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：cliproxy（海外服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
一、漂移如何从宿主机传到客机
最底层是硬件振荡器，决定走时快慢；宿主机通过 RTC、PTP 或 NTP 校准系统时钟。KVM 客机由虚拟化层把宿主机时间基准、虚拟 CPU 计时器和中断机制交给客机内核，并非独立获得绝对时间。
x86 客机的KVM 时钟源常见 TSC、kvm-clock。若 TSC 具备 invariant 特性，且各虚拟 CPU 读取计数器，读数应一致；若切换 CPU 时倒退，或迁移虚拟机后偏移突变，就可能时间跳变。若偏差持续累积，则多与宿主机频率不准、授时源失锁有关，客机只会追随错误基准。
chrony 校时会估计网络时延和频率误差，平时 slew 缓慢调频，仅在启动或策略允许时 step 跳变。因此，客机 chrony 也无法抵消宿主机走快或走慢；时间跳变更不该靠频繁 makestep 掩盖。
二、先测量偏移，再决定修哪一层
宿主机与客机同步采样，连续观察 24 至 72 小时并与同一授时源比较。一次 date 对比只能发现跳变，不能证明长期稳定。客机用 chronyc tracking、sources -v 核对偏移、层级、闰秒状态与 reach，再以 timedatectl show 确认同步状态。
读取 /sys/devices/system/clocksource/clocksource0/current_clocksource，并用 dmesg 查 TSC、clocksource、watchdog 线索。偏差线性增大，先查宿主机 chrony、PTP 与振荡器；偶发前后跳，再查 TSC 一致性、vCPU 迁移、暂停恢复和宿主机校时动作。
配置上，TSC 一致性应由平台保证，绝对时间由可靠授时源校准。若有内部 NTP 或 PTP，客机优先使用；否则配置多个低时延上游并保持 reach。业务中不要频繁 makestep，也别用 uptime 或单调时钟判断墙钟，它们会掩盖漂移。ServLlama 可留存多时段采样与 chrony 指标，还原偏差速率和跳变时刻。
剩余原理：KVM 时钟源与 chrony 校时
进一步看 KVM 的授时链路：虚拟机最终依赖宿主机提供的参考时间，常见KVM 时钟源包括 KVM clock、TSC、HPET 与 ACPI PM。Linux 通常优先选择稳定且读取成本较低的 TSC 或 KVM clock。TSC 是递增计数器，多个 vCPU 的读数必须保持TSC 一致性，其频率也须稳定；否则纳秒值换算错误，就会形成持续的系统时钟漂移。
chrony 校时先测量本地时钟相对 NTP 源的 offset，再用 slew 渐进修正频率；偏差超过阈值且符合策略时，才执行 step 直接改时。它能纠正调度造成的小幅误差，却无法修复失真或跳变的硬件源。若上游同步良好、本地频率稳定，长期 Residual freq 应接近零，offset 不应单向累积；若偏差随运行时间线性增大，通常更像本地振荡频率不匹配。排查应按 clocksource、可用上游、offset 和频率残差逐层进行。
容易踩的坑包括：防火墙阻断 UDP 123；只配置 DNS 却没有真正可达的 NTP 源；chronyd 与 systemd-timesyncd 同时运行而争抢服务；多网卡或策略路由下校时流量走错出口；快照恢复后 RTC、开机时间与内核基准不一致；迁移到另一宿主机后仍沿用旧延迟判断。还有人把 rtcsync 当成系统时钟同步开关，但它只负责周期性回写 RTC，不能替代 NTP。
时钟同步验证与最终检查清单
先运行 chronyc -n tracking，确认 Stratum、Reference ID、Leap status 正常，并观察 Last offset、RMS offset、Frequency 与 Residual freq 是否收敛。其中 Frequency 表示本地时钟的估计频率误差，Residual freq 是扣除该误差后的残差，持续异常通常比单次 offset 更值得警惕。再用 chronyc -n sourcestats 确认选中源可用，并配合 timedatectl show -p NTPSynchronized -p NTP -p TimeUSec 核对同步标志、服务与系统时间。偏差过大时执行 chronyc makestep 前，应先评估时间戳兼容风险。
时钟源方面，读取 cat /sys/devices/system/clocksource/clocksource0/current_clocksource 和同目录的 available_clocksource，再查看 dmesg | grep -Ei 'tsc|clocksource|timekeeping'。重点排查 TSC unstable、TSC ADJUST、频繁切换时钟源或 HPET fallback，并确认 CPU 标志包含 constant_tsc 与 nonstop_tsc。多 vCPU 环境应在不同核并行读取单调时钟，检查结果是否一致；若宿主机正在调整 TSC 基准，应先处理宿主层同步与迁移策略，而不是反复校准 guest。
最终可执行检查清单：①确认 chronyd 正常运行且无端口冲突；②至少配置三个不同网络的上游源；③验证 UDP 123 可以出站，并用 chronyc activity 确认存在响应；④连续记录十分钟，确认 offset 与 Residual freq 稳定；⑤核查 TSC 日志和多 vCPU 一致性；⑥在重启及快照恢复后重新验证；⑦保存检查结果，并为持续漂移建立告警，而不是依赖一次手动改时。
归根结底，只有把“时钟源是否可靠、时间换算是否正确、校时是否真正生效”逐层验证，才能准确判断问题位于 KVM、TSC、宿主机还是客户端配置，并避免用反复重启服务掩盖根因。
喜欢 
顶
难过
囧
围观
无聊
