DHCP服务器联通状态显示失败，本质上是客户端在请求IP地址时没有得到合法回应，原因集中在服务状态、网络链路和地址池配置三个层面，排查时需要逐层确认而不是盲目重启。
为什么DHCP服务器联通状态会显示失败
先理清一个概念,这里说的联通状态，指的是DHCP服务器与客户端之间的通信链路是否正常，显示失败，意味着客户端发出的DHCP Discover报文没有收到服务器的响应，或者响应报文没有正确回到客户端，这种情况在局域网维护中相当常见，尤其在路由器、交换机、Windows Server混合组网的环境里，出问题的概率更大。
服务进程有没有在跑：检查系统服务状态
很多人第一反应是网线松了或路由器坏了,但实际情况往往是DHCP服务本身已经停止响应，在Windows Server上，打开“服务管理器”，找到“DHCP Server”这一项，如果它显示“已停止”，那联通状态失败就很正常了，服务被禁用通常发生在系统更新之后，或者被安全软件误杀。
Linux环境下同理,主流发行版用的DHCP服务是dhcpd或dhcpd6，你可以在终端里执行systemctl status dhcpd来确认它的运行状态，这里要提醒一个容易忽略的点：服务进程活着不代表服务正常工作，如果服务处于“已停止”但被配置为“自动启动”，大概率是启动时加载配置失败，需要去查事件日志。
网络路径通不通：链路、防火墙和VLAN
DHCP走的是UDP协议,客户端用68端口发包，服务器用67端口监听，任何一层网络设备掐掉这两个端口，联通状态都会直接显示失败，行业共识认为，企业内部网络七成以上的DHCP故障出在防火墙策略上，而不是DHCP服务本身。
实操中可以这样验证：在客户端电脑上运行ipconfig /all，如果看到IP地址是169.254开头的，说明系统自动分配了一个APIPA地址，DHCP请求根本没有到达服务器，这时候可以抓包确认，Windows下可以临时关闭防火墙测试，但生产环境不建议这么干，更好的方式是检查防火墙规则里是否放行了UDP 67和68端口。
地址池还有没有货：租约耗尽和排除范围
另一个高频原因是地址池耗尽,DHCP服务器给每一台设备分配地址时会记录一个租约期限，默认通常是8天，如果内网设备多、地址池范围小，新设备接入时就没有空闲地址可分配。联通状态显示失败不等于服务器宕机，它可能只是“没有货”了。
在Windows Server管理界面里面，打开IPv4下的“地址池”一栏，能看到已用地址和剩余地址的数量，如果剩余为0，就需要扩容，但扩容前建议先检查作用域里有没有设置大量保留地址，或者存在不该有的排除范围，这些地址永远不会被分配，却占着池子。
客户端与服务器不在同一网段怎么办
跨网段分配地址依赖DHCP中继代理,如果服务器在192.168.1.0/24网段，客户端在192.168.2.0/24网段，中间的三层交换机必须配置ip helper-address指向DHCP服务器地址，很多网络管理员改了VLAN后忘记同步这条配置，结果就是一部分电脑能上网，一部分电脑获取不到地址，这类故障排查起来比较费劲，因为服务器端看不到任何请求记录。
DHCP服务器联通状态显示失败怎么解决
排查要按顺序来,从最上层服务到最底层链路，不要跳步。
第一步：确认服务状态并重新授权
Windows Server的DHCP服务有个特点，域环境下必须在AD里对服务器进行授权，没有授权的DHCP服务器无法对外提供服务，即使它在运行状态，打开DHCP管理工具，右键服务器名，授权”选项可用，说明当前就是未授权状态，点击授权之后等一两分钟再刷新。
Linux下没有授权这个概念,但需要确认配置文件语法正确，执行dhcpd -t可以测试配置文件的语法，如果返回空或者没有报错，再重启服务，重启命令是systemctl restart dhcpd，用这类命令来修复之后，建议顺手查看服务状态，确保没有启动失败。
第二步：从客户端角度测试联通性
这里给一个比较直接的测试思路,在客户端上释放IP再重新获取：
ipconfig /release ipconfig /renew
如果显示“无法联系DHCP服务器”，说明请求根本没有到达服务端，如果提示“服务器拒绝了请求”，说明请求到了但分配逻辑有问题，两种结果对应的排查方向完全不一样，前者查网络链路、中继代理和防火墙，后者查地址池、保留策略和租约状态。
第三步：看日志和抓包定位细节
Windows Server的事件查看器里，找到“Windows日志-系统”，筛选来源为“Dhcp-Server”的事件，地址池耗尽会有明确的事件ID提示，比如事件ID 1020表示没有可用地址，Linux下看/var/log/messages或journalctl -u dhcpd，日志里会直接写出是哪个MAC地址被拒绝了，以及拒绝理由。
如果日志信息不够,用tcpdump在服务器上抓包，命令如下：
tcpdump -i eth0 port 67 or port 68 -n
能看到客户端Discover报文但看不到服务器回复,说明问题出在服务器本机，如果连Discover报文都看不到，说明数据包没到服务器，问题在中间链路。抓包结论能直接砍掉一半排查方向，比猜快得多。
第四步：处理冲突和错误配置
客户端拿到地址后先发免费ARP探测,如果局域网内已经有设备占用这个IP，客户端会回复DHCP Decline，服务器收到后把这个地址标记为冲突，这类问题常见于AP、打印机等固定IP设备，和DHCP地址池范围重叠，解决方法是把固定IP设备排除在DHCP作用域之外。
另外注意一下DNS设置,DHCP服务器分配IP的同时也会下发DNS地址，如果下发的DNS指向已下线服务器，客户端能获取地址但上不了网，表现很像联通状态异常，在作用域选项中检查“003路由器”和“006 DNS服务器”这两个选项是否填写正确。
避免DHCP服务器反复故障的配置建议
恢复服务之后,优化配置能减少后续问题的发生频率。
租约时间和地址池规划
行业共识认为,地址池使用率长期超过百分之七十时就要考虑扩容或缩短租约，办公网络设备固定，租约可以设置8天以上；访客网络或临时设备多，租约建议设置为2到4小时，方便地址快速回收，这个参数在Windows Server的作用域属性里调整，Linux则在dhcpd.conf中修改
default-lease-time和max-lease-time。
冗余和监控机制
规模稍大的网络建议部署两台DHCP服务器,一份故障转移（failover）通常情况下能把中断时间控制在一分钟以内，Windows Server自带DHCP故障转移功能，配置路径是右键IPv4选择“配置故障转移”，Linux的dhcpd原生支持failover协议，但配置复杂一些，就算不做热备，至少要把服务加入监控系统，当服务停止或地址池低于阈值时自动告警，有条件的话每周做一次配置备份，避免服务器崩溃后整个配置丢失。
DHCP服务器故障排查与设置常见问题
Q：DHCP服务器联通状态显示失败，但部分客户端还能上网，这是怎么回事？
A：这个现象说明服务器没有彻底宕掉，很可能是缓存或地址租约仍在生效，已获取到IP的设备在租约期内不受影响，新接入的设备才需要向服务器请求地址，另外有些客户端的网卡里配置了备用IP，联通状态正常但用的是静态地址，也需要留意。
Q：DHCP服务已启动，为什么客户端还是获取不到地址？
A：服务进程存活并不代表服务可用，需要检查服务器是否已在AD中授权、作用域是否被停用、地址池是否已满，如果这些都正常，再看UDP 67和68端口通不通，在服务器上执行netstat -an | findstr "67"（Windows）或ss -ulpn | grep dhcp（Linux），确认端口处于监听状态，确认之后回头检查网络链路上的访问控制列表。
Q：如何判断DHCP客户端拿到的IP是动态分配还是手动指定？
A：在Windows命令行执行ipconfig /all，查看“DHCP已启用”这一行，显示“是”表示地址由DHCP服务器分配，显示“否”表示手动指定，Linux下执行nmcli dev show查看“DHCP4”字段，或在命令行输入dhclient eth0后自定义配置也能观察到动态申请的过程。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/718859.html
