Guest SSID 集体拿不到 IP：逐层排查全对，最后"插了一下网线"就好了

某分部的访客 Wi-Fi（Guest SSID，走独立 VLAN）下午突然集体断网。这次事故最后写进报告的根因一栏，是运维最不想写的那种。

症状

• 连上 Guest SSID 的客户端全部拿到 APIPA 自配地址（169.254.x.x），没有网关——DHCP 彻底没响应；
• 从该网段 ping VLAN 网关（192.168.61.254）超时；
• 同一批 AP 上的另一个 SSID（默认网络，192.168.1.x）全程完全正常；
• UniFi 控制器里，Guest SSID 的客户端一片橙色「体验差/无连接」。

ipconfig /all 的对照非常干净：正常 SSID 的客户端拿到 192.168.1.63，故障 SSID 的客户端是 Autoconfiguration IPv4 Address 169.254.242.41——问题精确锁定在这一个 VLAN 的 DHCP 链路上。

逐层排查（然后每层都是好的）

排查的每一层都是绿的——这正是这个故障最折磨人的地方

1. AP 层：18 台 UniFi AP 全部 Online，不是 AP 挂了；
2. SSID/VLAN 配置：两个 SSID 配置完好，Guest 正确绑在 VLAN 20；
3. DHCP 服务器（防火墙）：地址池 192.168.61.20–240、租约 24h、网关 DNS 都对，地址池远没耗尽；
4. Vendor 远程复核：VLAN、防火墙、交换机、WLC 逐一过了一遍——「all are correct」；
5. 深夜重启防火墙：问题依旧。

配置层全绿、重启无效，还剩什么？

结局：物理层的玄学

第二天上午工程师到场：

• 笔记本插上交换机——VLAN 不通；
• 再插上防火墙、打开 DHCP monitor——10:05，租约突然开始发放，客户端陆续拿到地址，全部恢复。

报告里的原话：“some physical connections either plug to switch or firewall awake them to function”——某些物理连接的插拔唤醒了它们。确切机制？未知。可能是端口协商挂死、可能是 VLAN 在某台设备上的转发表异常——插拔动作触发了重新协商。问题解决了，但根因栏只能诚实地写「无法完全确定」。

教训

1. 排查要按层走，且要相信排查结果：AP → SSID → VLAN → DHCP → 物理，每层验证后就不再回头怀疑它，否则会在配置里打转到天亮；
2. 对照组是最强工具：同 AP 上另一个 SSID 正常，直接把 AP 和无线侧全部排除，范围立刻缩小一半；
3. 重启大法失效时，下一步是物理层：换端口、换线、插拔重新协商——比它更玄的答案基本不存在了；
4. 事后把这类「未解决根因」的事故写成正式报告（时间线 + 逐步排查记录 + 复发时的快速检查清单）——下次再犯，直接从第 ⑤ 步开始。