Windows Server 时间不同步：时间源、域层级与校验
本文适用于 Windows Server 2022、2025。时间故障需要先分清“显示在哪个时区”与“系统时钟是否准确”。两台服务器显示相差数小时，可能只是时区不同；同一时区下持续偏差数秒，则更值得检查时间源和同步状态。修改之前应保存状态，避免手动调时打乱故障证据。
先记录状态，不急于设定时间
# 服务器：管理员终端，只读查询
Get-Date
Get-TimeZone
w32tm /query /status /verbose
w32tm /query /source
w32tm /query /configuration
重点关注当前来源、上次成功同步时间、相关错误以及配置从本地还是策略获得。某个来源名称显示出来，不代表最近已经成功同步；需要结合时间和状态字段判断。
若显示本地时钟或虚拟化相关来源，应进一步确认它是预期设计还是外部同步失效后的结果。不要仅根据来源字符串套用修复命令。查询方式和参数见 Windows 时间服务工具与设置。
域成员应遵循既定层级
加入 Active Directory 域的成员通常通过域层级获取时间，配置中常见 NT5DS 模式。域控制器也有对应的时间同步层级，林根域中承担 PDC 模拟器角色的服务器通常是规划外部可靠时间源的关键位置。
因此，不能把独立服务器的手动 NTP 配置批量套用到每台域成员或域控制器。如果所有成员同时出现偏差，应先检查上游域时间链路及策略，而不是逐台设置公共时间服务器。域结构与时间源选择的原理见 Windows 时间服务工作方式。
受组策略管理的配置可能在下一次策略刷新时被覆盖。排障记录应明确来源与负责人，持久修复应落到实际管理位置。对域控制器进行时间源调整应纳入域运维流程，避免影响身份认证。
独立服务器也要核查网络和来源
独立服务器可以按组织设计使用指定的可信时间源。来源应实际可达、稳定并适合当前网络，不能把教程中的示例域名直接复制到生产配置中。
# 服务器：替换为实际允许访问的时间源，仅观察偏差
w32tm /stripchart /computer:time1.example.com /samples:5 /dataonly
观察结果可辅助判断与指定服务器的时间差，但一次查询成功不能完全证明 Windows 时间服务的同步路径正常。服务通信与诊断工具的具体网络行为可能不同，还应检查服务状态、防火墙、上游访问策略和事件日志。
NTP 常使用 UDP 123，TCP 端口测试成功与否不能证明它可用。虚拟机还要核查宿主机时间及集成时间同步机制，避免同时存在未经规划的多个来源。
修复应只针对已经确认的原因
如果只是时区显示不符合业务要求，调整时区即可，不需要伪造系统时间。如果配置来自错误策略，就修正策略；如果上游不可达，就先恢复网络或正确的时间源。不要把停用时间服务作为长期解决方案。
在来源和配置已经修正后，可根据维护方案执行 w32tm /resync 请求重新同步，但这不保证立即修正所有偏差。偏差较大时，服务还可能受到允许校正范围等设置约束。应阅读返回信息及日志，而不是重复执行或盲目放大校正限制。
较大的时间跳变会影响令牌有效期、计划任务、日志顺序和部分数据库行为。生产环境应评估业务影响并安排窗口，不要用手工拨钟掩盖持续漂移。
验证需要观察后续同步周期
修复后再次查询来源、状态和上次成功同步时间，并在一段时间后复查，确认偏差没有继续增长。把应用错误的时间与系统事件关联，验证登录、证书访问和定时任务恢复正常。
多台服务器应在同一时间基准下比较记录，故障工单中明确使用的时区或 UTC 偏移。需要为日志建立可靠留存时，可结合备份方案保存证据；证书访问异常则还应检查HTTPS 证书配置，不要把所有证书错误都归因于时间。