办公电脑连上交换机后一直转圈，最终得到169.254地址；同一台电脑搬到另一个楼层又正常。跨VLAN获取地址时，客户端广播不会自动穿过路由器，需要DHCP Relay把请求送到正确服务器。
DHCP分配经过哪些报文
- 客户端广播Discover寻找服务器；
- 服务器返回Offer提供候选地址与网络参数；
- 客户端发送Request选择地址；
- 服务器通过ACK确认租约，或以NAK拒绝无效请求。
故障可能发生在任何一程。只看到Discover不代表服务器已经选到地址池，只看到Offer也不代表客户端收到并接受。
Relay怎样帮助服务器选池
中继把客户端广播转换为可路由请求，并在报文中提供中继接口相关信息。服务器通常依据giaddr或策略选择对应子网的地址池。中继接口地址、VRF或源选择错误，服务器可能选错池或找不到可用范围。
HTTP代理在这里没有作用
客户端尚未获得正常IP、网关和DNS时，浏览器HTTP代理无法参与。DHCP使用独立的UDP流程。把代理地址填进操作系统不会修复Discover或Offer丢失，反而可能让后续网页测试更加混乱。
服务器收到请求却不回应
查看服务器日志是否显示无匹配作用域、地址池耗尽、策略拒绝、服务未授权或租约数据库异常。不能只用“DHCP服务正在运行”判断。还要确认请求中的中继地址、客户端标识、MAC和Option 82是否符合策略。
Option 82为何会改变结果
网络设备可插入Relay Agent Information，用于标识接入端口或线路。服务器若要求特定Circuit ID或Remote ID，而中继没有插入、格式改变或多级中继重复处理，就可能拒绝。该信息也属于网络资产数据，应限制日志访问。
应答如何返回客户端
服务器将响应发给中继，再由中继送回客户端VLAN。去程可达但回程路由、ACL或VRF不对，仍会表现为客户端收不到Offer。应同时查看中继计数、服务器响应和客户端侧报文，不能只测试服务器端口。
地址池有空闲为何仍失败
空闲地址可能位于另一个作用域；排除范围过大、保留地址、冲突检测或租期策略也会减少实际可用数。高峰期要监控使用率和分配失败，而不是等到池完全耗尽才扩容。
双DHCP冲突的现象
未经协调的服务器可能同时发Offer，客户端随机选择，导致错误网关、DNS或重复地址。使用受支持的Failover或Split Scope设计，并通过DHCP Snooping限制非授权服务器。不要仅靠关闭一台服务器临时“治好”而不查来源。
PXE为何也受Relay影响
网络启动既需要地址租约，也可能需要额外的引导服务器信息或ProxyDHCP。相关边界可参考PXE的DHCP、TFTP与UEFI排查，不要把PXE选项直接混进所有办公终端地址池。
推荐排查顺序
- 确认客户端物理端口、VLAN和三层网关接口；
- 核对Relay目标地址、VRF、giaddr与Option 82；
- 在服务器确认请求到达并命中正确地址池；
- 检查Offer/ACK返回、中继转发和客户端接收；
- 核对池容量、排除、租约与高可用状态；
- 排查未授权DHCP服务器和错误静态地址。
结论
DHCP Relay故障不是一个代理参数问题。按客户端广播、中继封装、服务器选池和应答回程四步核对，才能找到是VLAN、中继地址、地址池还是策略造成客户端拿不到IP。
