简介局域网时间同步工具提供了服务器端与客户端的一体化方案面向需要在小型局域网内统一设备时钟的IT运维人员或开发者。该工具采用VC实现通过客户端向指定服务器请求时间并校准本地时钟支持周期性同步与错误处理适合标准NTP不适用或需要定制化同步逻辑的场景。压缩包共55个文件约6.69MB包含Visual C工程源码cpp、h、dsp、dsw、可直接运行的exe程序、资源文件rc、ico、bmp及编译调试辅助文件obj、pch、pdb、bsc等方便用户查阅实现细节或直接部署。资源中另附ReadMe文档配合客户端与服务器端程序可快速搭建一对一时间同步环境。已有3200余人学习下载对于需要轻量级、可控性强的局域网时间同步方案的开发者而言具备明确的参考和复用价值。1. 局域网时间同步服务器和客户端时间对不上排障先从时钟开始做运维最难受的不是服务宕机而是服务看着都正常日志时间对不上。有次某公司一台数据库主库延迟报警我追查了一上午最后发现主库和备库的系统时间差了将近三分钟告警时间线完全对不上。局域网时间同步就是这么个不起眼却绕不过去的环节。服务器之间要做日志关联、证书有效期校验、定时任务批量执行只要各台机器的时间来源不统一偏差迟早会被放大成事故。这篇我按生产环境实际部署的顺序来写先讲方案选型再落服务器端、客户端的安装与配置最后把容易翻车的点集中讲完。新手照着命令能搭通一套熟手也能拿走参数取舍上的几个使用习惯。2. 时间同步方案怎么选chrony、ntpd 和 w32tm 各管一段局域网时间同步的核心是 NTP 协议它把时间从上游源一层层下发靠 UDP 123 端口通信。协议本身不复杂复杂的是操作系统里往往同时存在多种时间同步实现选错或者重复启用才是大多数故障的起点。先对主流实现做一次横向对比再讲拓扑怎么规划。2.1 常见的 NTP 实现与适用边界实现常见环境定位部署优先度chrony新版 Linux 系统客户端 服务端一体新装首选ntpd旧版 Linux 系统经典 NTP 守护进程存量系统维护systemd-timesyncdsystemd 发行版轻量 SNTP 客户端单机够用不能当服务端w32tmWindows 系统系统自带时间服务Windows 客户端chrony 是近些年多数主流发行版的新默认由 chronyd 守护进程和 chronyc 查询客户端两部分组成。相比 ntpd它对网络抖动适应性更好启动后能在几轮内快速收敛虚拟机场景下的漂移处理也更强。选型上我的习惯是只要是能装 chrony 的 Linux新部署就不要再用旧 ntpd老系统如果 ntpd 跑得好好的不强行迁移但要确认它指向的内网源是对的。systemd-timesyncd 是 systemd 自带的轻量时间同步组件只做 SNTP 客户端不监听 123 端口对外服务。个人办公机器上够用一旦需要给内网其他设备授时就必须换成 chrony 这类完整实现。最容易踩的坑是系统装了 chrony 却没有停掉 timesyncd两个服务抢同一个端口后面排错会专门讲。Windows 上对应的实现是 w32tm从比较老的 Windows 版本一直沿用到现在。很多 Windows 管理员习惯性地把它禁用其实 w32tm 完全可以做客户端与服务端只是需要显式配置时间源。域环境下时间源由组策略统一下发工作组环境下手动指定内网 NTP 服务器即可。2.2 局域网时间同步的两类拓扑最常用的拓扑是单主源一台内网服务器作为唯一时间源它同步公网 NTP内网所有 Linux、Windows 和网络设备都指向它。适用场景是一个机柜或者一个扁平网段机器几十台这种结构排查最方便只要盯住这一台服务器的同步状态就够了。机器多或者跨楼栋、跨安全域时推荐两级架构一级时间源同步公网二级时间源只同步一级客户端全部指向二级。好处是授权边界清晰一级只需要对几个二级源放行 UDP 123二级源再面对各自的客户端源越少越容易追问题。NTP 的层级用 stratum 表示层数越小越权威公网源一般 stratum 2内网一级设成 stratUm 3 的情况比较多配置时我们并不需要精确定义chrony 会自动继承上游的层级并加一。拓扑定下来之后有个原则值得养成习惯客户端不要直连公网源统一指向内网服务器。直连公网源表面上省了一台机器的配置实际上时间源分散哪台机器外网出口紧张、哪台防火墙拦了 UDP 123根本查不完。用一层内网时间源收敛访问面后续巡检、换源、加机器都在一个点上操作。3. 服务器端部署用 chrony 把内网 NTP 时间源搭起来内网时间源服务器我一般放在核心网段里的一台 Linux 机器上要求常年开机、能与公网 NTP 源通信。硬件服务器比虚拟机更省心但多数场景内网虚拟机也够用关键是别把时间源服务器也做成随手快照还原的测试机。下面以一台 IP 为 192.168.31.1 的 Linux 为例完整走一遍安装和配置。3.1 安装 chrony两个包管理器一条命令Debian 系发行版执行apt update apt install chrony -y systemctl enable --now chronydRPM 系发行版执行dnf install chrony -y systemctl enable --now chronyd老版本系统上没有 dnf 就用 yum install chrony -y效果一样。chrony 安装包同时提供 chronyd 守护进程和 chronyc 客户端工具装完就已经是开机自启状态。systemctl enable --now 表示设置自启并立即启动如果安装时提示服务已启动这条命令只是保证重启后依然拉起。Debian 系这一步容易先失败因为 systemd-timesyncd 还占着 123 端口建议先跳到 5.2 处理完再回来。装完用 systemctl status chronyd 看一眼进程状态Active 行显示 active (running) 再继续往下配。如果 Status 是 failed说明端口冲突或者配置文件有语法问题先解决再走下一步不然后面全白费。3.2 修改 chrony.conf上游源、网段授权和本地时钟兜底装好后 chrony 自带一份默认配置直接能跑但要给内网授时需要改三个点上游时间源、允许同步的网段、外网失联时的兜底策略。下面是我在一台时间源服务器上用的完整最小配置# /etc/chrony/chrony.conf # 上游公网时间源iburst 让启动后前四轮同步快速完成 pool cn.pool.ntp.org iburst # 允许内网网段访问本机时间服务按实际网段修改 allow 192.168.31.0/24 # 与外网断开时用本地时钟继续给内网提供服务层级设为 10 local stratum 10 # 偏差超过 1 秒且连续 3 个轮询周期执行步进校准 makestep 1 3 # 漂移文件chronyd 估算本地时钟速率时使用 driftfile /var/lib/chrony/driftpool 和 server 都是指定上游源区别在于 pool 后面跟域名时会把域名解析出的多个时间源都利用起来server 后面一般跟单台 IP。内网服务器指向上游时用 pool 比较稳因为公网源挂了还有别的候选源自动顶上。allow 是授权内网客户端来同步语法上可以直接写单个 IP也可以写网段。默认配置里 allow 是被注释掉的等于只能本机自我同步不加这一行内网客户端都拉不到时间。local stratum 10 是纯内网环境或者外网短暂失联时的保险没有外部源可用时chronyd 依然把自己作为 stratum 10 的源继续工作避免内网机器全部失去时间参照。这里要特别提醒stratum 10 是比公网源低很多层级的标记只是比没有强的兜底不能把兜底当成正经上游源来设计。makestep 1 3 是生产环境很关键的一行。NTP 默认是缓慢调整本地时钟速率来对齐时间如果偏差已经超过 1 秒靠微调要等很长时间才收敛makestep 1 3 表示偏差超过 1 秒且出现在前 3 个轮询周期内时直接步进校准。对刚装好的机器来说第一步就该跳变否则会出现同步正常但时间还是差了几十秒的错觉。改完配置重启服务systemctl restart chronyd重启后不要立刻看结果等一到两分钟让 chronyd 完成上游源的探测和首个轮询周期。3.3 开放 UDP 123 并启动服务NTP 走的是 UDP 123不是 TCP防火墙规则别放错协议。使用 firewalld 的发行版firewall-cmd --permanent --add-servicentp firewall-cmd --reload使用 ufw 的发行版ufw allow from 192.168.31.0/24 to any port 123 proto udpfirewalld 里 add-servicentp 对应自带的 ntp 服务定义展开之后就是 UDP 123 端口reload 之后立即生效。ufw 那条命令把源限制成内网网段比开放所有来源更收敛。如果机器有云平台安全组或者机房 iptables也要同步检查 UDP 123 的入站和出站规则这一步漏了是后面绝大多数不同步问题的开头。3.4 服务器端自检chronyc 两个最常用的查询服务起来之后验证同步状态用 chronycchronyc sources -v chronyc tracking chronyc clientssources -v 会列出时间源当前状态开头的符号有讲究^* 表示当前正在使用的正常时间源^ 是备选时间源^? 表示不可达。看到 ^* 说明上游源选出来了第一步算通过。tracking 输出的 System time 表示本机与源之间的偏差几毫秒是合格水平变成秒级就要继续查。clients 列出最近同步过本机的客户端地址能确认内网机器是否真的过来取了时。三行命令各有用处但巡检时第一眼看 sources 里有没有 ^* 就行。如果安装后直接执行看到的是 ^?不要急着改配置先等一到两个轮询周期个别公网源响应慢是常态。tracking 里还有一个值得留意的字段是 Stratum时间源服务器一般是 3 左右如果显示 10 说明 local 兜底生效了上游源可能根本没合格。4. 客户端配置Linux 和 Windows 机器统一指向内网服务器服务器端就绪之后客户端侧的工作就是把每台机器的时间源指到 192.168.31.1。这里分两种场景Linux 客户端优先用 chrony 做长期同步Windows 客户端用 w32tm。老的 Linux 机器实在装不上 chrony 时用 ntpdate 应急校一次也是允许的。4.1 Linux 客户端chrony 指向上游服务器客户端机器安装 chrony 和服务器端是同一套包装好之后改配置文件把默认的公网源注释掉声明内网时间源# /etc/chrony/chrony.conf # 客户端不需要公网源注释掉 # pool cn.pool.ntp.org iburst # 内网时间源iburst 加速首次同步 server 192.168.31.1 iburst makestep 1 3然后重启并检查systemctl restart chronyd chronyc sources -v chronyc tracking客户端这边不需要 allow因为它不给别人提供时间服务local stratum 10 也不用配置它是给时间源服务器兜底用的。客户端只要能看到 ^* 并且 tracking 里 System time 在几十毫秒内就说明已经同步上了。这里有个容易忽略的细节如果客户端到服务器之间跨了多个网段且经过防火墙那么客户端出站、服务器入站两边的 UDP 123 都要放行。常见做法是只配服务器入站忘了客户端出站一样会卡在 unreachable。新装的虚拟机客户端头一次启动建议先看一眼系统时间距离现实差多少。如果差好几分钟chronyd 按缓慢校准的方式要磨很久直接执行 chronyc makestep 手动步进一次再正常重启服务收敛时间会短很多。4.2 没有 chrony 的老机器先用 ntpdate 应急校准有些老系统没有 chrony 包ntpdate 作为一次性校准工具仍然好用ntpdate -b 192.168.31.1-b 参数表示跳过逐渐微调直接跳变到目标时间适合刚装完系统、偏差已经很大的场景。注意这只是应急操作绝不能靠 crontab 周期执行 ntpdate 代替常驻同步。NTP 守护进程的价值在于它会持续估计本地时钟的漂移速率定时 ntpdate 只会每次硬跳一次两者在时间收敛质量上差很多。应急校准完仍然要尽快补装 chrony。4.3 Windows 客户端w32tm 配置内网时间源Windows 在工作组环境下手动指定时间源管理员身份打开 CMD 执行w32tm /config /manualpeerlist:192.168.31.1,0x8 /syncfromflags:manual /reliable:NO /update net stop w32time net start w32time w32tm /resyncmanualpeerlist 指定手动 NTP 源0x8 告诉 w32tm 用客户端模式向该源请求时间而不是扮演对等同步的公告角色syncfromflags:manual 表示不从域或自动发现机制获取源只用上面手动写的列表update 让配置立即生效。重启 w32time 服务是必须的配置改完后服务不会热加载新源。验证用w32tm /query /status看 Source 字段是否等于 192.168.31.1如果显示的是 Local CMOS Clock 说明内部时钟源还占着位置返回去重新检查配置和刚才那条 net stop/start。另外提醒一点域环境下受组策略保护手动配置会被策略刷新覆盖正确做法是在域内设置统一的 NTP 源或者在策略里放开不是逐台手工改。5. 排查避坑时间同步装好了不同步的 5 个真实原因前面配置走完大部分机器能正常同步但总有几台怎么都不对。下面这 5 条是我这几年在局域网时间同步上遇到频率最高的坑每条按现象、原因、解决三个步骤记录方便直接对号入座。5.1 时间源显示 unreachableUDP 123 没放行现象客户端执行 chronyc sources -v源前面是 ^?等很久依然是 unreachable。原因服务器端或者客户端某一侧的 UDP 123 被防火墙拦截。NTP 是 UDP 协议与常见的 TCP 服务排查习惯不同防火墙放行 TCP 端口不会对它有影响。解决先在服务器端确认防火墙规则firewalld 执行 firewall-cmd --permanent --add-servicentp 后 reload再检查客户端出站规则云环境还要看安全组。规则改完不用重启 chronyd等下一个轮询周期 sources 里的 ^? 会自己变成 ^*一般 30 秒到 1 分钟内看到变化。5.2 systemd-timesyncd 抢占了 123 端口现象Debian 系安装 chrony 后执行 systemctl start chronyd 直接失败journalctl 里能看到端口绑定失败或者 chronyd 启动成功但 sources 查询无可达源。原因发行版自带的 systemd-timesyncd 作为 SNTP 客户端已经占用了同一个监听资源chronyd 起不来。这类自启动优先级容易被忽略。解决停用系统自带组件再启动 chronysystemctl stop systemd-timesyncd systemctl disable systemd-timesyncd systemctl restart chronyddisable 之后即使升级也不会把它带回来。装 chrony 时如果依赖关系没有自动处理就手动走一遍这三条这是新装 Debian 系服务器时我每次都会先做的事。5.3 时钟漂移特别快同步收敛后过一会又偏了现象同步时 offset 已经到几毫秒半小时再看又变成几百毫秒甚至更大像拉不回来的感觉。原因常见于虚拟化环境。虚拟机半虚拟化时钟本身精度有限宿主机节能策略变化、虚拟机迁移、休眠恢复都会造成时钟快速漂移NTP 还在按缓慢速率调整漂移速度已经超过了修正速度。解决先确认这台机器是不是在虚拟机里是的话把虚拟化平台时钟模型调到更接近真实时钟的模式关闭不必要的主机电源管理同时在客户端配置文件里把 makestep 调整得激进一些makestep 1 1这样只要偏差超过 1 秒每次轮询都可以步进修正比默认策略更贴合虚拟机场景。另外长时间挂起后恢复的虚拟机第一次同步前先执行 chronyc makestep 手动步进一次会更干脆。5.4 Windows 客户端 w32tm /resync 报服务未运行现象执行 w32tm /resync 提示服务尚未启动配置怎么改都没反应。原因Windows 时间服务 w32time 启动类型被人为改成了禁用或手动或者装完系统后一直没有启动过。解决用管理员 cmd 先把服务拉起并设成自启sc config w32time start auto net start w32time w32tm /resync注意 sc config 的 start 后面是有空格的写成 startauto 会报语法错误。恢复自启后重新配置源并同步状态查询里 Source 字段就会从 Local CMOS Clock 变为指定的内网服务器。5.5 服务器自己同步失败内网跟着全错现象内网客户端 sources 显示的是 ^*看似正常但所有机器时间和真实时间差了很大一截回到服务器上一查它的 sources 全是 ^?。原因服务器自身的上游公网源不可达。可能是出站 UDP 123 被拦截、上游源域名解析失败、运营商封了常见 NTP 地址或者服务器所在网络本身没有公网出口。客户端全部跟随服务器于是错误被整体放大了。解决先确认服务器能否解析上游域名再尝试临时用 ntpdate -b 手动校一次确认出站通路。如果上游彻底不通就换一个可用的公网 NTP 地址或者考虑在配置里加 local stratum 10 让内网至少有个统一基准。这算兜底不代表时间准后面还要尽快恢复公网源。6. 装完怎么验证把全网时间误差收敛到 50ms 以内配置全部完成不是终点验证收敛才是。我每次做完时间同步都会固定走一遍三个验证步骤防止看着配置都对实际时间还差着。6.1 服务器端看 tracking 三行关键指标chronyc tracking 里重点看三个值Leap status 为 Normal 表示没有闰秒问题System time 是本机当前与时间源的偏差数值越小越好Last offset 是最近一次校正量如果这个值是正几秒说明前一次同步直接跳了一大截。几个值都稳定在几十毫秒内服务器端就可以确认收工了。6.2 用一段脚本批量检查客户端 offset机器多的时候逐台登上去查太慢我用一个脚本解决#!/bin/bash # 批量检查客户端时间同步状态 for ip in 192.168.31.11 192.168.31.12 192.168.31.13; do echo $ip ssh $ip chronyc tracking | grep -E Leap status|System time|Last offset done思路很简单对每个客户端取 chronyc tracking 的关键行脚本里替换成自己的机器列表即可前提是管理机到各客户端已经配好了免密登录。输出里只要 System time 全部在几十毫秒量级就算通过。Windows 客户端批量验证要麻烦一点可以留一台拿 w32tm /query /status 人工确认或者用计划任务把输出写到文件里再汇总。6.3 Windows 侧验证与长期巡检习惯Windows 单机验证用 w32tm /query /status也可以执行 w32tm /monitor 查它和指定时间源的偏差。巡检频率上我习惯每周抽一次把服务器和抽样客户端的 offset 记录到交接文档里。记录的习惯比查错本身更值钱时间同步的问题往往不是爆发式故障而是慢慢漂出来的连续几周的数据一对比哪台机器在恶化提前就能发现。有次我在迁移机房后忘了同步防火墙规则内网有一半机器连不上时间源从那以后我每次做完时间同步都强制走一遍 chronyc sources -v 加客户端抽检流程确认所有点都有 ^* 才收工。希望帮到你。本文还有配套的精品资源点击获取