时间同步与双系统 UTC 陷阱

核验于 2026-10-292 分钟阅读

修掉走慢的时钟或固定差 8 小时的问题、理解 w32tm，并让双系统不再改你的时区。

测试环境Pro (26H2) / Server · 版本号 26300.9457 / 26100.33650 · x64

版本号: 26300.9457 / 26100.33650
版本: Pro (26H2) / Server
架构: x64
支持: 文档（E1）
证据: E1官方文档
核验日期: 2026-10-29
页面类型: 排障

一句话结论

两种不同的故障看起来一样：

现象	原因
时钟慢慢走偏（每周几分钟）	时间同步坏了——服务器错、123 端口被拦
每次开机都正好差 N 小时	双系统对 RTC 的写法不同（Windows 用本地时间，Linux 用 UTC）
时间对、时区错	时区设置，不是同步
唤醒后时间跳变	恢复时才同步，而不是之前

正好差整数小时的情况根本不是同步问题，跑 w32tm /resync 修不了。

诊断

w32tm /query /status
w32tm /query /configuration | Select-String 'Type|NtpServer|Enabled'
w32tm /stripchart /computer:time.windows.com /samples:3 /dataonly
Get-TimeZone | Select-Object Id,DisplayName,BaseUtcOffset

读 w32tm /query /status：

Source——time.windows.com（公网）、你的 DC（域），或 Local CMOS Clock（没在同步）。
Last Successful Sync Time——几天前说明同步在失败。
Poll Interval——重试间隔。

Source: Local CMOS Clock 表示机器在相信自己那颗硬件时钟，于是在漂移。

修同步

w32tm /config /manualpeerlist:"time.windows.com,0x9" /syncfromflags:manual /update
Restart-Service w32time
w32tm /resync /force
w32tm /query /status

还是失败，就确认 UDP 123 出站没被拦（公司网络常拦），并换一个服务器。

域内成员不要指向公网服务器——它们必须跟随域层级（/syncfromflags:domhier）。

双系统 UTC 陷阱

Windows 默认按本地时间读写硬件时钟；Linux 按 UTC。一个系统写了 RTC，另一个读出来，时间就正好差你的 UTC 偏移——中国 8 小时、纽约 5 小时，而且夏令时会变。

两种修法：

A. 告诉 Windows RTC 是 UTC（双系统推荐）：

reg add "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation" /v RealTimeIsUniversal /t REG_DWORD /d 1 /f

然后重启。Windows 从此与 Linux 一致。

B. 让 Linux 使用本地时间（等价，但不够干净）：

timedatectl set-local-rtc 1 --adjust-system-clock

选一个。两个都做会把偏移重新造出来。

时区与时间

Set-TimeZone -Id "China Standard Time"
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\tzautoupdate' -Name Start -ErrorAction SilentlyContinue

“自动设置时区”对会移动的笔记本有用，对连 VPN 的台式机有害——地理位置查询会把你放到错误的国家。

为什么这事重要

TLS 证书校验在时钟错误时失败——每个网站都提示“连接不是私密连接”。
Kerberos 在偏移超过 5 分钟时拒绝认证（域机器）。
文件时间戳在备份与日志里变得误导。
2FA/TOTP 验证码被拒。

实验室边界

E1。时间服务行为有微软文档依据。实验室虚拟机从 Proxmox 宿主时钟同步，因此未复现漂移或双系统偏移。