服务器会向dhcp发送什么信息，dhcp服务器如何回应请求？

服务器在DHCP交互中主要向客户端发送DHCPOFFER（租约建议）、DHCPACK（租约确认）和DHCPNAK（租约拒绝）三类报文，分别对应租约分配、确认和拒绝场景。

DHCP服务器发送的核心报文：OFFER、ACK、NAK

服务器收到的第一条消息，永远是客户端广播的DHCPDISCOVER，服务器看完之后，会从自己的地址池里挑一个空闲IP，然后回一条DHCPOFFER，相当于递了一张“租房合同草案”，草案里有IP地址、子网掩码、网关、DNS、租期时长，以及服务器自己的标识（Server Identifier）。

客户端可能同时收到多台服务器的OFFER，但它只选第一张“合同”，然后广播DHCPREQUEST，告诉所有人“我选定了哪台服务器”，被选中的服务器收到REQUEST后，验证一下租约信息，觉得没问题，就甩出DHCPACK真正的“合同生效通知”，从此,客户端网卡上的IP被正式激活。

如果服务器发现这个IP已经被别的设备占用，或者地址池里已经没有可用空间，就回一条DHCPNAK，相当于“对不起，这房不能租给你”，客户端收到NAK后，会回到初始状态，重新发DHCPDISCOVER，或者干脆显示网络受限。
注意，NAK只在服务器收到REQUEST之后才可能出现服务器不会主动发NAK,它必须等客户端先开口。

DHCPOFFER里到底装了什么

OFFER报文是服务器对客户端“可供分配资源”的完整告白，它包含：

• 你的候选IP地址（yiaddr字段）
• 子网掩码（Option 1）
• 默认网关（Option 3）
• DNS服务器列表（Option 6）
• 租期时长（Option 51）
• 服务器标识（Option 54），即服务器自己的IP 域名（Option 15）、WINS服务器（Option 44）、TFTP服务器地址（Option 66,常用于无盘工作站）

这些选项并非服务器“自由发挥”，而是来自DHCP服务器配置里的作用域设置，比如Windows Server的DHCP控制台里，你可以在“服务器选项”或“作用域选项”里逐条设置，Linux的ISC DHCP则用option routers、option domain-name-servers这类参数声明。

DHCPACK：租约确认的完整清单

ACK是OFFER的最终确认版本，内容几乎一样,但多了两个重要变化：

• 租期开始时间自动重置，以服务器收到REQUEST的那一刻为起点
• Option 53（消息类型）改成5，表示“确认”

客户端拿到ACK后，会做一次冲突检测（ARP探测），如果发现IP冲突，会发DHCPDECLINE给服务器，服务器收到后把这个IP标记为“不可用”并暂时放进黑名单，若没有冲突,客户端就正式启用这个IP。

DHCPNAK：拒绝背后常见的几个原因

服务器不是随便拒绝的，触发NAK的场景很固定：

• 客户端的REQUEST里带的IP，已经不是这个服务器分配的了（比如租约已被回收后，客户端还在续租）
• 客户端跨越了VLAN，物理位置变了，原有作用域不再匹配
• 地址池耗尽且没有可排除的保留地址

这里有个容易混淆的点：客户端用DHCPINFORM请求本地配置参数（比如只要DNS和网关，不要求分配IP）时，服务器只回ACK或者INFORM响应，但这个ACK不带租约,只是纯配置参数下发。

DHCP服务器租约到期会怎样：续租流程中的发送逻辑

当租期过半（T1时间点），客户端会单播发送DHCPREQUEST给原服务器请求续租，这个过程的报文和初次分配时一模一样，服务器只需要回ACK，租期就重新刷新，如果服务器没理它，客户端等到租期到87.5%（T2时间点）时，就改成广播发DHCPREQUEST，此时如果原服务器还是没反应,就找别的服务器帮忙。

租约到期且服务器拒绝续租

DHCP服务器租约到期会怎样，最典型的答案是：IP被服务器回收，客户端继续使用则会出现“IP地址冲突”提示，服务器不会主动发消息给已经下线的客户端它靠租约时间自动判定，到期后地址回到地址池，被分配给下一个设备，如果原客户端还在线上，可能引发IP冲突，它的表现往往是“网络连接受限”或者“另一台设备无法上网”。

服务器主动释放租约的情况

有两种场景服务器会主动发起释放逻辑：

• 管理员在DHCP控制台或命令行里强制删除了某个租约
• 检测到客户端发送了DHCPRELEASE（常见于用户执行ipconfig /release）

但严格说，服务器不会向客户端发送“释放通知”，它只是默默地把租约标记为可重用，所以如果你在客户端上看到“已释放”字样，那是客户端自己产生的状态,不是服务器通知的。

DHCP中继和DHCP代理的区别：服务器视角的报文转发

跨网段部署时，客户端广播的DISCOVER到不了服务器，就得靠DHCP中继（Relay Agent）转单播。DHCP中继和DHCP代理的区别，很多人混为一谈，行业共识认为，两者本质功能相同都在不同网段之间桥接DHCP报文，但工作层次略有差异：

• DHCP中继：工作在IP层，只转发报文，不解析也不修改选项
• DHCP代理：常指嵌入在路由器/防火墙里的简化版中继逻辑，部分设备会额外插入Option 82（中继代理信息），记录客户端所在端口号和VLAN

服务器视角看，两者都只是“传话筒”，但中继会在转发给服务器的报文里加一个giaddr（网关IP地址）字段，服务器就靠这个字段判断客户端属于哪个作用域，从而挑选对应的地址池，没有这个字段,服务器无法跨网段分配IP。

服务器对中继报文的特殊回应

当服务器收到带giaddr的报文时，它不是广播回包，而是单播发送给中继设备的IP地址，再由中继转发给客户端，所以你可以简单理解：服务器在跨网段时，永远只和中继对话，不和客户端直接对话。

服务器也会主动发信：DHCPFORCERENEW和INFORM响应

多数人以为DHCP服务器永远是被动响应，其实它还有一种主动行为发送DHCPFORCERENEW（Option 82中用到的强制续租指令），这是一种自定义扩展选项（RFC 3203），用于让客户端立刻重新续租，常用于地址回收、网络策略变更时，但老实说，这玩意儿在现实网络里少见,主流系统默认都不开启。

另一种服务器主动下发的场景是DHCPINFORM响应，客户端已经拥有静态IP，只希望“查一下DNS、网关等额外参数”，就发DHCPINFORM，服务器收到后，直接给一个ACK或者INFORM响应，里面带Option 6（DNS）、Option 3（网关）、Option 15（域名）等参数，但不分配IP、不建立租约，这在无盘工作站、VOIP电话、打印机获取网络参数时很常见它们不需要服务器管IP，但需要服务器告诉它们“DNS是谁”。

实操：如何抓包看服务器到底回了什么

你不需要猜，只要能抓到包,一切清清楚楚。

• 在Windows上运行netsh trace start capture=yes，或者装个Wireshark
• 过滤条件填dhcp或者port 67 or port 68
• 在客户端执行ipconfig /renew，立刻能看到一串交互

你会在抓包里看到顺序：DISCOVER → OFFER → REQUEST → ACK，点开OFFER和ACK报文，展开“Dynamic Host Configuration Protocol”层，能看到服务器的所有选项字段，重点观察：

• Option 54（Server Identifier）服务器的身份
• Option 51（IP地址租用时间）默认通常是86400秒（1天）
• Option 61（客户端标识）是MAC还是自定义ID

如果看到NAK，Expand开来看“Message Type”是6，此时排查方向：检查客户端是否换过网卡、是否跨了VLAN、是否和保留地址冲突。

Linux下的验证方式

在CentOS/RHEL/Ubuntu上，用

tcpdump -i eth0 port 67 or port 68 -env，实时抓取DHCP交换，想确认服务器配置是否正确，直接看/var/log/messages或/var/log/syslog里的dhcpd日志。
检查服务器实际分配了哪些参数：在Linux上跑ipconfig /renew不如dhclient -v eth0直观,它会打印出DHCPOFFER中携带的所有option。

Q&A：服务器与DHCP通信的常见问题

DHCP服务器容易遇到的报错是什么？

频率最高的是“地址池耗尽”和“冲突检测失败”，地址池耗尽时，服务器会记录类似“No free leases”的日志；冲突时则记录“DHCPDECLINE”，这两种都不是服务器硬件问题，多数情况下是规划失误地址池范围设置过小，或者大量设备的租期设成了无限长。
对策：把租期适当缩短（例如无线网络改成8小时），并保证地址池排除掉打印机、服务器等静态设备所在的IP段。

为什么有的DHCP服务器配置教程里强调要设置“作用域选项”而忽略“服务器选项”？

作用域选项只对当前IP段生效，服务器选项对整台服务器所有作用域生效，从DHCP服务器配置教程的角度看，新手常犯的错是在服务器选项里填了某段特定的DNS，结果另一个VLAN也继承了它，导致解析异常，行业共识是：作用域选项优先级高于服务器选项，两台不同路径的设备,建议直接在作用域里配置专属参数。

企业DHCP服务器哪家好？

没有绝对答案，但按场景分就有倾向性：

• 纯Windows环境：Windows Server的DHCP角色最顺手，和AD域控联动好，企业DHCP服务器哪家好这个问题的常见回答就是微软自家
• 混合环境或Linux居多：ISC DHCP虽然停止主动维护，但仍是经典；Kea DHCP（ISC继任者）更适合现代网络，支持数据库后端
• 路由器/交换机内置：适合小网络，功能弱但零成本
• 考虑高可用：Windows DHCP支持故障转移；Kea支持数据库同步；软路由如OpenWrt也能做简单HA
  真要塞进生产环境，建议把DHCP放在独立服务器或虚拟机，别塞在域控上，避免“单点故障连带”。

服务器向DHCP客户端发送的信息，本质就一句话：告诉客户端“用这个IP，这个网关，这个DNS，用这么久，不行就说不行”，搞懂OFFER、ACK、NAK的分工，再理解续租和跨网段的转发逻辑，大部分DHCP疑难杂症都能对症下药，抓包永远是验证真相的最佳手段下次网络不通，先别重启路由器，抓一把DHCP包看看服务器到底“说”了啥。