WiFi实名认证系统上线，往往不是麻烦的结束，而是另一种麻烦的开始。上线头几周，认证失败的工单会集中涌来：连上了弹不出页、收不到验证码、认证通过却上不了网、时好时坏。这些问题单个看都不难，但如果不建立一套排查思路，运维就会陷在反复救火里。我们把上线后最常见的几类认证失败原因梳理出来，附上排查路径，能省掉大量无用功。

弹不出认证页，先看重定向链路

用户连上WiFi，打开浏览器却直接进网站、或者提示无网络，认证页不出来，这是最高频的问题。根因几乎都在重定向：未认证用户访问外网时没有被精准引到Portal。排查顺序一般是：终端有没有正常拿到IP、DNS能不能解析、AC或网关的重定向规则有没有生效、认证服务器地址通不通。我们遇到最多的，是DHCP给了IP但DNS被安全策略误拦，重定向触发不了。还有AC固件bug导致特定终端不弹页。排查时拿一台测试手机，一步步看从连WiFi到弹页的每一跳，比盲目重启设备有用得多。

收不到验证码，八成在短信通道

认证页弹出来了，输完手机号点获取验证码，一直收不到，这类失败几乎都出在短信通道。可能的原因：通道被运营商限流、供应商接口故障、号码被运营商判为高风险拦截、短信内容触发敏感词。排查要分两头：一边在认证系统侧看发送请求有没有发出、返回码是什么；一边用不同运营商的手机号实测。我们建议上线前就接好备用短信通道，主通道异常时自动切换，并且监控发送成功率和到达时延。只接一家通道又没有监控，高峰期一挂就是大面积认证失败。

认证通过却上不了网，查放行策略

用户输入验证码显示认证成功，但网页还是打不开，这种"假成功"最让人迷惑。根因通常是认证通过后， firewalls 或者AC没有把该终端从"未认证VLAN"移到"已认证VLAN"，或者放行的访问策略没生效。排查要看认证系统返回成功之后，有没有正确下发放行指令给网络设备，网络设备有没有执行。我们遇到过AC和认证系统之间的放行接口偶发超时，成功了一半没放行。这类问题要在认证系统和网络设备上同时抓日志对照，单看一边容易误判。

时好时坏，多半是并发或链路抖动

认证平时正常，一到高峰期就大面积失败，或者某个区域时好时坏，这类问题指向容量和链路质量。认证服务器并发到顶、回程链路丢包、AP负载不均，都会在峰值暴露。排查要拉高峰期的监控：认证服务器CPU和连接数、链路延迟丢包、各AP的带机量。我们做过一个场馆，平时几百人没问题，活动一来两千人同时认证，服务器连接池耗尽，一半人卡在获取验证码。扩容连接池、加认证前置缓存后解决。时好时坏的问题，靠"等它再犯"时抓现场数据，比静态检查有效。

特定终端连不上，看兼容和协议

安卓能连苹果连不上，或者某品牌手机总失败，这是终端兼容问题。原因可能是特定系统对Portal重定向的处理差异、对HTTPS拦截证书的不信任、对 captive network 检测的实现不同。苹果设备尤其特殊，它有自己的联网检测机制，和某些认证页的跳转逻辑会打架。排查要用多品牌终端复现，重点看认证页在对应系统上的表现。我们建议认证页做终端适配，并且提供一个"手动打开认证页"的兜底入口，万一自动跳转失败，用户也能手动进。

批量失败，先怀疑外部依赖

如果某一刻开始,所有用户同时认证失败，基本不是本地配置问题，而是外部依赖挂了：短信网关、身份对接系统、公安上报平台、DNS服务。排查要立刻检查这些外部服务的健康状态，看认证系统有没有对应的错误日志和告警。我们强调上线时就要给所有外部依赖接监控和告警，一旦批量失败，第一时间能判断是内部还是外部。否则容易在本地设备上瞎折腾半天，其实根因在几百公里外的短信平台维护。

反复失败的用户，查账号状态

个别人无论怎么试都过不了，其他人正常，多半出在这个账号本身：被拉黑、被限频、状态异常、和身份系统对不上。排查要在认证系统里查这个账号的认证历史、失败码、限制记录。我们见过用户连点十几次获取验证码，触发限频被临时锁，自己还不知道。还有账号在身份系统里被禁用但WiFi侧没同步，认证永远失败。这类问题要有专门的账号诊断入口，输入号码就能看到完整状态和最近失败原因，别让用户和运维互相猜。

建立排查手册比堆人肉救火强

上面这些问题，每一次都从头查，效率极低。我们建议上线时同步产出一份认证失败排查手册，把每类现象对应的排查路径、常用命令、日志位置、联系谁，都写清楚。一线运维照着手册走，大部分问题十分钟能定位。手册还要随问题积累持续更新，新出现的失败模式补进去。WiFi实名认证系统本身也应该提供诊断看板，把发送成功率、放行成功率、各区域失败分布摆出来，让运维从"等投诉"变成"看板预警"。排查能力沉淀下来，上线后的麻烦才会真正降下去。