上周刚处理完一个项目收尾，某省属本科院校，去年十月上线了新的校园网认证计费系统，开学后三个月内累计收到近两千条投诉，绝大多数集中在宿舍区，主要症状是：认证页面打不开、认证成功后掉线、套餐扣费但无法上网。我把这次排查过程中发现的问题整理出来，方便做类似项目的人少踩一遍。

坑一：AP与认证系统的重定向逻辑没有对齐

Portal认证的核心逻辑是：未认证的终端访问任何网页时，网络设备（通常是AC或者核心交换机）拦截HTTP请求，将用户重定向到Portal认证页面。这个重定向依赖两端配置：网络设备这边要知道把未认证流量发到哪里，认证系统这边要能接收并处理重定向过来的请求。

这次项目的问题是：部分老旧AP固件不支持新版本的重定向协议（Portal 2.0），它们还在用老协议发重定向请求，但认证系统已经升级到了只支持新协议的版本。结果是这些AP区域的用户完全拿不到认证页面，表现为"连上WiFi但上不了网"。排查了一周才定位到是AP固件版本的问题，最终花了一个月时间把全校二百多台问题AP全部升级固件。

坑二：HTTPS网站触发不了认证重定向

这个问题在行业里已经存在多年，但还是有很多项目没处理好。Portal认证的重定向是基于HTTP的，认证系统需要能拦截到未认证终端的HTTP请求才能完成重定向。但现在绝大多数网站都是HTTPS，浏览器默认优先访问HTTPS，HTTPS流量加密之后网络设备无法拦截，重定向就失效了。

处理方式有几种：在AC上配置专门的HTTP引流地址（让终端先访问一个确定的HTTP地址），或者在认证系统里内置一个检测服务，终端连上无线之后主动发起探测请求触发重定向。不同厂家的解决方案实现方式不同，但如果项目里没有专门测试HTTPS场景下的认证触发，上线后这个问题一定会大批量出现。

这次项目里，iOS设备的认证触发率明显高于Android，原因是iOS有一套Captive Portal检测机制，连上WiFi后会自动访问一个苹果的HTTP检测地址，触发重定向。Android不同厂家的行为不一样，部分机型默认HTTPS优先，就卡在了这个问题上。

坑三：账号并发认证限制设置过严

认证系统为了防止账号共享，通常会限制同一账号在短时间内的认证次数。比如设置为"同一账号一分钟内只能发起三次认证请求，超过则封禁十分钟"。这个设置的本意是对抗脚本批量认证，但在实际使用中，学生手动重复点"重试"很容易触发这个限制。

宿舍区的典型场景是：认证页面加载慢，学生等了几秒没反应，多点了几次"提交"，结果账号被自动封禁，学生以为系统坏了，到网络中心投诉。网络中心一解封，学生回去再点一遍，又封了。这一轮循环在开学前两周非常集中，单天解封申请可以到几百条。

解决方法是调整并发认证限制的阈值和封禁时长，开学期间可以临时放宽，同时在认证页面加入"认证中……"的等待提示，减少学生重复提交的冲动。

坑四：计费扣款和在线状态不同步

这次项目用的是按时长计费的套餐，逻辑是：学生在线时长实时累计，套餐时长用完后提示续费，不续费则强制下线。

出问题的地方在于：认证服务和计费服务是两个独立的模块，它们的状态同步是靠消息队列做的。在某些高峰时段，消息队列积压，计费模块认为学生套餐已经到期，通知认证模块把账号下线，但认证模块还没来得及处理，学生在前端还在正常上网。等认证模块处理完，账号被踢下线，学生看到的是"突然断网"，根本没有提前提示。

学生充了钱但被意外踢下线，投诉量非常高，而且每一条都要核查，判断是真的套餐用完还是系统bug。这种问题的根源在于两个模块的状态同步机制没有设计好，调试起来也费时，最后是供应商花了两周时间做了专项优化。

坑五：教职工账号优先级设置引发访问冲突

学校给教职工配置了不限流量的优先套餐，但系统里对"教职工"的判断依据是账号属性，而不是接入地点。结果是：部分教职工在宿舍楼附近接入了宿舍区的AP，账号属性是教职工，享受不限流量，占用了宿舍区的出口带宽，导致宿舍学生在晚高峰时期网速极差。

这个问题不是认证系统本身的Bug，是策略设计的漏洞：带宽策略应该和接入点的位置绑定，而不是只和账号属性绑定。教职工在教学楼和行政楼享受优先级，在宿舍楼就应该按正常学生待遇处理，或者做物理隔离。排查这个问题花了三天，因为谁都没想到账号优先级会和地理位置产生耦合。

坑六：短信验证码网关在高峰期限流

系统支持短信验证码找回密码和短信认证，接入的是第三方短信网关。开学第一周，大量学生同时激活账号，短信发送量在早上八点到九点集中爆发，超过了网关的免费额度和预设发送速率限制，网关开始限流，大量验证码延迟甚至不到。

学生收不到验证码，以为账号有问题，到网络中心投诉。网络中心调查发现是网关限流，给短信服务商打电话扩容，折腾了大半天。这个问题可以通过提前预估开学峰值发送量，和服务商谈好保障协议来规避。但实际上没有一家高校在采购认证系统的时候会考虑到这一条。

坑七：日志查询接口响应太慢，运维效率极低

每当有学生投诉断网或者扣费有问题，网络中心的处理流程是：查日志，看这个账号最近的认证记录和计费记录，判断问题出在哪里。

但这次上线的系统，管理后台的日志查询界面，查询一个账号最近三十天的记录，要等三十秒以上，有时候还会超时报错。原因是日志表没有做合理的索引，数据量积累之后查询性能急剧下降。

运维效率直接影响投诉处理速度，一条投诉如果要等半小时才能查清楚，学生不满意，运维人员也疲惫。这个问题在测试环境里数据量少看不出来，上线三个月数据量积累到百万条之后才暴露。最终是供应商来做了数据库优化，加了索引，查询时间降到了两秒以内。

以上七条问题，有设计缺陷，有配置失误，有压力测试不充分，也有需求对接不到位。没有一条是无法避免的，但每一条都需要有人在项目早期主动去想、去测，而不是等上线后被投诉倒逼着去解决。