访客 WiFi 连不上网，配置查了个遍全是对的——最后靠"拔一下"解决
同一套无线网络里有两个 SSID：员工日常使用的默认网络，和给访客用的独立访客网络。某天访客网络的用户开始反映连不上网，而员工网络全程正常——这种”两个网络共享同一套硬件，只有一个出问题”的情况，天然带有一个现成的排查参照物：能正常工作的那个网络，就是最好的对比基准。
症状：典型的 DHCP 失败
访客网络的客户端设备，ipconfig /all 显示的是 APIPA 自动分配地址（169.254.x.x），没有默认网关——这是 Windows 在始终收不到 DHCP 服务器响应时的保底行为，等同于明确告诉你：DHCP 请求发出去了，但没有收到回应。
排查：从接入点，到控制器，到防火墙，逐层对照
- 基准测试：在能正常工作的默认网络上跑一次
ipconfig /all，确认它拿到的是网段内的合法地址——排除”网络基础设施整体故障”的可能，问题被锁定在访客网络这一条链路上； - 检查接入点：登录无线控制器后台，涉及的全部接入点都显示在线，没有掉线或不可达的情况——排除接入点故障；
- 检查客户端连接状态：控制器里能看到访客网络下多个客户端处于”信号差/无法连接”状态，符合 DHCP 分配失败的表现，但这只是症状的进一步确认，不是根因；
- 检查 SSID 配置：无线控制器里两个 SSID 的配置（网络类型、接入点绑定）都正确无误——排除 SSID 层面的配置错误，把排查焦点转向防火墙上的 DHCP 服务；
- 检查防火墙 DHCP 服务器配置：访客网络对应的 VLAN 接口和 DHCP 服务器设置（地址池范围、子网掩码、网关、租期）逐项核对，全部正确，地址池也没有耗尽。
配置层面挨个核对，全部”正确”，但网络依然不通——这本身就是一种排查结果
转折：重启不解决问题，物理插拔解决了问题
在配置层面找不到问题的情况下，先尝试了一次远程重启防火墙——重启后症状依旧，说明问题不是那种”重启就能刷新掉”的临时状态异常。第二天技术员到现场，直接物理接触防火墙和交换机：插入交换机端口时无法访问对应 VLAN，转而直接接入防火墙、登录 DHCP 监控页面，这时才发现 IP 地址租约在这次插拔操作之后开始正常发放。后续复盘认为，某些物理连接（交换机口或防火墙口）本身需要被重新触发（拔插）才能”唤醒”其正常工作状态——具体是哪个物理层面的元件出了问题，已经无法在事后确认，但插拔本身确实解决了问题。
教训
- 有对照基准的排查，比凭空排查快得多——本例中”同样的硬件，一个 SSID 正常、一个不正常”这个前提，直接把嫌疑范围从”整个网络”缩小到”这一个 SSID 专属的那部分配置”，大幅减少了排查路径；
- 逐层验证”配置正确”依然可能查不出根因——接入点、SSID、DHCP 服务器配置层层核对都没问题，说明问题可能根本不在配置层，而在更底层的物理连接或硬件状态，这类问题在纯软件排查里是查不出来的；
- 不是所有故障都有一个能被清楚解释的根因——这次的解决方式是”插拔线缆”，而不是”改了某个具体设置”，遇到配置层面查无所获、但物理层面的操作确实能解决问题的情况，记录下”做了什么让它好了”，比执着于找到一个完美解释更实际。