WiFi认证系统上线一段时间之后，最容易出现的问题不是认证失败，而是莫名其妙的"断线"和"卡顿"。用户反馈来了："连是连上了，但过一会WiFi又断了，又要重新输入验证码"。运维去查设备，CPU不高、内存够用、上联带宽也没打满，日志里也没有明显的报错——这时候就要排查那些不容易一眼看出来的因素了。

DHCP地址池耗尽是一种容易被忽略的故障模式

WiFi认证系统依赖DHCP给终端分配IP地址。一个学校的宿舍区或者一个写字楼的高峰时段，在线用户数可能比平时高出好几倍。如果DHCP地址池的容量是照着"日常在线数"来规划的，而不是照着"峰值在线数"来规划的，高峰时段就会出现地址池耗尽的情况。表现就是：终端能搜到WiFi信号但拿不到IP，或者能拿到IP但被踢掉后又分配不到新的。

还有一个容易被忽略的情况：DHCP租约时长设得太长。如果租约是24小时，一个临时访客连了一下WiFi就走了，那个IP地址还占着24小时才释放。如果一天里访客流量很大，可能到下午IP地址就不够分了。在高流动性的场景中——比如酒店大堂和会议室——DHCP租约应该设置得短一些，2到4小时就够了，确保地址能快速回收。

NAT表容量对认证系统并发能力的隐性约束

网关设备在做NAT转换的时候，每一条活跃的TCP/UDP会话都会占用一条NAT表项。一个用户连WiFi之后，手机后台几十个应用会同时发起连接——微信、邮件、推送、应用自动更新——每个连接一条NAT表项，一个用户轻松消耗上百条表项。如果网关设备的NAT表容量是一百万条，一千个活跃用户就用了十万条——看起来不多。但如果网关硬件实际能处理的并发NAT表项远小于规格书上的标称值，高并发下就会出现NAT表爆满的情况，表现就是：有些用户的网络能通、有些不通、而且是随机性的。

这个问题在项目选型阶段就要关注，不能只看厂商规格书里的"最大并发会话数"，要看第三方测试机构做的实际吞吐量测试数据，或者直接找同行的使用反馈。NAT表满载时的表现很少是整机崩溃，更多是"偶尔卡、时好时坏"，排查难度很大。

终端兼容性问题导致的假性断线

WiFi认证系统在真实环境中要面对各种各样的终端：iPhone各代、Android各品牌各版本、笔记本不同型号的无线网卡、IoT设备。不是所有终端的WiFi驱动都按照802.11标准来写的，有些终端在PMF（Protected Management Frames）开启的环境下会频繁掉线，某些笔记本网卡在802.11r快速漫游开启时认不到AP，还有一些老的IoT设备只支持802.11b/g/n。

这些终端兼容性问题，WiFi认证系统本身是解决不了的——这是无线网络层的事情。但认证系统可以做一件事：当检测到某个MAC地址在短时间内多次认证成功又断开时，把这个信息推送到运维告警里，让运维去排查是不是终端侧的问题，而不是被"WiFi坏了"的投诉淹没。

ARP表项和MAC地址表溢出的连锁反应

二层交换机的MAC地址表也是有容量上限的，企业级交换机的MAC表容量通常在几万到十几万条之间。在大型WiFi认证系统部署环境中，如果存在VLAN划分不合理、广播域过大的情况，每个交换机端口上会学到大量终端MAC地址，导致MAC表接近满载。满载之后的后果是：新出现的MAC地址无法被学习，交换机对这些MAC帧进行广播洪泛，广播流量反过来又消耗了大量上行带宽，形成一个恶性循环。

这个问题在WiFi部署中并不少见，特别是在那些AP密度高、终端流动性大、VLAN没有做精细化划分的场景里。解决思路是缩小二层广播域、做好VLAN分段、把楼层或区域按规律切分成小网段。

高并发压力下Radius服务器的会话管理

WiFi认证系统大量依赖Radius协议做AAA。在高并发场景下——比如中午12点食堂区域涌入大量员工连WiFi，或者晚上8点酒店住客集中回到房间——Radius服务器瞬间要处理大量认证请求。如果Radius服务器的并发处理能力和TCP连接池设置不合理，就会出现请求排队超时的情况。从用户体验上看，就是"明明输对了密码，但等了好几秒才提示认证成功，或者干脆超时了"。

Radius协议的底层是UDP，请求超时是家常便饭，所以客户端一般会重试。但如果重试次数太多——比如连着重试了三次——第三次还没回应，客户端就会认为服务器不可达。在高并发场景下，Radius服务器的UDP缓冲区大小和认证处理线程数的配置要提前根据预估峰值调优，不能拿默认配置上线。

WiFi认证系统的稳定运行靠的不只是产品本身的质量，还有大量部署环境里那些不太容易在规格书里看到的"隐性边界"。把这些边界摸清楚，比任何高级功能都更实际。