DHCP服务器只有在收到客户端发出的DHCP REQUEST报文，且服务器自身校验通过（如请求的IP仍可分配、租约信息匹配）时，才会发送ACK报文作为最终确认。简单说，ACK不是服务器主动发的，而是对客户端“确认要这个IP”的应答，下面从报文交互流程、触发场景、异常情况到实战排查，把这个问题讲透。
DHCP的四个阶段里，ACK为什么是“临门一脚”
要搞清楚ACK的出场时机,得先看客户端和服务器之间是怎么“对话”的，行业共识认为，DHCP完整交互由四个报文组成，顺序固定，缺一不可。
- DHCP DISCOVER：客户端刚接入网络，没有IP，于是广播“谁在？给我一个地址”。
- DHCP OFFER：服务器回应“我这里有地址，你要不要？”，此时服务器只是预留，还没正式分配。
- DHCP REQUEST：客户端选定一个OFFER（比如第一个到达的），广播回复“我就要这个地址了”。
- DHCP ACK：服务器收到REQUEST后，确认无误，正式将IP绑定到客户端MAC，发送ACK。
ACK报文的本质，是服务器对REQUEST的“点头同意”，没有REQUEST，ACK永远不会出现，这也是抓包排查时判断故障的关键如果只看到DISCOVER和OFFER，没有REQUEST，说明问题出在客户端；如果看到REQUEST却没ACK，问题多半在服务器或中间链路。
哪些情况下，DHCP服务器会发送ACK报文
实际网络环境中,ACK不是只在首次获取IP时出现，以下四个场景，服务器都会发ACK，但触发条件和报文内容略有差异。
全新客户端首次接入网络
最典型的情况,新设备开机，广播DISCOVER，服务器分配一个空闲IP并发送OFFER，客户端回复REQUEST，服务器最终发送ACK，这个时间点，服务器发送ACK的前提是：该IP在地址池内、未被占用、且已通过OFFER完成预留。
客户端租约续租成功（约50%租期）
IP地址有租约期限,默认通常是24小时，当租约过半时，客户端会单播发送REQUEST给服务器，请求续租，服务器若同意（IP依然可用、租约策略未变），就会直接回复ACK，把租约时间重新刷新。
这里有个常见误区：
续租时客户端发的是REQUEST，但服务器不一定回ACK，如果服务器因策略调整决定不续租，会回NAK，客户端就得从头开始DISCOVER，收到REQUEST后是否回ACK”，完全取决于服务器端的分配策略和当前资源状态。
DHCP中继场景下的跨网段分配
当客户端和服务器不在同一个广播域,中间隔着三层设备，客户端广播的DISCOVER会被中继（如路由器、交换机）转换成单播转发给服务器，服务器处理完，ACK报文同样先发给中继，再由中继单播或广播给客户端。
在这种架构下,ACK的发送时机没有变化，但对中继配置的依赖度极高，如果中继接口没配好，客户端可能只收到OFFER，却永远等不来ACK，排查时不能只看服务器日志，还得看中继设备的报文转发记录。
客户端重启或网卡禁用再启用
设备重启后,会主动发送REQUEST，请求续用上次分配的IP（即使租约还在有效期内），服务器核对租约数据库，发现该IP仍绑定此客户端MAC，直接发送ACK，完成快速重连。
这个机制的好处是IP稳定，设备重启后大概率还是原来的地址，不会频繁变动，服务器发送ACK的前提是租约记录未过期、IP未被管理员手动排除或分配给其他设备。
什么情况下服务器打死不回ACK，反而回NAK
很多人在排查“拉不到IP”的问题时，抓包看到的不是“没有响应”，而是收到NAK报文，NAK和ACK互为镜像，NAK是拒绝，ACK是同意，服务器回NAK的场景主要有三种：
- 客户端请求的IP超出地址池范围：比如服务器地址池是192.168.1.100-200，客户端REQUEST却要192.168.1.250，服务器直接拒绝。
- 租约记录不匹配：客户端声称自己之前租过某个IP，但服务器数据库里根本没有对应记录，或者该IP已绑定到别的MAC。
- IP地址被保留或冲突：管理员手动保留了某IP给特定设备，或者其他设备已在用，服务器确认无法分配，只能回NAK。
需要特别注意的是：服务器回NAK也需要收到REQUEST才行，如果客户端一直在发DISCOVER而服务器不回任何消息，问题就从“分配逻辑”变成了“可达性或配置问题”可能地址池耗尽、服务未启动，或报文被防火墙丢弃，区别这两种情况，是排查效率的关键。
抓包验证：怎么亲眼看到ACK报文发出
纸上谈兵没用,实操才是硬道理，在Windows服务器上，用Wireshark抓包验证ACK的发送时机，步骤如下：
- 在DHCP服务器上打开Wireshark,选择连接客户端网段的网卡，抓包过滤器填入
port 67 or port 68。 - 让客户端执行
ipconfig /release再执行ipconfig /renew。 - 观察抓包结果,正常流程你会依次看到DISCOVER、OFFER、REQUEST、ACK四个报文的顺序出现。
- 双击ACK报文,在“Option Field”里能看到租约时间（Renewal Time Value）、子网掩码、网关、DNS等信息，所有参数的确认都在这一个包里完成。
如果想快速确认服务器是否回包,也可以用命令行看统计：
- Windows服务器：在PowerShell里键入
Get-DhcpServerv4Statistics，查看“Offer”和“Ack”计数器是否在增长。 - Linux（常见ISC DHCP）：查看
/var/lib/dhcp/dhcpd.leases文件，成功分配的记录末尾有binding state active字样，和ACK是同步完成的。
收不到ACK？按这个顺序排查，不走弯路
如果你在抓包里只看到REQUEST而没有ACK,大概率是以下四个原因之一，按顺序排查效率最高：
- 看地址池是否耗尽，打开服务器地址池的已用数量统计，如果分配率接近上限，服务器根本无IP可给，自然不会回ACK。
- 看REQUEST和服务器记录是否冲突，比如客户端请求的IP已从地址池中删除或改成保留，服务器会直接回NAK而非ACK。
- 看中间链路是否拦截单播，REQUEST是单播优先，若中间交换机开了DHCP Snooping且信任口配置错误，很可能直接把REQUEST丢弃，服务器压根没收到，自然无ACK可回。
- 看服务器日志中的错误ID，Windows事件查看器里，DHCP服务的错误日志会明确写出“地址已被占用”或“作用域已停用”等具体原因，比盲改配置高效得多。
回答常见疑问：搞懂这几个问题，ACk的发送场景你就彻底明白了
DHCP服务器收到OFFER后马上就发ACK吗？
不是,OFFER之后必须等待客户端的REQUEST，服务器不会主动把地址硬塞给客户端，如果在OFFER之后长时间没等到REQUEST，服务器会把预留的IP重新放回地址池，这个等待时间通常由实现决定，常见默认是60秒左右，所以严格说，服务器的ACK不是“发送”出来的，而是“回应”出来的。
为什么我设置了DHCP服务器但客户端总是拿到169.254开头的地址？
254开头是Windows系统的APIPA自动私有地址,说明客户端完全没收到任何有效OFFER或ACK，整个DHCP交互都没成功，这种情况优先排除链路问题检查网线、VLAN、中继配置，而不是盯着服务器端看，如果客户端连OFFER都收不到，就不会发REQUEST，更轮不到ACK出场，中继配置错误是该现象的常见原因。
DHCP服务器在续租时发送的ACK和首次分配时的ACK有区别吗？
功能一致,但报文内容有细微差异，续租ACK通常会刷新租约时间，且报文中携带的Option参数（如DNS、网关）可能与首次分配时一致，而首次分配ACK则是在新绑定租约记录后发送，从抓包上看，二者的报文结构完全相同，区别只在于服务器内部的租约状态是“续约”还是“新建”，还有一种细微区别：续租ACK通常单播发给客户端，而首次分配ACK在部分广播网络中可能以广播形式发出，但这不是必须的。
如果两台DHCP服务器同时在线，ACK会是谁发的？
通常是先收到REQUEST并确认租约记录的那台，如果两台服务器的地址池没有做冲突避免（比如用拆分作用域或热备协议），客户端可能会收到两个不同的OFFER，但REQUEST只认其中一个，一旦REQUEST发出去，另一台服务器看到这不是自己OFFER的IP，通常会保持沉默，不回ACK也不回NAK，所以多服务器环境下，客户端只收到一个ACK是正常的，收到两个反而要检查配置。
结尾说句实话
弄懂ACK的发送时机,其实就是弄懂DHCP协议的“确认制”思维服务器的一切分配行为都要以客户端的请求为起点，而ACK就是这条请求链路的最终盖章，下次遇到IP获取失败，先别急着换服务器，抓个包看看报文走到哪一步断了，按请求链路逐段检查发送条件，答案会比想象中更清晰。