Windows客户端DHCP获取失败时，应按“客户端→物理链路→交换机/中继→服务器”顺序排查：先确认DHCP启用状态、APIPA地址、强制续租结果及IPv6干扰；再检查网卡指示灯、ping网关、arp表和Wireshark抓包验证二层广播通断；接着核查dhcp snooping信任端口、中继配置、防火墙UDP 67/68拦截及无线隔离策略；最后验证服务器作用域启用状态、地址池余量、监听网卡及事件日志错误。
当windows客户端无法获取dhcp地址时，核心思路是“从本机出发，逐层验证dhcp通信链路是否畅通”。重点检查客户端配置、网络连通性、中间设备（如交换机/防火墙）策略以及服务端状态。
检查客户端基础状态与本地配置
先确认客户端是否真正处于DHCP模式，并排除本地缓存或残留配置干扰：
- 运行 ipconfig /all，查看“DHCP已启用”是否为“是”，且IPv4地址是否为169.254.x.x（APIPA地址），这说明DHCP发现阶段失败
- 执行 ipconfig /release && ipconfig /renew 强制重试；若提示“无法联系DHCP服务器”，说明客户端发不出Discover或收不到Offer
- 检查是否误启用了“Internet协议版本6 (TCP/IPv6)”的自动配置并干扰了v4流程（可临时禁用IPv6测试）
- 确认系统时间偏差未超5分钟（Kerberos环境下的DHCP认证可能因此失败）
验证物理与数据链路层连通性
DHCP依赖二层广播，任何中断都会导致Discover包无法送达：
- 观察网卡指示灯是否正常，ping 默认网关IP（若已知）或同网段其他主机，不通则排查网线、端口、VLAN划分、STP阻塞等
- 在客户端执行 arp -a，看是否有网关或DHCP服务器的MAC条目；若空，说明L2通信异常
- 用 Wireshark 过滤 bootp || dhcp，确认是否发出DHCPDISCOVER（目标MAC为ff:ff:ff:ff:ff:ff），且无DHCPOFFER返回——这是定位问题层级的关键证据
排查中间网络设备限制
交换机、路由器或安全设备常默认过滤DHCP广播或限制中继行为：
- 接入交换机端口是否开启 dhcp snooping？若开启，需确保上联口设为trusted，且客户端口在合法VLAN内
- 跨网段场景下，检查DHCP中继（ip helper-address）是否配置在三层接口，且指向正确的DHCP服务器IP
- 防火墙或终端防护软件（如某些EDR）可能拦截UDP 67/68端口流量，临时禁用测试
- 无线网络中，确认AP或AC未启用“DHCP隔离”或“客户端隔离”策略
快速验证DHCP服务器侧状态
不依赖日志也能做基础判断：
- 在DHCP服务器上运行 Get-DhcpServerv4Scope（PowerShell）或打开DHCP管理器，确认作用域已启用、地址池未耗尽、且排除范围未误圈走可用IP
- 检查服务器是否绑定到正确网卡（多网卡环境易选错监听接口）
- 用另一台已知正常的客户端在同一网段测试，若也失败，基本可定位为服务端或网络问题；若仅故障机不行，聚焦该机策略或驱动
- 查看服务器事件查看器中“DHCP Server”日志，筛选错误级别事件（如ID 1046表示拒绝请求，常因策略或策略冲突）
实际排查时建议按“客户端→物理链路→交换机/中继→服务器”顺序推进，每步用最小动作验证。多数问题集中在客户端网卡驱动异常、交换机端口VLAN错配或DHCP Snooping未信任上联口这三类。
