WiFi认证系统认证失败率高怎么查：分层排查树

用户打电话说"WiFi 连不上"，这句话背后可能是十几件完全不同的事：他手机 WiFi 没开、信号太弱、密码输错、认证页面弹不出来、认证服务器没响应、出口断网、还是他的账号已经过期。网管如果每次都从第一句开始猜，一个电话就要折腾半小时。一套 WiFi认证系统 上线之后，把认证失败的排查路径理成一棵从用户端到出口的树，是日常运维最能省时间的事。

排查的第一步，是先分清"连不上 WiFi"和"连上 WiFi 但上不了网"。这两个现象用户描述起来差不多，但故障位置完全不同。前者的问题在无线关联层，也就是手机和 AP 之间的连接还没建立；后者的问题在认证和网络层，无线已经连上，但认证没通过或者策略没放行。区分方法很简单：让用户看手机 WiFi 设置，那个 SSID 后面有没有显示"已连接"；再看手机状态栏，连上之后有没有出现登录提示。SSID 都连不上，先查无线信号和 AP；SSID 连上但网页打不开，往认证链路查。

无线关联层的问题通常集中在几个点。信号弱是最常见的：用户所在位置 AP 覆盖不到，或者被墙壁、金属柜子挡住，手机看到信号格但实际协商速率很低。这种情况换个位置或者加个 AP 就能解决，和认证系统无关。AP 本身故障或者负载过高也会导致连不上，同一时间太多人挤在一个 AP 上，新用户就关联失败，这要从 AC 后台看 AP 的在线数和负载。还有一类是终端兼容性：某些老手机在特定信道或者特定加密方式下关联不上，换个 SSID 或者调整信道就好。

无线连上之后，下一个要看的是 Portal 认证页面弹不弹得出来。这是用户投诉的重灾区——明明连上了 WiFi，打开浏览器却是一直转圈，或者直接打开了旧页面。这个问题的根因通常不在认证服务器，而在 Portal 重定向这一跳。手机连上 WiFi 之后，系统应该自动把所有 HTTP 请求重定向到认证页面，但如果用户手机开了 VPN、装了广告拦截、DNS 被手动改过，重定向就会被挡住。排查时先让用户手动打开一个没上过的 HTTP 地址，看能不能触发跳转；再让他关掉 VPN 和代理。这一招能解决掉相当大一部分"弹不出页面"的工单。

认证页面能打开了，下一步才是认证服务器本身。用户提交账号密码或者短信验证码之后，系统返回成功还是失败？后台日志里应该能看到这次认证请求：来源 IP、认证方式、结果码、失败原因。如果日志里根本没有这次请求，说明请求没到认证服务器，问题在网络链路——AC/AP 到认证服务器之间的转发、Radius 报文有没有被防火墙拦。如果日志里有请求但返回失败，看失败原因：账号不存在、密码错误、账号过期、被锁定、还是余额不足。这一类问题根据日志对症下药，比让用户反复重试高效得多。

短信验证码收不到是另一类高频问题。用户在认证页输了手机号，验证码迟迟不到，他就反复点发送，结果收到一堆延迟的验证码。这个问题通常不是认证系统的锅，而是短信通道的问题：通道拥堵、运营商拦截、用户手机号被标记。排查时先看认证后台的短信发送记录，有没有发出去、回执是什么状态。如果显示已送达但用户没收到，是用户手机端的问题；如果根本没发出去或者回执失败，联系短信服务商。不要在这种情况下让认证系统重启，重启解决不了短信通道的问题。

认证成功了但还是上不了网，问题就转到策略和放行这一段。用户认证通过之后，认证系统要通知 AC/交换机把他的流量放出去，还要给他下发对应的 VLAN、带宽、访问权限。如果这一步没成功——比如 Radius 响应里带的属性 AC 不认识、VLAN 下发失败、策略没生效——用户会看到"认证成功"但实际还是上不了网。这类问题要在认证日志和 AC 日志两边对：认证侧显示成功，AC 侧有没有收到对应的放行指令。两边对不上，就是中间这条联动链路出了问题。

还有一类是"时好时坏"的故障，最让运维头疼。用户有时候能认证成功，有时候又不行，没有明显规律。这种问题通常和高并发、链路波动、或者会话保持有关。晚高峰认证请求集中的时候，认证服务器处理不过来，部分请求超时；或者主备链路切换的时候，短暂的认证中断；或者用户在 AP 之间漫游时，认证会话没有正确移交。排查这种问题不要盯着单个用户，要看认证系统的监控曲线：失败率是不是集中在某个时段，是不是集中在某个 AP、某个 VLAN、某类终端。把失败率按这几个维度切开，规律通常就出来了。

前面这些排查步骤，应该沉淀成运维手册而不是存在某个人脑子里。常见故障对应的现象、排查第一步、定位位置、解决方法，写成一页纸的速查表。一线运维遇到工单，先按速查表走前两步，能定位的直接处理，定位不了再升级。这样既缩短了用户等待时间，也避免每次故障都要把资深工程师叫起来。

日常监控要前置。不要等用户投诉了才知道认证失败率上升。认证系统的实时在线数、认证成功率、失败原因分布、Portal 响应时间，这几个指标应该在后台有持续监控，失败率一旦超过阈值自动告警。这样很多问题在用户感知之前就被发现了，比如某个 AP 突然失败率飙升、短信通道响应变慢，运维先收到告警先处理，比用户打电话进来要主动得多。

认证故障排查说到底是一个分层定位的过程：先分无线层和认证层，再从终端、Portal、认证服务器、联动策略、出口一段一段往下切。每一段都有对应的日志和监控点，不要一上来就重启服务器——重启解决不了定位问题，还会把现场日志冲掉。把这棵排查树跑顺之后，大部分认证故障都能在几分钟内定位到具体环节，剩下真正需要厂商介入的，也能带着清晰的日志和现象去提工单，而不是一句"网不好"让厂商自己猜。