先检查客户端是否获取到169.254.x.x地址：有则说明DHCP失败启用APIPA，问题在通信或配置；没有则可能网卡未发请求或物理断开。
客户端无法从 windows server 的 dhcp 服务器获取 ip，通常不是单一环节出问题，而是涉及客户端、网络通路、dhcp 服务本身及作用域配置四个层面。排查需按逻辑顺序逐层验证，避免盲目重启服务或重装角色。
检查客户端基础网络状态
先确认客户端是否具备发起 DHCP 请求的基本条件：
- 网卡已启用且物理连接正常（指示灯亮、交换机端口无错包）
- IP 配置为“自动获得 IP 地址”（即 DHCP 模式），未被手动设为静态或保留了错误的旧地址
- 运行 ipconfig /release && ipconfig /renew 强制刷新；若提示“无法联系 DHCP 服务器”，说明请求未送达或未响应
- 在客户端执行 ipconfig /all，观察是否出现“DHCP 已启用”但“IPv4 地址”仍为 169.254.x.x（APIPA 地址），这是未收到响应的典型标志
验证客户端与 DHCP 服务器之间的可达性
DHCP 使用 UDP 67/68 端口，不依赖 IP 层连通性，但中间设备（如路由器、防火墙、三层交换机）可能拦截或转发异常：
直播间话术巡检-windows
下载
直播话术巡检系统(Windows版) — 实时语音转写、关键词检测、场景自动切换、告警推送、大屏可视化。支持 Windows VB-Cable 虚拟声卡音频采集，阿里云 ASR 实时识别。一键启动脚本，自动安装环境。
- 若客户端与 DHCP 服务器不在同一子网，确认中继代理（DHCP Relay Agent）已正确配置：在路由器或 Windows Server 的“远程访问”角色中启用，并指向正确的 DHCP 服务器 IP
- 检查交换机端口是否启用了 DHCP Snooping（尤其在企业环境），若启用但未将上联口设为 Trusted，则会丢弃 DHCP Discover 包
- 临时关闭客户端和服务器上的 Windows 防火墙（或添加入站规则允许 UDP 67/68），排除本地策略拦截
确认 DHCP 服务运行状态与作用域有效性
即使服务显示“正在运行”，也可能因配置错误导致实际不响应请求：
- 打开“DHCP 控制台” → 展开服务器 → 查看“作用域”节点：确保至少有一个作用域处于“已激活”状态（右键菜单中无灰色“激活”项）
- 双击作用域 → “地址池”：确认起始/结束 IP 在合理范围内，且未被全部分配完（查看“地址租约”中已分配数量）
- 检查“筛选器”：若启用了“拒绝”列表，确认客户端 MAC 地址未被意外加入；“允许”列表启用时，需确保客户端 MAC 已明确添加
- 查看 Windows 事件查看器 → “应用程序和服务日志” → “Microsoft” → “Windows” → “DHCP-Server”：重点关注错误事件 ID 1046（服务启动失败）、1056（作用域未激活）、1058（数据库损坏）
抓包定位协议交互断点
当以上步骤均无明显异常，建议在客户端或服务器侧抓包，直接观察 DHCP 四步流程（Discover → Offer → Request → Ack）是否完整：
- 在客户端用 Wireshark 过滤 bootp 或 udp.port == 68，释放并续订后观察是否有 Discover 发出、是否有 Offer 返回
- 若客户端发出 Discover 但无 Offer，问题大概率在服务器侧（服务未监听、作用域失效、ACL 阻断）；若收到 Offer 但无 Ack，可能是客户端拒绝（如地址冲突检测失败）或服务器租约校验失败（时间不同步、数据库异常）
- 注意：Windows Server 自带的“网络监视器”（Netmon）已弃用，推荐使用 Wireshark 或 PowerShell 的 Get-NetAdapter | Get-NetIPAddress 辅助判断接口绑定情况
