系统上线只是开始，真正的考验在用户涌进来的那一刻。很多单位前期测试都顺利，一正式开放就冒出各种认证失败：有人连上弹不出页，有人收不到验证码，有人卡在"认证中"转圈。这些问题单看一个个都小，堆在一起就是大面积投诉。把常见的失败原因和排查路径理清楚，上线后才不至于手忙脚乱。

弹不出认证页，先看DHCP和重定向

用户连上WiFi却看不到认证页，最常见的两类原因：一是没拿到IP，DHCP地址池满了或者交换机没放通；二是拿到了IP但重定向没触发，DNS被拦或者Portal规则没生效。排查时第一步用手机连上后看IP拿到了没，能打开认证服务器域名吗。我们处理过一起商场故障，原因是新加了一批AP但没同步Portal模板，只有那几台AP下的用户弹不出页，其他区域正常，这种局部故障最容易误判成全局问题。定位要具体到位点，不能笼统说"网络有问题"。

收不到验证码，九成是短信通道或防火墙

填了手机号点获取验证码却一直收不到，绝大多数不是认证系统本身的问题。要么是短信网关余额不足、通道被限流，要么是防火墙把出站短信端口拦了。排查时让运维从服务器侧发一条测试短信，看能不能到达，再查防火墙策略。曾经有个项目上线当天短信量暴增，供应商的免费额度用完了没提醒，结果一半用户收不到码。这类问题上线前就应该设好余额告警和备用通道，而不是等用户投诉。

卡在"认证中"，多半是后端会话或并发

用户输入验证码后页面一直转圈，或者提示认证失败但说不清原因，通常出在认证服务器和后端数据库或计费模块的会话处理上。高峰期并发一高，数据库连接池耗尽、会话锁等待，就会让一部分请求卡死。这种问题测试环境压不出来，只有真实峰值才暴露。我们一般建议上线前做一轮接近真实的压测，并且给认证服务器配好连接池上限和超时熔断，卡住的请求快速失败而不是无限等待，至少用户能重试。

认证成功却上不了网，放行策略没配对

还有一类更隐蔽的：页面显示认证成功，但用户打开网页还是不行。这说明认证动作完成了，但认证后把用户从"受限VLAN"放到"上网VLAN"的那一步没生效，可能是radius返回的属性不对，也可能是交换机没接住授权。排查要看认证服务器日志里有没有下发授权，再看交换机侧有没有收到并应用。我们遇到过一个案例，认证全绿，但上网VLAN的网关地址配错了一个数字，几百号人集体上不了网，表面看认证一切正常，实际是最后一公里的网络配置问题。

部分终端连不上，看兼容性和频段

投诉里经常有"我的手机连不上，别人的能"，这种多半是终端兼容性。某些老旧安卓对特定加密方式支持差，某些苹果设备对5G和2.4G的切换处理不同。排查时要收集失败终端的具体型号和系统版本，对照已知兼容列表。我们一般建议公共场合的认证WiFi同时开2.4G和5G，并且不要把认证页强依赖某个频段。个别机型实在适配不了的，至少要有个明确的提示而不是让用户干等。

日志是排查的命脉，但要会看

所有认证失败排查，最终都要落到日志：认证服务器记了什么、AC记了什么、防火墙记了什么。问题是很多单位日志散在各处，出事了要登三四台设备拼时间线。我们建议上线时就把关键日志集中到一个能检索的地方，并且给每种失败配一个明确的错误码。用户报"连不上"时，运维一查错误码就知道是哪一类，不用从头猜。日志不是给监管看的摆设，是给自己排障用的武器。

建立一份故障分级响应机制

认证故障分轻重，不能一律当急诊。个别用户连不上，可能是终端问题，引导重试即可；一片区域连不上，是点位或设备问题，派人去现场；全场上不了，是核心链路或服务器问题，要立刻启动预案。我们给客户做上线支持时，会先帮他们把故障分成三级，每级对应谁来处理、多久要响应。没有分级，小问题也会被当成大事故乱撞，既浪费人力又容易误操作。机制比人靠谱，尤其半夜出事的时候。