为什么要分层排查
无线故障的表象高度相似：连不上、慢、掉线，但成因可能分布在供电、射频、关联、网络与应用完全不同层面。分层模型的价值在于给出固定的检查顺序：从最底层的供电与物理链路开始，向上依次确认射频质量、关联与认证、地址与网关、DNS 与应用。每一层都要拿到证据再进入下一层，避免在射频层还没确认的时候就去重装网卡驱动这类无效操作。
五层模型
| 第一层 物理 | AP 供电（PoE 或电源）、网线、指示灯与端口状态 |
|---|---|
| 第二层 射频 | RSSI 与 SNR、信道利用率、噪声底与干扰源 |
| 第三层 关联 | 扫描、关联、认证、密钥握手是否完成 |
| 第四层 网络 | IP 地址、VLAN、网关可达性、上联链路 |
| 第五层 应用 | DNS 解析、Portal 认证、业务系统返回 |
逐层验证顺序
逐层验证顺序
1. AP 是否在线（控制器、SSH 或指示灯）
2. 目标位置 RSSI 不低于 -67dBm 且 SNR 不低于 25dB
3. 终端能否完成关联与认证（事件日志看卡在哪一步）
4. 拿到正确网段 IP，能 ping 通网关
5. DNS 解析与业务返回码正常
# 上一层未确认前，不要跳到下一层做操作每层的关键证据
| 层级 | 关键证据 | 常用手段 |
|---|---|---|
| 物理 | 端口供电状态、AP 上电记录 | 交换机面板、控制器告警 |
| 射频 | RSSI、SNR、信道利用率、重传率 | 控制器射频统计、扫频工具 |
| 关联 | 失败阶段与原因码 | 终端连接日志、AP 关联记录、抓包 |
| 网络 | 地址是否获取、网关是否可达 | ipconfig、ping、DHCP 日志 |
| 应用 | 解析是否成功、返回码是否正常 | nslookup、业务客户端日志 |
典型使用场景
- 用户报障时的标准处置流程
- 新点位验收：逐层确认覆盖与连通性
- 间歇性问题复现：定位证据缺失在哪一层
- 多人协同时的分工依据：射频、网络与应用各有人负责
- 复盘与归档：把根因归到具体层级便于统计
分层排查的纪律
三条纪律。第一，先取证再动手：重启与复位会清掉现场证据，重启前先保存日志、当前状态与抓包。第二，一次只改一个变量：同时调信道、功率与带宽后，无法判断哪一项起了作用。第三，把结论落到层级上记录，例如「二层射频覆盖不足」而不是「信号不好」；只有归到层级，才能形成可复用的经验，也才能在同类故障再次出现时快速对照。这三条纪律比任何具体命令都更能提升排障效率。
「先重启再说」会把现场证据清掉：复位前尽量先收集日志与当前状态截图。
分层模型同样适用于验收：覆盖、关联、地址、应用四个环节各自留一份基线数据，后续对比才有依据。