无线认证系统的验收测试，通常做得比较顺利。测试账号能通，Portal页面能弹，认证日志能查，验收报告一签，项目就算交付了。但这套系统真正跑起来之后，很多问题才慢慢暴露出来。

蓝海卓越在各种场景的项目里总结过这些问题，有些是技术配置层面的，有些是运维管理习惯层面的。下面说几个出现频率最高的，提前知道可以少踩一些坑。

一、用户说上不了网，但在线用户列表里有人，这是什么情况

这是上线后工单里出现频率最高的一类问题。现象很清楚：用户反复弹Portal页面，或者提示密码错误，但账号状态明明正常，认证系统的在线用户列表里也能看到这个人的记录。

问题往往不在认证系统里，而是在AC和认证系统的联动配置上。整个认证流程是：用户发认证请求 → Portal服务器收到请求 → Radius认证通过 → AC收到Access-Accept响应 → AC下发策略放行用户上网。这条链路上任何一个环节出问题，用户都会感知到"上不了网"，但认证日志是干净的。

常见的原因有几个。

第一种：AC侧超时设置太短。用户量集中认证的时候，Radius响应的速度跟不上，AC在等待过程中超时，直接拒绝用户。蓝海卓越的Portal认证服务器支持每秒4000次以上的认证吞吐，但如果AC侧的超时参数没有跟着调，认证能力再强也发挥不出来。

第二种：VLAN分配不一致。用户认证通过了，但AC下发的VLAN标签和预期的策略组不对应，用户被放到了错误的网络里，实际上不了外网。

第三种：策略下发延迟。AC在收到认证响应后，策略下发有延迟，用户端已经收到"认证成功"的提示，但网络还没真正通。这类问题在验收测试时不容易发现，因为测试环境里的并发量远低于真实上线后的水平。

排查这类问题要看整条链路，不能只看认证日志。蓝海卓越的后台有完整的认证流程追踪日志，能看到每个环节的响应时间和返回码，运维人员顺着日志逐段定位，很快能找到根因。

二、多厂商设备对接，出了问题说不清是谁的问题

中大型项目很少只用一家网络设备商。AP是这家厂商的，AC是那家的，交换机又是一家，认证系统还要对接第三方Radius和短信网关。这种多厂商对接环境，是网络项目里扯皮最多的地方。

蓝海卓越的Portal认证系统和Radius认证服务器支持对接十几家主流厂商的AC和交换机，包括华为、中兴、H3C、锐捷、RUCKUS、ARUBA等。对接能力是现成的，但实际项目里，不同厂商固件版本的兼容性、不同配置参数的对接细节，还是会出各种问题。

最有效的预防办法是：在项目验收之前做完整的对接测试，不要等上线后出了问题再来定位。蓝海卓越的项目团队在验收阶段会逐一对接各厂商设备，验证Radius报文格式、Portal跳转逻辑、VLAN下发策略是否正常。如果有问题，在验收阶段暴露出来，甲乙双方的责任边界是清晰的。等上线之后才发现，再来协调各个厂商的工程师，扯皮成本会高出很多。

三、带宽被少数用户占满，大部分人跟着卡

带宽不够用，通常不是因为总出口带宽太小，而是流量分配策略没做或者做得太粗糙。常见的情况是：只设了总带宽上限，没有按用户、按终端、按应用做细粒度分配。结果就是几个人开着下载或者看视频，正常办公的人跟着一起卡。

蓝海卓越的流量控制方案能解决这个问题。NE系列流控网关可以识别3600多种网络应用，对高流量应用做全局限速，对关键业务应用走优先通道。比如，限制P2P下载的峰值带宽不超过50Mbps，保证OA系统和视频会议的带宽始终充足。

有个前提条件：流量识别和带宽控制策略要在上线前配置到位。上线之后再补配置，运维人员要重新理解流量模型，配置参数不一定准，测试验证也需要时间。最好在方案设计阶段就把流量控制策略设计进去。

四、私接路由器和多设备共用账号，计费系统感知不到

这个场景在宿舍、公寓、共享办公空间里很常见。一个房间拉了一条认证账号，接入之后用户把自己的路由器接上去，路由器下面又接了三四台设备，所有这些设备都通过路由器的NAT上网，计费系统只记录了一个账号，实际上有四五台设备在共用。

这类问题的危害不只是计费不准——私接路由器会改变终端的MAC地址和IP分配逻辑，网管系统对网络拓扑的感知就失效了，安全审计日志里只有路由器本身的记录，看不到路由器下面的终端。

蓝海卓越有针对这个场景的检测能力。通过分析终端接入模式、DHCP分配行为、流量特征，系统可以识别出疑似私接路由器的终端，并做告警或者限制。这个功能需要正确配置才能生效，很多项目验收阶段没有专门测这一项，上线后也没定期检查，被用户钻了空子。

更好的做法是配合带宽和设备数策略：每个账号最多同时N台设备在线，超出的拒绝接入；或者对高流量终端做持续监控，发现异常行为自动降速或者封禁。

五、Portal页面打开很慢，用户以为认证失败了

Portal认证页面的加载速度，直接影响用户对整个认证过程的感知。很多项目上线初期用户投诉"认证页面打不开"，实际上不是认证失败了，而是页面加载太慢，用户没有耐心等，直接放弃了。

影响Portal页面加载速度的因素有几个。

第一种：Portal服务器性能不足。高并发认证场景下，Portal服务器同时处理大量用户的页面请求，如果服务器CPU和内存配置不够，页面响应会变慢。蓝海卓越的Portal服务器支持集群部署，可以通过横向扩展应对高并发，验收阶段要做压力测试，模拟高峰期用户量，看服务器能不能撑住。

第二种：页面资源太大。很多酒店和商场把Portal页面做得很炫酷，高清大图、Flash动画、视频背景——这些资源加载起来很慢。用户体验最好的Portal页面反而是轻量级的，核心信息清晰，加载时间控制在3秒以内。蓝海卓越的Portal定制服务会建议甲方控制页面资源大小，不要用炫技式的设计影响基础体验。

第三种：外部资源引用。有些Portal页面引用了外部CDN资源（比如字体、图标库），如果CDN访问不稳定，页面加载就会受影响。最稳妥的做法是把外部资源本地化，所有页面资源都放在本地服务器上，不依赖外部网络的连通性。

六、日志留存周期差几天，上级检查来了才发现

《互联网安全保护技术措施规定》要求上网日志留存不少于6个月。这是硬性要求，检查来了拿不出日志，就是违规。

但实际项目中，系统配置的日志留存周期经常和这个要求有偏差。有的是数据库空间预估不足，日志自动清理周期被设短了；有的是日志服务器部署架构有问题，部分网段的日志没有完整采集；有的是日志推送接口断了几个月没人知道，数据没有真正推到网监平台。

解决这个问题，需要定期做日志完整性检查。蓝海卓越的运维服务包里包含定期巡检项目，会检查日志留存周期配置是否正确、日志推送是否正常、存储空间是否充足。定期巡检不能省，这是合规的最后一道防线。

说到底，无线认证系统上线后的问题，大多数不是认证系统本身的质量问题，而是验收阶段没有测到边缘场景、运维阶段没有做定期巡检、方案阶段没有把流量控制和设备数策略做细。上线前多做一步压力测试，上线后每月做一次运维巡检，很多问题在萌芽阶段就能被发现和解决。