一台电脑拿不到地址，可以先看网卡；一层楼突然拿不到地址，就要同时看地址池、VLAN、中继和 DHCP 服务端。若 Windows DHCP 租约列表出现大量 BAD_ADDRESS，也不能仅凭这个词断定“有一台设备偷占了所有 IP”。它是调查入口，不是根因报告。
本文给负责企业网络的管理员一份按证据推进的排查顺序。它适用于有 DHCP 服务器、交换设备或跨 VLAN 中继的常见环境；具体设备命令和变更应以厂商、版本和授权为准。文中的排查表是公开资料整理示例，不是煜企客户现场记录。
先定影响范围，再动配置
先记下四项：什么时候开始、受影响的是一个终端还是整个网段、问题是否只在某个 VLAN、变更前有没有加过交换机/防火墙/无线控制器或改过 DHCP scope。不要一看到 BAD_ADDRESS 就批量删除租约、扩地址池或关闭冲突检测；这些动作可能掩盖仍在发生的冲突。
在受影响客户端留一份 ipconfig /all；在 DHCP 服务器留对应 scope 的可用地址数、租约状态和审计日志时间；在交换设备留该 VLAN 的中继/IP Helper 配置与最近变更时间。三侧时间线对齐，才能区分“没有收到请求”“有请求但不分配”和“分配后被拒绝”。微软的 DHCP 故障排查指南把客户端、服务端和跨网段 relay 分开检查，也建议在必要时按 DHCP 报文序列定位丢包点。
按症状查：先看哪一段，留下什么证据
以下是可复制的通用排查顺序，不是五种固定“故障码”。同一症状可能有不同原因。
同网段只有少数终端拿不到地址
先查：网卡状态、接入口/VLAN、DHCP Client 服务，以及服务器 scope 是否还有可租地址。证据：受影响客户端的 ipconfig /all、事件日志和 scope 统计。下一步：先排除单机或局部接入口，再扩大到服务器。
整个跨网段 VLAN 都拿不到地址
先查：该 VLAN 的 DHCP relay/IP Helper、网关和中间设备。证据：变更前后配置、网关地址，以及请求是否到达 DHCP 服务器。下一步：区分请求路径中断与服务端拒绝租约。
租约列表出现 BAD_ADDRESS
先查：静态地址是否落入动态池、重复地址、冲突检测和相关日志。证据：标记的 IP、MAC、审计日志时间和设备归属。下一步：按实际占用和检测机制找原因，不先清空条目。
服务器发出 OFFER，客户端仍没拿到地址
先查：回程丢包、DHCP snooping、DAI 或其他中间设备行为。证据：客户端与服务器在同一时间抓包，核对 DISCOVER→OFFER→REQUEST→ACK 哪一步消失。下一步：只在获授权的维护窗口定位设备侧配置和转发路径。
地址有了，但主机名仍解析错
先查：DNS 动态更新与旧 A/PTR 记录。证据：租约时间、DNS 记录和更新主体。下一步：把它作为 DNS 后续分支，不要误判为 DHCP 未分配。
例如微软的 Event ID 4199 说明指出，客户端的地址冲突判断也可能和设备侧 ARP probe/检查时序有关。看到冲突事件，仍要对上时间、MAC 和链路位置。
BAD_ADDRESS 的三条核对线
第一条是地址规划：打印机、网关、服务器或手工配置的终端是否用了动态池里的地址？静态地址不能落入 DHCP 动态分配范围；可以通过不重叠的地址规划或 DHCP 排除项明确边界，不能靠“平时没碰到”来保证不会冲突。
第二条是 DHCP 来源：局域网里是否只有预期的 DHCP 服务在响应？交换机、防火墙、无线路由设备可能自带 DHCP 功能，但不能靠“扫描没看到”就宣布不存在。需要在受影响网段的真实租约过程里看谁发送 OFFER。
第三条是冲突检测本身：日志标的是哪个地址、时间和 MAC？只有在现场证据指出检测机制误报或设备互相干扰时，才进入相关设备的配置核对。不要为了让告警消失就关闭 DHCP 冲突检测或 DAI。微软官方指南也列出 DHCP snooping、DAI 和中继等中间设备作为排查范围；这不是建议一律停用它们。
什么时候需要抓包，什么时候先停手
如果客户端日志、scope 和中继配置看起来都正常，但租约依然失败，可以在获授权的维护窗口做客户端与服务器两端同步抓包。用同一请求的事务 ID 对齐：客户端有 DISCOVER、服务器没有，优先查上行；服务器已发 OFFER、客户端没看到，优先查回程与中间设备。这个判断框架来自微软的 DHCP 报文排查步骤。
若问题随交换机、VLAN、relay 或网关变更而扩大，先保留变更前后配置与回退条件，不要边猜边改多个位置。若要改动生产网络，必须让有权限的管理员确认影响范围、维护窗口和恢复路径。没有真实配置、日志与现场拓扑，本文不能替代诊断，也不提供盲改命令。
煜企能接哪一段
煜企的网络设备与交换路由服务覆盖交换机、路由器、网关与链路关系，地址/VLAN/路由配置基线，以及割接、连通性验证和回退条件。如果你的问题已经落在 DHCP relay、VLAN 关系或设备变更后的网络验证，可以带上“影响范围—三侧日志—变更记录—回退条件”这份排查表，再沟通具体诊断范围。这里不承诺所有冲突都由网络设备造成，也不承诺固定恢复时长。
资料来源与边界
- Microsoft：DHCP troubleshooting guidance：客户端、服务端、relay、
BAD_ADDRESS与双端抓包排查框架。 - Microsoft：Event ID 4199 and DHCP conflict detection：冲突检测与设备侧 ARP 行为的特定机制，不代表所有事件同因。
- Cisco：Troubleshoot DHCP in Enterprise Networks：厂商侧企业网络排障参考；命令仅适用于相应平台和版本。
公开问题样本包括 Microsoft Q&A：BAD_ADDRESS 耗尽地址池 与 另一例持续 DHCP 冲突排查。它们证明有人遇到过此类问题，不证明搜索量、行业普遍性或煜企已完成同类现场交付。Microsoft Q&A 仅用于证明公开用户问题存在；问答中的回答来自社区或独立回答者，不等同于 Microsoft 官方技术结论。技术判断以 Microsoft 官方 DHCP 文档为准。本文是排查顺序与证据模板，不是客户案例、设备实测或维修保证。