周传炽如果你在公司内部局域网里维护过一批 Windows 机器，一定体会过这种场景：明明所有机器都连着同一个网络，但登录日志、数据库事务、邮件告警里的时间却各自为政。更难受的是，某天证书突然校验失败，排查了一圈发现根本不是证书过期，而是机器时间偏了十几分钟。这种问题一旦出现，往往不是你敲两下 date 命令就能解决的，尤其在纯内网环境里，没有互联网时间服务器可用，Windows 自带的时间同步机制又不会自动帮你找到局域网里的“标准钟”。
这篇文章就从实际配置的角度，把“局域网内 Windows 时间同步”这件事拆开讲清楚：怎么选时间源、怎么把一台 Windows 变成 NTP 服务器、其他 Windows 机器怎么指向它、以及同步完之后怎么验证、怎么排错。适合所有需要在局域网、隔离网、虚拟化环境里维护一批 Windows 服务器的运维同学，也包括实验室里管着十几台设备的兄弟。
1. 为什么局域网里也要单独维护一套“标准时间”？
先说一个反直觉的事实：大多数局域网里的 Windows 机器，时间从来都不是准的，只是偏差没大到让你注意到。每台电脑的硬件时钟（CMOS）本身就存在漂移，一天差个几百毫秒很正常。如果某台机器长期不关机、不联网、不主动对时，累积几天甚至几周，偏出几分钟完全可能。单台机器偏几分钟没什么大不了，可一旦多台机器之间互相有依赖，问题就来了。
1.1 时间不同步的典型代价：证书、日志、数据库和 Kerberos
最常见的受影响场景是 HTTPS 证书校验。内网里很多系统用的是自签证书或内部 CA 签发的证书，客户端在验证服务端证书时，会先检查“当前时间是否在证书有效期内”。如果客户端机器时间比真实时间慢了两天，而服务端证书恰好刚签发，客户端就会认为证书“尚未生效”，直接拒绝连接。这类故障现场的表现和证书真过期一模一样，很多人会第一时间去翻 CA 配置，却忽略了源头的时钟问题。
第二个受罪的是日志系统。当运维排查故障时，要把各个服务器上的应用日志、系统日志、数据库慢查询日志按时间线串起来。如果每台机器的时间基准不一致，日志会呈现出一种“未卜先知”或“时间倒流”的效果，排查链路直接断掉。数据库主从复制、消息队列、定时任务调度，这些系统对时间一致性更敏感，哪怕偏差几百毫秒，也可能导致主键冲突、重复执行、数据覆盖等让人头疼的现象。
第三个重灾区是 Windows 域环境的 Kerberos 认证。域内成员和域控制器之间的时间差如果超过默认容差（通常是 5 分钟），Kerberos 票据就会被判定为无效，用户会突然无法访问共享目录、无法登录域账号。这种情况在大型企业里非常经典：网络通、账号没问题、DNS 也正常，但就是鉴权失败，最后查出来是某台域控的硬件时钟漂移了。
1.2 NTP 机制与时间层级：先想清楚谁是源头
理解了“为什么”，再来看“怎么办”。Windows 时间同步依赖的基础协议是 NTP（Network Time Protocol），默认走 UDP 123 端口。NTP 的核心思路不是“把本机时间直接改成服务器时间”，而是通过连续多次报文往返，估算出网络延迟和时钟偏移，再平滑地调整本机时钟。这样的好处是避免一次大步跳变给应用带来冲击，也是 NTP 能保持较高精度的原因。
NTP 用层数（stratum）来标记时间源的“权威程度”。Stratum 0 是原子钟、GPS 这类物理授时设备；Stratum 1 是直接连接 Stratum 0 的服务器；Stratum 2 是向 Stratum 1 同步的服务器，以此类推。层数越小越接近权威时间源，但并不意味着层数为 3 就不准。一个典型的局域网架构是这样的：内网主时间源可以是 Stratum 2 或 Stratum 3，它向上连接互联网公共 NTP 服务器或上级单位的授时系统；其他 Windows 机器作为客户端，都指向这台内网主时间源。没有外网的隔离环境里，主源也可以退化为“本地权威源”，这时重点已经不是绝对时间准不准，而是整个网络内部必须一致。
1.3 内网时间同步的常见拓扑
实操中常见的部署方式是星型：一台服务器当 NTP Server，其余所有 Windows 客户端都指向它。这种结构简单、容易排查，不需要在每台机器上做复杂的故障转移。稍微讲究一点的公司会部署两台 NTP Server，优先级一主一备，客户端配置两个源地址。我这里想说的是，除非你已经有成熟的运维体系，否则初期别搞太复杂，一台稳定运行、能开机自启、硬件时钟相对可靠的主源，加上所有客户端统一指向它