WiFi断连总反复？一个真实的网络事件处理流程示例

上周三下午，某连锁咖啡店的店长在微信里急匆匆发来截图：3台POS机全掉线，手机连不上WiFi，客人扫码付款失败。这不是故障报警，是现场正在发生的“服务中断”。

事情是怎么一步步理清楚的？

我们没先重启路由器，也没一上来就查日志。而是按实际操作顺序走了一遍：

1. 确认影响范围：仅该店2楼西区信号弱，1楼和隔壁店正常 → 排除出口带宽问题；
2. 用手机WiFi分析仪扫频，发现2.4G频段信道11被隔壁3个路由器重度占用，同频干扰严重；
3. 检查AP设备：该区域挂载的是老款吸顶AP，固件停留在2021年版本，不支持自动信道避让；
4. 临时处置：手动将AP切换至信道1，5分钟内POS恢复联网；
5. 根因闭环：次日更换为支持DFS+智能射频的新型AP，并开启定时信道扫描策略。

这个流程不是模板，是现场写出来的

很多团队喜欢套用“监测-定位-处置-复盘”四步法，但真实场景里，步骤经常交叉甚至倒置。比如这次，客户报障时我们同步做了两件事：一边让店员拍现场AP指示灯状态（绿灯常亮，排除断电），一边远程登录AC平台看在线终端数（从87掉到12）——这两个动作同时发生，不是先后关系。

附：一线工程师常用排查指令片段（AC平台SSH下）

show ap-name coffee-west status
show wlan ssid coffee-guest client-count
show ap-name coffee-west interference 2.4g
ap-name coffee-west channel 1

注意：interference 2.4g这行命令不是所有AC都支持，老版本得靠外接频谱仪。工具是死的，人得知道什么时候换路子。

现在那家店2楼西区的WiFi信号强度稳定在-58dBm，信噪比从12dB升到31dB。客人再没因为连不上网而放弃点单。