校园网WiFi计费系统上线那一刻只是开始，真正的考验在日常运维。这篇文章整理了运维过程中反复遇到的问题和应对经验，不讲理论，只讲实操中发现的规律。
第一个坑：Portal页面不弹或反复弹
这是报修率最高的问题。学生说连不上WiFi，实际是连上了但没弹出认证页面。排查路径通常是：先检查网关是否正常工作（CPU和内存占用）、再看终端的DNS解析是否被正确劫持到网关地址、然后确认网关层的iptables重定向规则是否生效。
反复弹认证页面则是另一个方向的问题。通常原因是终端的系统级连接检测使用了HTTPS站点（如苹果的 captive.apple.com），但校园网WiFi计费系统只对HTTP做了重定向。解决方法是升级网关固件或校园网WiFi计费系统版本，支持HTTPS的Captive Portal检测响应。这个问题在每年新生入学季会集中爆发，因为新生使用各种品牌和系统版本的手机。
第二个坑：无感认证失效
已绑定的设备突然需要重新Portal认证，学生投诉说"明明已经绑定过了"。常见原因有三个：校园网WiFi计费系统的MAC地址绑定表被清空了（通常是系统重启后未正确恢复）、终端换了网卡或开启了MAC地址随机化、AP切换导致DHCP Option82信息变化触发安全策略。
MAC地址随机化是近几年新出现的问题。iOS和Android默认启用了私有WiFi地址功能，终端每次连接WiFi时可能使用不同的MAC地址。校园网WiFi计费系统需要适配这个变化，通常的做法是识别厂商的OUI（组织唯一标识符）前缀来判断是否为随机MAC，或者在首次绑定时提示学生关闭随机化功能。
第三个坑：运营商出口跳变
学生选了电信套餐但实际流量走了联通出口，导致超额计费。这个问题在多运营商环境下偶尔出现，根因通常是：网关层的策略路由表在AP切换或链路故障切换时没有正确更新，导致用户会话的出口标记丢失。
排查方法是查看校园网WiFi计费系统的会话日志和网关的路由表，确认每个在线会话对应的出口标记是否正确。预防措施是在校园网WiFi计费系统中设置出口校验机制：定期检查会话的流量是否走在了正确的出口链路上，发现偏差时自动告警或纠正。
第四个坑：计费不准确
学生投诉说流量明明没用完就被断网了，或者包月到期时间不对。计费不准的常见原因包括：校园网WiFi计费系统的计费周期起始时间与学生缴费时间不一致、跨运营商的流量统计有遗漏（部分流量走了默认出口没被计入）、系统时钟不同步导致会话时长计算偏差。
建议建立每月一次的计费对账机制：从校园网WiFi计费系统导出计费明细，与运营商提供的流量统计做交叉比对，发现差异及时定位原因。这个工作虽然繁琐，但能维护学生对校园网收费的信任。
第五个坑：日志存储爆满
万人学校运行半年后，校园网WiFi计费系统的日志存储就可能接近上限。如果没有提前规划归档策略，日志写满后要么覆盖旧数据（不满足6个月留存要求），要么系统报错停止写入（影响正常计费）。
推荐的日志管理策略是：热数据保留最近3个月，存放在SSD或高速磁盘上供实时查询；冷数据压缩后归档到低成本存储，满足6个月合规留存；超过6个月的数据自动清理或归档到离线存储。配置时要给日志预留至少30%的冗余空间，因为考试季或开学季的日志量可能是平时的2到3倍。
第六个坑：高峰期性能瓶颈
晚上9点到11点是校园网的高峰时段，所有宿舍同时在线。这个时段如果校园网WiFi计费系统性能不足，会出现认证响应慢、网关CPU飙到100%、部分学生被踢下线等问题。瓶颈可能出现在认证服务器、数据库查询、网关NAT会话表任何一个环节。
建议在选型时就做压力测试：模拟80%的预期并发数，持续运行24小时，观察认证响应时间、网关CPU和内存占用、数据库查询延迟等指标。如果厂商不愿意配合做压力测试，这本身就是一个危险信号。
第七个坑：新生季的集中开户
每年9月新生入学是校园网WiFi计费系统运维最忙的时候。几千名新生需要在短时间内完成账号开通、WiFi连接和首次认证。如果校园网WiFi计费系统不支持批量导入用户数据，或者导入过程中出现数据格式不兼容，会极大增加运维工作量。
提前准备的工作包括：从学工系统导出新生名单、按校园网WiFi计费系统要求的格式整理数据、提前做小批量导入测试确认格式无误、准备好常见问题的FAQ发给新生。这些工作建议在8月底前完成，避免开学后手忙脚乱。
运维工具推荐
日常运维中好用的工具包括：用于监控网关状态的Zabbix或Prometheus告警、用于日志分析的ELK（Elasticsearch + Logstash + Kibana）或轻量的Grafana Loki、用于远程排障的SSH隧道工具、用于模拟认证测试的radtest命令行工具。把校园网WiFi计费系统的关键指标（在线用户数、认证成功率、各运营商出口利用率、日志存储使用率）接入监控大盘，可以在问题变成投诉之前就发现和解决。
中文