某年十月，一所高校的信息科突然收到大量学生投诉：宿舍WiFi能连上，但浏览器打开任何网页都跳到认证页面，输入用户名密码之后提示"认证成功"，但刷新页面还是跳认证。这个现象在全校多栋宿舍楼同时出现，持续了大约四十分钟才恢复正常。信息科事后对这次故障做了完整的排查和复盘，里面涉及的一些思路值得记录下来。

故障现象的精确描述很重要

这件事的第一个教训是：收到"WiFi不能用"的投诉时，不要急着去重启设备，先把现象说清楚。"WiFi连不上"和"WiFi连上了但上不了网"是两件完全不同的事情，后者又可以细分为"DNS解析失败"、"HTTP请求无响应"、"被重定向到认证页"三种完全不同的情况，对应的排查方向完全不同。

那次故障的现象被精确描述为：无线连接正常（手机显示WiFi已连接、IP地址正确）、认证页面能打开（说明DNS解析和基本HTTP是通的）、认证操作有响应（说明认证服务器在线）、但认证后仍然被重定向（说明会话状态没有正确写入）。这四条合在一起，把问题的定位范围从"网络层"直接缩小到了"认证系统的会话管理"。

排查过程的逻辑推进

基于上面的现象描述，信息科工程师开始按优先级逐一排查可能的原因。

首先检查认证服务器的状态。登录认证网关管理页，看到认证服务的进程在运行，RADIUS端口在监听，CPU和内存使用率正常。初步排除"认证服务挂了"的可能性。

然后检查认证服务器的日志。在认证日志里，可以看到大量认证请求，请求的结果字段显示"Access-Accept"——意味着RADIUS服务器在告诉认证网关"这个用户认证通过了"。但是学生在Portal页面输完密码之后，系统没有执行"放行这个用户的流量"这个动作。

这个现象说明：RADIUS认证本身是成功的，但认证成功之后的"放行动作"没有被执行。认证成功和流量放行是两个独立的步骤，在校园网WiFi网络计费系统的架构里，前者由RADIUS处理，后者由认证网关（通常是策略下发到AC或者防火墙）处理。问题在两者之间的衔接环节。

进一步检查认证网关的会话表。发现会话表里的记录数量在短时间内增长了很多，接近系统设定的上限。会话表满了之后，新的认证成功请求无法写入新的会话记录，导致认证通过但用户流量仍然被拦截。

根因：会话表上限设置得太低

最终的根因定位是：认证网关的会话表上限被设置成了20000条，而当天因为某个活动（学校新生运动会），多栋宿舍楼的学生同时在线，会话总数超过了这个上限。

20000这个数字是设备出厂的默认值，没有人在项目上线的时候专门去核对过这个参数是否适合这所学校的规模。这所学校有在校生23000人，如果宿舍区在线率达到80%以上，光宿舍区的会话数就接近20000条，再加上教学区和其他区域的在线用户，超限是迟早的事。

更隐患的地方是：这个会话表的上限在管理界面里有显示，但没有配置告警阈值——也就是说，在会话数接近上限的时候，系统没有任何告警，信息科不知道有这个风险。只有等到用户投诉了，才能发现问题。

修复和改进措施

当天的临时修复是把会话表上限调到50000条，并手动清理了一批长时间未活跃的僵尸会话。四十分钟后服务恢复正常。

事后的改进措施分了三个方向。第一是参数复查：对校园网WiFi网络计费系统里所有关键的容量参数做了一次系统性梳理，包括会话表上限、RADIUS并发连接数、计费数据库连接池大小、日志写入队列长度等，逐一核对设定值是否与学校实际规模匹配。发现有好几个参数都是用的默认值，与学校实际情况不符。

第二是监控补盲：在监控系统里新增了几个关键指标的告警规则，包括会话表使用率超过70%告警、RADIUS每秒请求量超过阈值告警、认证失败率超过5%告警。这些告警在事前没有配的原因是"默认监控模板里没有这几项"，事后专门补上了。

第三是压测复盘：在暑假期间做了一次模拟开学季的压测，把并发认证数推到3000次/分钟，观察系统的瓶颈在哪里。这次压测又发现了另一个隐患——RADIUS数据库在高并发下的锁等待问题，事后通过优化索引和引入查询缓存来解决。

几条值得记住的经验

这次故障排查的过程里，有几条经验在后来的项目里被反复提起。

一是容量参数不能用默认值。设备或系统的默认参数是厂商给"一般场景"配的，不是给你的具体环境配的。上线前要做一个容量规划的专项检查，把所有跟并发、存储上限相关的参数都过一遍，对比学校的实际规模和峰值预期来调整。

二是告警盲区是故障的温床。没有告警的系统，出了问题只能靠用户投诉来发现，响应时间取决于"学生被骚扰到了才去反映"。把关键指标的告警阈值配好，是运维的基础设施，不是可选项。

三是故障复盘要做深。这次故障的直接原因是会话表满了，但更深层的原因是项目上线时没有做系统性的容量参数核查。如果复盘只停在"调大参数就解决了"，类似的问题会在其他参数上重演。