简介：DHCP Server for Windows V2.3 是一款面向 Windows 平台的轻量级 DHCP 服务端工具，适合网络管理员、运维人员及需要搭建小型局域网或远程启动环境的用户使用。它能为 TCP/IP 网络中的其他计算机自动分配 IP 地址，并额外集成 TFTP、DNS 与 HTTP 协议支持，便于快速部署简易网络，满足远程引导等场景需求。压缩包共 9 个文件，约 101KB，包含 2 个 exe 主程序与配置向导、2 个 xsl 样式表、1 个 html 页面、1 个 txt 说明文档、1 个 ico 图标及 2 张 jpg 示意图，结构紧凑、开箱即用。目前已有 390 人学习下载，读者可借助内置向导完成服务配置，通过说明文档了解参数含义与部署要点，并参考示例页面与样式表理解其 Web 管理界面组织方式，适合作为局域网 IP 分配与远程启动实验的入门工具。
1. 为什么一台 Windows 机器值得单独跑一个 DHCP Server
很多人第一次听到「DHCP Server for Windows」会下意识觉得多余：路由器不是自带 DHCP 吗，域控不是也能发地址吗，为什么还要在一台 Windows 主机上单独装一个 DHCP 服务？答案往往出现在那些路由器管不到、域控又不想碰的场景里——实验室里几十台设备要按 MAC 绑定固定 IP、内网要下发自定义的 PXE 引导地址和 TFTP 服务器、临时搭建的隔离网段需要快速给一批机器分配地址并记录租约。这些需求用路由器做要么功能太弱，要么改一次配置要重启整网。
DHCP Server for Windows V2.3 就是冲着这类场景来的：它是一个原生跑在 Windows 上的轻量 DHCP 服务端，不依赖 IIS、不依赖域环境，配置文件是纯文本，启动即用，日志能直接看到每一次 DISCOVER、OFFER、REQUEST、ACK 的往返。它解决的核心问题是「在 Windows 上有一个可控、可观测、可脚本化的 DHCP 服务」，适合做网络实验、内网运维、嵌入式设备批量上电测试的工程师。下面按「它怎么工作 → 怎么装怎么配 → 参数怎么调 → 坑在哪 → 怎么验证」的顺序讲透。
2. DHCP Server for Windows V2.3 的工作方式与选型理由
2.1 它和路由器 DHCP、Windows Server DHCP 角色的区别
先把三种常见方案摆在一起看，选型时心里才有数。
| 方案 | 配置方式 | 可观测性 | 自定义选项 | 适用场景 |
|---|---|---|---|---|
| 路由器内置 DHCP | Web 界面点选 | 弱，多数只有租约列表 | 少，通常只能改网关/DNS | 家庭、小型办公 |
| Windows Server DHCP 角色 | 图形控制台 + 域集成 | 中，有审计日志 | 中，需域或授权 | 企业域环境 |
| DHCP Server for Windows V2.3 | 纯文本 ini + 命令行 | 强，逐包日志 | 强，可下发任意 option | 实验网、隔离网段、批量测试 |
关键差异在「可观测性」和「自定义 option」。路由器 DHCP 出问题时你只能看到「没拿到地址」，而 V2.3 会把每个数据包的交互写进日志，你能看到客户端发了什么、服务端回了什么、为什么没回。做嵌入式批量上电测试时，这一点决定了你排查问题是以分钟计还是以小时计。
2.2 配置文件驱动的运行模型
V2.3 的核心是一个 ini 文件，服务启动时读取它，之后所有行为都由这份配置决定。理解它的结构比记命令更重要。典型配置分成三段：全局段定义监听网卡和租约时间，子网段定义地址池和网关，保留段按 MAC 绑定固定地址。
# dhcpsrv.ini 结构示意 [GLOBAL] # 监听哪块网卡，多网卡时用分号分隔 INTERFACE=192.168.50.1 # 默认租约时长，单位秒 LEASETIME=86400 # 日志级别，0 关闭，1 只记错误，2 记租约，3 记全部数据包 LOGLEVEL=3 [SUBNET_192.168.50.0] # 地址池起止 RANGE=192.168.50.100,192.168.50.200 # 下发的网关 ROUTER=192.168.50.1 # 下发的 DNS DNS=192.168.50.1,8.8.8.8 # 子网掩码 MASK=255.255.255.0 [RESERVED_01] MAC=00-1A-2B-3C-4D-5E IP=192.168.50.10这段配置的逻辑是：服务只监听 192.168.50.1 这块网卡，收到请求后先看是不是保留段里的 MAC，是就直接发固定 IP，不是就从 RANGE 里挑一个空闲地址。LEASETIME 决定客户端多久续租一次，LOGLEVEL 决定你能看到多少细节。参数说明：INTERFACE 必须写本机真实网卡地址，写错服务起不来；RANGE 的起止不能包含网关和保留地址，否则会冲突；MASK 和 ROUTER 必须和实际网段一致，否则客户端拿到地址也上不了网。
2.3 什么时候不该用它
如果你的网络里有 Windows 域控，且需要和 DNS 动态更新联动，那用 Server 自带的 DHCP 角色更省事，V2.3 不参与域集成。如果只是家庭网络，路由器 DHCP 足够，没必要多维护一个服务。V2.3 的价值区间是「隔离网段 + 需要精细控制 + 需要看日志」，超出这个区间就要重新评估。
3. 在 Windows 上把 V2.3 跑起来的最小步骤
3.1 安装与首次启动
V2.3 通常以压缩包形式分发，解压后是一个可执行文件加一份示例配置。不要双击 exe 就完事，正确做法是先确认网卡地址，再改配置，最后以服务方式启动。
# 第一步：查看本机网卡地址，确认要监听哪一块 ipconfig /all # 第二步：进入解压目录，复制示例配置 cd C:\dhcpsrv copy dhcpsrv.ini.example dhcpsrv.ini # 第三步：用记事本或 VSCode 编辑 dhcpsrv.ini notepad dhcpsrv.ini # 第四步：前台启动，观察日志输出，确认没有报错 dhcpsrv.exe -debug # 第五步：确认无误后注册为 Windows 服务，后台运行 dhcpsrv.exe -install net start "DHCP Server"逻辑说明：-debug模式让服务在前台运行并把日志打到控制台，方便第一次调试时看到数据包交互。确认能正常发地址后再-install注册成服务，这样开机自启、不占终端。参数说明：-install会把服务注册到系统，服务名通常是「DHCP Server」；如果之前装过旧版本，先-remove卸载再装，否则会残留旧配置。
3.2 配置一块独立网卡做隔离网段
做实验时最稳妥的做法是给 Windows 主机加一块 USB 网卡或第二块板载网卡，专门接实验网段，不要和办公网混在一起。
[GLOBAL] # 只监听实验网段那块网卡 INTERFACE=192.168.50.1 LEASETIME=3600 LOGLEVEL=3 [SUBNET_192.168.50.0] RANGE=192.168.50.100,192.168.50.150 ROUTER=192.168.50.1 DNS=192.168.50.1 MASK=255.255.255.0这里 LEASETIME 设成 3600 秒而不是 86400，是因为实验网段设备经常上下电，短租约能让地址回收更快，避免池子被占满。LOGLEVEL=3 会记录每个数据包，调试阶段必开，稳定后可以降到 2 减少日志量。注意 RANGE 只给了 51 个地址，如果实验设备超过这个数，要么扩大范围，要么缩短租约。
3.3 用保留段做 MAC 绑定
批量测试时经常需要每台设备每次上电都拿到同一个 IP，方便脚本按 IP 去连。做法是在配置里加保留段。
[RESERVED_DEV01] MAC=00-1A-2B-3C-4D-5E IP=192.168.50.10 [RESERVED_DEV02] MAC=00-1A-2B-3C-4D-5F IP=192.168.50.11逻辑说明：服务收到请求后先匹配 MAC，命中保留段就直接返回对应 IP，不再从 RANGE 里分配。参数说明：MAC 格式用连字符分隔，大小写不敏感，但必须和客户端实际 MAC 完全一致，差一位就匹配不上。保留 IP 不要落在 RANGE 区间内，否则可能和动态分配冲突。改完配置后需要重启服务或发重载信号才生效。
4. 参数调优与日志排查：把玄学变成可观测
4.1 租约时间、地址池大小和并发上电的关系
批量上电是最容易翻车的场景：几十台设备同时发 DISCOVER，如果地址池太小或租约太长，会出现「前面设备占着地址不放，后面设备拿不到」。经验公式是地址池大小至少是并发设备数的 1.5 倍，租约时间按测试轮次来定。
| 场景 | 地址池建议 | 租约时间 | 理由 |
|---|---|---|---|
| 单台调试 | 10 个地址 | 86400 秒 | 稳定不变，方便反复连 |
| 小批量测试（<20 台） | 30 个地址 | 3600 秒 | 兼顾回收和稳定 |
| 大批量上电（>50 台） | 设备数 × 1.5 | 600 秒 | 快速回收，防止池满 |
租约时间不是越短越好。太短会导致客户端频繁续租，增加服务端负担；太长会导致地址回收慢。600 秒适合上电测试，86400 秒适合长期运行的设备。
4.2 看懂日志里的四步握手
V2.3 的日志会按数据包类型记录，排查问题时按 DISCOVER → OFFER → REQUEST → ACK 的顺序看。
# 正常交互日志片段 DISCOVER from 00-1A-2B-3C-4D-5E via 192.168.50.1 OFFER 192.168.50.100 to 00-1A-2B-3C-4D-5E REQUEST 192.168.50.100 from 00-1A-2B-3C-4D-5E ACK 192.168.50.100 to 00-1A-2B-3C-4D-5E如果只看到 DISCOVER 没有 OFFER，说明服务端没匹配到子网或地址池空了。如果看到 OFFER 没有 REQUEST，说明客户端没接受这个地址，通常是客户端已经有地址或配置了静态 IP。如果看到 REQUEST 没有 ACK，说明服务端在确认阶段出了问题，检查保留段是否冲突。这套四步对照法能把大部分「设备拿不到地址」的问题定位到具体环节。
4.3 用 Wireshark 交叉验证
日志是服务端视角，客户端视角要用抓包。在 Windows 主机上装 Wireshark，过滤bootp或udp.port == 67 || udp.port == 68，能看到完整的 DHCP 交互。
# Wireshark 显示过滤器 bootp # 或者按端口过滤 udp.port == 67 || udp.port == 68逻辑说明：67 是服务端端口，68 是客户端端口。抓包能看到日志里看不到的东西，比如客户端发的 DISCOVER 里带了哪些 option、服务端的 OFFER 里 option 53 是什么值。当日志和抓包对不上时，以抓包为准，因为日志可能因为级别设置漏记。参数说明：抓包时要选对网卡，多网卡机器上选错网卡会什么都抓不到。
5. 避坑：V2.3 部署中最容易踩的五个坑
5.1 服务起不来，日志报「无法绑定接口」
现象：dhcpsrv.exe -debug启动后立刻退出，日志提示绑定失败。原因：INTERFACE 里写的地址不是本机真实网卡地址，或者该网卡被禁用。解决：用ipconfig /all确认地址，确保网卡处于启用状态，INTERFACE 写的是本机地址而不是网段地址。
5.2 客户端拿到地址但上不了网
现象：设备显示已获取 IP，但 ping 不通网关。原因：ROUTER 或 MASK 配错，或者下发的网关地址不在本机网段。解决：检查 ROUTER 是否等于本机监听地址，MASK 是否和实际网段一致，客户端ipconfig看到的网关是否可达。
5.3 保留地址和动态地址冲突
现象：某台设备偶尔拿到保留 IP，偶尔拿到动态 IP。原因：保留 IP 落在了 RANGE 区间内，服务端在动态分配时可能先把这个地址分出去。解决：把保留 IP 全部移到 RANGE 之外，或者把 RANGE 缩小到不包含保留地址。
5.4 多网卡机器上服务监听了错误的网卡
现象：实验网段设备拿不到地址，但办公网设备拿到了。原因：INTERFACE 没指定，服务默认监听了第一块网卡。解决：显式写 INTERFACE，只写实验网段那块网卡的地址，多网卡时用分号分隔但通常不建议同时监听。
5.5 改完配置不生效
现象：改了 ini 文件，客户端拿到的还是旧参数。原因：服务启动时读一次配置，之后不会自动重载。解决：改完配置后net stop "DHCP Server"再net start "DHCP Server"，或者用服务管理器重启。注意重启会中断正在进行的租约交互，批量测试时选在轮次间隙操作。
6. 用脚本批量验证租约与自动化回归
6.1 从日志里提取租约做自动核对
手工看日志只能应付几台设备，几十台就要靠脚本。下面这段 Python 从日志里提取 ACK 记录，输出 MAC 和 IP 的对应关系，方便和预期清单比对。
import re # 匹配 ACK 行，提取 IP 和 MAC pattern = re.compile(r'ACK (\d+\.\d+\.\d+\.\d+) to ([0-9A-Fa-f-]+)') leases = {} with open('dhcpsrv.log', 'r', encoding='utf-8') as f: for line in f: m = pattern.search(line) if m: ip, mac = m.group(1), m.group(2).upper() leases[mac] = ip # 输出排序后的租约表 for mac in sorted(leases): print(f'{mac} -> {leases[mac]}')逻辑说明：正则只抓 ACK 行，因为 ACK 才是最终确认的租约。用字典按 MAC 去重，同一设备多次续租只保留最后一次。参数说明：日志路径按实际改，编码用 utf-8 防止中文路径乱码。如果日志级别低于 3，ACK 行可能不存在，需要先把 LOGLEVEL 调到 3。
6.2 用预期清单做回归比对
把预期租约写成一个 CSV，和脚本输出比对，就能在批量测试后快速发现哪台设备没拿到正确地址。
import csv expected = {} with open('expected.csv', 'r') as f: for row in csv.DictReader(f): expected[row['mac'].upper()] = row['ip'] for mac, ip in expected.items(): actual = leases.get(mac) if actual != ip: print(f'MISMATCH {mac}: expected {ip}, got {actual}')逻辑说明：expected.csv 里放 MAC 和预期 IP，脚本逐条比对，只打印不一致的。这样批量测试后一眼就能看出问题设备。参数说明：CSV 表头必须是 mac 和 ip，MAC 格式和日志里保持一致。这个脚本可以挂到 CI 里，每次测试自动跑。
6.3 一个我常用的习惯
每次改完配置，我不会直接上批量设备，而是先拿一台笔记本连上去，ipconfig /release再ipconfig /renew，确认拿到预期地址后再上批量。这个习惯帮我省过很多次「改错一个参数导致几十台设备全拿不到地址」的后悔药。DHCP 这东西，配置看着简单，但一个字符错了就是全网翻车，先单台验证再批量，是最划算的保险。希望帮到你。
本文还有配套的精品资源，点击获取
