探测请求风暴是什么
终端为了发现网络会主动发送 Probe Request（探测请求），正常情况下频率不高。当某类终端或某个故障设备以极高频率反复扫描时，大量管理帧会持续占用空口，同时抬高 AP 管理面的处理负担，表现为整体时延抖动、吞吐下降，而信号指标看起来并不差。
来源与缓解思路
常见来源是驱动异常的终端、后台频繁扫描的应用，以及不支持 802.11k 引导、只能做全信道扫描的物联网设备。缓解要两头做：在终端侧定位并处理异常设备，在网络侧用 11k/11v 引导减少全信道扫描，部分控制器的探测请求限速功能可以作为兜底。
基本信息
| 识别方式 | 监听模式抓包统计每秒 Probe Request 数量与来源 MAC |
|---|---|
| 常见来源 | 故障终端驱动、扫描类应用、低功耗 IoT 设备 |
| 影响 | 占用空口时间、抬升 AP 管理面 CPU、增加时延抖动 |
| 网络侧缓解 | 启用 11k/11v 引导，减少终端全信道扫描；必要时用探测限速 |
| 终端侧缓解 | 定位异常设备，更新驱动或更换设备 |
观察方法
观察方法
# 监听模式抓包，过滤 Probe Request
wlan.fc.type_subtype == 0x04
# 按源 MAC 统计发送速率，找出异常终端
# 与同一时段的信道利用率对照，确认影响量级现象与判据
| 现象 | 判据 | 结论 |
|---|---|---|
| 整体慢但信号好 | 信道利用率高、Probe 帧占比异常 | 管理帧占用空口 |
| AP CPU 偏高 | 管理面负载上升 | 大量探测请求需 AP 响应 |
| 固定终端周边变差 | 该终端 Probe 速率远高于其他 | 单个设备刷探测 |
典型使用场景
- 办公区整体变慢但排查无干扰：用抓包统计确认管理帧占比
- IoT 设备批量接入后体验下降：检查设备扫描行为
- 某工位周边异常：定位该位置附近的异常终端
- 评估 11k/11v 启用效果：对比启用前后探测请求数量
- 定位「幽灵」终端：找出电波存在但不上线的设备
- 容量规划验证：确认管理帧以外的空口开销是否被低估
个别故障设备持续刷探测就能明显拖累整个信道，定位办法是先抓包锁定来源 MAC，再针对该设备处理。