网络WiFi认证系统上线之后，故事才真正开始。上线头三个月，各种意料之外的状况会轮番上演：有人反映Portal页面白屏，有人投诉验证码收不到，有人发现凌晨三点认证记录里出现大量失败重试。系统不出问题靠设计，出了问题能不能快速定位靠运维。这套系统的运维有其独特性，它不是纯粹的服务器运维，也不是纯粹的网络运维，而是处在网络和应用的交叉地带，故障根因可能在AC的配置里，可能在Radius服务的进程里，也可能在运营商的短信通道里。

日常运维的第一条线是监控体系建设。认证系统的核心指标就那么几个：认证成功率、平均认证时延、并发请求数、RADIUS服务响应时间、短信通道送达率。这些指标需要实时采集、可视化展示、设置告警阈值。认证成功率低于百分之九十五持续超过五分钟，自动推送告警。平均认证时延超过三秒，自动触发排查流程。这些阈值不是拍脑袋定的，而是根据业务场景反复调出来的。商场场景用户对WiFi连接速度的容忍度远低于校园场景，商场WiFi认证页面加载超过三秒就有用户关掉页面改用流量，所以商场的告警阈值要比校园更敏感。

性能监控之外，硬件资源同样需要盯住。RADIUS服务器的CPU使用率在高峰时段跑到百分之八十以上就要预警，百分之九十以上就要考虑横向扩容。内存泄漏是所有长期运行服务都可能遇到的问题，认证系统也不例外，需要关注内存使用率的长期趋势曲线，稳定增长但从不回落，大概率是内存泄漏，需要升级补丁或者定期重启服务。

第二条线是账号生命周期管理。校园和企业的WiFi账号不能是静态的。学生毕业了，账号应该自动注销。员工离职了，账号应该立即禁用。访客账号用了一次之后，三天不活跃就应该自动清理。把这些账号管理逻辑写成自动化脚本，比靠人手工维护可靠得多。手工管理账号的问题不在于人会犯错，而在于人会忘。一个离职三个月的员工的WiFi账号还在系统里活跃着，这在安全审计中是典型的扣分项。把账号管理对接上HR系统的离职流程，或者教务系统的学籍状态变更流程，做到账号跟着人事变动自动流转，才算是把这块踩实了。

第三条线是故障排查能力。运维最怕的不是已知的故障，而是用户报上来的问题无法复现。用户说连不上WiFi，你到现场用自己的手机一连就上去了，这种情况在WiFi认证运维中比想象中常见得多。根本原因通常是终端侧的差异：某些安卓机型的WebView内核版本过低，无法正常渲染Portal页面；某些笔记本的无线网卡驱动有兼容性问题，导致802.1X证书校验失败；某些安全软件把所有HTTP重定向都当成中间人攻击给拦截了。把这些终端侧的问题整理成一个知识库，下次遇到同样的机型直接给出解决方案，比每次都从头排查效率高得多。

常见故障的排查路径需要形成标准流程。用户反馈无法打开认证页面，第一步让用户检查是否获取到了IP地址，如果分配到了169.254开头的自动配置地址，说明DHCP没拿到正确的IP，问题在AP或者DHCP服务器。如果有正常IP但打不开页面，第二步排查AC的Portal重定向规则是否配置正确，是否启用了HTTPS跳转。HTTPS跳转在技术原理上是矛盾的：HTTPS的设计目标就是防止中间人篡改，而Portal认证恰恰需要中间人拦截重定向。解决这个矛盾的常见做法是让AC对未认证终端强制放行一个DNS查询结果，将特定域名解析到Portal服务器地址，用户访问任何网页都会被DNS引导到Portal页面。

认证通过但上不了网是另一个高频故障。根源通常是RADIUS服务器向AC下发的放行规则不完整。RADIUS协议用属性值对来传递参数，不同厂商的AC对属性字段的支持程度不一样，比如华为和H3C的AC对RADIUS属性编号的映射就存在差异。一个属性字段填错了，AC解析出来的上网策略就是空的，用户认证成功但依然被挡在门外。遇到这种问题，排查步骤是在RADIUS服务器上抓包，看看认证通过的Access-Accept报文中携带了哪些属性，再到AC上检查这些属性是否被正确解析和应用。

性能优化是运维的进阶课。当认证并发量达到瓶颈时，优化方向通常有三个。第一个方向是Radius服务本身的优化，包括启用认证缓存、优化数据库查询、调整线程池大小。认证缓存的效果立竿见影：一个终端断开WiFi后在几秒内重新连上，如果直接走完整认证流程，就是一次数据库查询加一次协议交互；如果走了缓存命中，几乎不消耗资源。第二个方向是Portal页面的性能和加载体验，页面资源做CDN加速，压缩图片和脚本大小，确保在3G网络下也能在三秒内完成首屏渲染。第三个方向是网络层面的优化，调整AC的认证超时时间，避免无效的半连接占用资源，优化AP的信道分配，减少同频干扰导致的认证超时。

高可用架构是运维的最后一道保险。单点故障在认证系统中是不可接受的。Radius服务宕机，全区域WiFi瘫痪，这属于重大生产事故。Radius服务需要至少部署两个节点，通过VRRP或者负载均衡实现主备切换。主节点宕机后，备节点在数秒内接管所有认证请求，对终端侧几乎无感知。数据库同样需要主从复制，主库故障后从库自动提升为主库。交换机和AC虽然不太容易做热备，但至少要有冷备设备在库房，确保出问题后半小时内能换上。

网络WiFi认证系统的运维，拼的不是单点技术深度，而是对系统全链路的理解。从AP到AC，从Radius到Portal，从短信通道到数据库，整个链条上任何一个环节出问题，用户看到的都是同一个结果：WiFi连不上。运维人员要做的就是顺着这条链路，在最短的时间内找到那个出问题的环节。