校园网认证计费系统跑一段时间后故障难免。有些重启就好有些需要逐步定位。以下列的是高校运维一线反馈频率最高的几类故障和排查思路。

故障一：连WiFi但打不开认证页面

所有故障里投诉最高的没有之一。学生连上学校SSID WiFi图标显示已连接浏览器打开任何页面转圈Portal死活弹不出来。

排查顺序：

第一步确认客户端是否拿到有效IP。让用户看本地配置——是不是169.254.x.x链路本地地址？（DHCP没成功）拿到正确网关了吗？（ping网关通不通？）这一步能过滤约30%伪故障其实是DHCP问题不是认证问题。

第二步检查DNS解析。客户端命令行nslookup认证Portal域名看能不能解析到正确IP。解析不到或解析到错误地址问题在DNS配置。常见原因客户端设了自定义DNS（8.8.8.8或科学工具留下的）导致强制重定向DNS hijacking没生效。解决办法ACL规则拦截公共DNS或DHCP选项强制下发校内DNS并禁止客户端修改。

第三步检查HTTP/HTTPS拦截。现在越来越多浏览器和OS默认HTTPS（HSTS预加载列表越来越大）如果HTTP强制跳转只拦80端口没处理443端口用户Chrome打开https://www.baidu.com不会被重定向到Portal。解决方案部署证书443端口也做拦截重定向或者DNS redirect绕过HTTPS限制。

第四步抓包。以上都没问题还是打不开那客户端tcpdump或Wireshark抓包。重点看：收到DHCP Offer没？DNS查询返回什么？HTTP请求目标地址响应状态码？收到302没？重定向目标URL？抓包文件几分钟内通常暴露根因。

故障二：认证成功但不能访问外网

输完密码显示"认证成功"或看到欢迎页但访问任何外网站点超时拒绝连接。比打不开Portal更让人困惑——明明通过了为什么还不能上网？

最常见两个原因：

一是NAT或路由表异常。认证网关用户通过后需将流量加入NAT转换表或开放路由策略。NAT池耗尽（公网IP不够）、路由下一跳不可达、防火墙drop规则排在permit前面都会出现"过了但过不去"。检查方法：网关上看该用户会话状态确认NAT映射存在否；traceroute外网目标地址看流量走到哪断了。

二是DNS递归问题。有些架构用户认证后被分配内网DNS由它递归解析外网域名。但这台内网DNS出了问题（进程挂了上游不可达缓存污染）用户认证成功但解不了任何外网域名等于不能上网。快速验证：让用户手动指定公网DNS（114.114.114.114）试试通了就是内网DNS的问题。

故障三：频繁掉线反复要求重认证

刷着网页突然弹出认证页面或打团战直接断线。间歇性最难定位因为随机发生等你排查它又好了。

先排除简单可能性：账号其他设备登录踢掉了？（查在线列表几个会话）达到最大在线设备数限制？（查concurrent-session配置）这两个原因就不是故障是正常策略执行。

排除了之后：

一看心跳超时配置。Keep-alive间隔和超时阈值比例至少1:3（每60秒心跳180秒超时）。太接近（55秒心跳60秒超时）稍微抖动就误判掉线。另外客户端锁屏休眠后停止发送心跳醒来发现会话被清了——正常行为但用户报告成"故障"。

二看DHCP租期和ARP老化配合。DHCP租期短（30分钟）ARP老化时间长（4小时）客户端续租获新IP后网关ARP表还保留旧IP旧MAC映射后续转发失败。建议DHCP租期设为会话超时2倍以上ARP老化与DHCP租期一致或更短。

三看无线漫游日志。特定物理位置频繁掉线可能是AP信号质量差导致客户端频繁切AP每次触发新DHCP请求和认证检查。解决方法优化该位置无线覆盖或调roaming敏感度参数。

故障四：认证响应慢或超时

早晚高峰大量学生同时认证出现响应慢甚至超时这是系统容量不足的表现。

先看认证服务器资源使用率（CPU内存磁盘I/O数据库连接数）。CPU 80%+或数据库连接池满了就是容量不够。短期缓解：加节点负载均衡清历史日志释放空间优化索引。长期评估峰值并发重新规划硬件。

再看RADIUS通信链路。后端对接LDAP/AD或其他RADIUS Server鉴权的话中间网络延迟丢包也会慢。尤其多校区场景认证服务器主校区LDAP另一个校区跨校区WAN链路质量直接影响速度。建议关键RADIUS路径持续延监控超阈值告警。

第三前端有没有瓶颈。Portal本身加载慢（大图外部JS第三方统计代码）用户体感"认证慢"跟后端没关系。优化静态资源加载减外部依赖启用压缩传输页面加载时间往往缩短一半以上。

故障五：计费数据不准

"我才用了两小时为什么扣了一天？"或者管理员日报总收入跟支付渠道实际入账对不上。计费准确性关系双方经济利益必须认真对待。

常见原因：

一时钟不同步。认证网关计费引擎数据库之间时间不一致（哪怕差几秒）跨午夜结算按时长计费就可能偏差。所有服务器配NTP同步同一可靠时间源。

二是会话结束事件丢失。正常用户主动下线或超时掉线网关向计费引擎发Accounting-Stop事件触发结算。但网关发Stop前重启或中断了事件丢了会话一直"在线"持续计费直到最大时长上限。解决方案计费引擎端"僵尸会话检测"——定期扫描长时间无心跳更新的会话强制结算关闭。

三是并发计费逻辑bug。一账号多设备在线各设备流量时长怎么算累加还是取最高值？业务逻辑有歧义或实现有bug就会混乱。上线前构造各种并发场景回归测试。