WiFi认证系统运行过程中，有一种故障现象很让人头疼：同一层楼里，有人能正常上网，有人怎么都连不上。检查信号强度没问题，Radius服务器正常，Portal页面也能打开，但某些区域的认证就是失败。排除了一圈，最后发现是AP负载不均导致部分AP上连接的设备过多，认证处理不过来。这种问题不是硬件故障，而是容量规划和负载策略的问题，排查时要有系统性的思路。

AP负载不均是怎么形成的

无线终端选择AP时，通常基于信号强度做决定。但在高密度场景下，所有终端都倾向于连到信号最好的那个AP，结果这个AP被挤爆，周围其他AP却空闲。比如会议室、食堂、报告厅这种人员密集区域，AP负载经常出现严重不均衡。如果认证请求集中涌向几个热点AP，这些AP的CPU、内存、并发连接数都会达到上限，新的认证请求就会被丢弃或延迟处理。

有些场景下，AP负载不均还和终端粘性有关。一个终端连上AP1后，即使走到AP2附近，信号已经变弱，也不愿意切换。因为终端切换AP需要重新认证或重新关联，很多终端为了避免中断，会保持原连接。结果AP1一直扛着远距离的终端，AP2附近的新用户又连不上。 终端粘性连接问题是高密度WiFi的经典难题。

认证失败和AP负载的关联

AP负载高的时候，认证失败通常表现为几种形态。一种是终端连接WiFi后无法获取IP地址，因为AP上的DHCP中继已经被压垮。一种是Portal页面打不开或跳转异常，因为AP上的HTTP服务或重定向服务响应变慢。还有一种是Radius请求超时，因为AP或AC把认证请求发到Radius后，Radius还没来得及响应，AP就已经放弃等待。这些问题的共同点是：不是Radius本身慢，而是AP侧处理不及时导致请求中断。

排查时可以先看AP的在线用户数、CPU利用率、内存占用。如果发现某个AP用户数明显偏高，或者CPU长时间接近100%，就要重点检查这个AP。同时要看周围AP的负载情况，确认是否是不均衡导致。很多无线管理系统有热力图和负载均衡统计，可以直接查看。

负载均衡策略的几种做法

解决AP负载不均，最常见的方法是配置负载均衡。负载均衡策略可以基于用户数、流量、信号强度、频段等综合判断。AC会根据这些策略，把新接入的终端引导到负载较轻的AP。但负载均衡策略不能一刀切，配置太激进会导致终端频繁切换，反而影响体验。配置太保守又起不到作用。

频段引导也是一种常用手段。5GHz频段信道更多、干扰更少、容量更大，2.4GHz频段覆盖广但容量小。如果双频终端都挤在2.4GHz上，认证压力会很大。通过策略引导双频终端优先使用5GHz，可以缓解2.4GHz的拥塞。但老旧终端只支持2.4GHz，不能一刀切拒绝接入。

在高密度场景下，如果单个AP的容量确实不够，就需要增加AP密度。增加AP的同时要注意信道规划，避免AP之间互相干扰。相邻AP使用相同或相邻信道会互相干扰，实际容量反而下降。合理的信道规划是无线网络容量扩展的前提。

排查时的数据抓手

排查AP负载不均导致的认证失败，要有几个关键数据。第一是AP实时在线用户数分布，第二是各AP的CPU和内存利用率，第三是终端接入和离开AP的历史记录，第四是认证失败的时间分布和位置分布。把这些数据叠加起来，就能看出问题区域。比如每天上午8点到9点，食堂区域大量认证失败，其他区域正常，就很可能是食堂AP容量不足。

WiFi认证系统的稳定性很大程度上取决于无线网络的规划质量。AP部署不是把设备装上墙就完事，负载均衡、频段引导、信道规划、容量预留都要提前考虑。认证失败不一定都是认证系统的问题，有时候根源在AP负载上。排查时把视野放宽，才能找到真正的症结。