故障排查与解决
故障现象 / 场景
客人连上酒店 WiFi 后浏览器不跳认证页；或认证页面能打开、也能点击登录，但登录后依旧打不开网页；部分安卓机正常、苹果机异常（或反之）。
排查思路（由易到难）
- 确认是「不弹」还是「弹了打不开」：先手工访问任意 http 站点，看是否 302 到认证页；
- 检查免认证白名单是否包含认证服务器自身的域名与 IP，若被 Portal 拦截会形成死循环；
- 确认 HTTPS 站点处理方式：多数 Portal 无法对 HTTPS 做重定向，需依赖终端的强制门户探测（Captive Portal）能力；
- 检查 DHCP 下发的 DNS 是否为网关或内网 DNS，错误的 DNS 会导致探测域名解析失败而不弹页面；
- 查认证后的授权表与地址池，确认认证成功但未下发放行规则（常见于 AC 与网关分离部署、规则未同步）。
解决方案
1) 白名单放行认证服务器域名与 IP、以及终端探测域名。 2) 保证 DHCP 下发的 DNS 可达且能解析探测域名，避免直接下发不可用的公网 DNS。 3) 确认 AC 与网关之间的认证联动配置一致，认证通过后能正确下发放行 ACL。 4) 按酒店合规要求开启实名认证（手机号短信或微信连 WiFi），并确保认证记录与上网日志可留存、可查询。 5) 对认证页做一次真机回归：iOS、Android、鸿蒙各测一台，覆盖微信内置浏览器与系统浏览器。
适配型号支持 Portal / 微信连 WiFi / 短信认证的 AC 或网关（华为、锐捷、H3C、爱快等）
根因总结
Portal 认证是终端、DNS、AC、网关、认证服务器五方协作的结果。任意一环缺位都会表现为「不弹页面」或「认证了也不通」，而不是某一个设备坏了。
延伸知识
同类问题在商场、医院、园区的访客网络上完全一致；差异在于酒店还需满足公安网安对实名与日志留存的备案要求，认证方式不能随意用「无感知直连」。
避坑要点
不要为了「让页面能弹出」而把 Portal 整个关掉。酒店访客网络一旦失去实名环节，既不合规也无法追溯；确需免认证的只能是员工网络或指定设备。
「不弹认证页」和「认证了不通」是两类问题
| 现象 |
主要方向 |
| 完全不跳转 |
探测域名被拦、DNS 不可达、白名单缺失 |
| 页面能开、点了没反应 |
认证服务器与 AC 联动异常 |
| 认证成功仍打不开 |
放行 ACL 未下发、地址池或授权表异常 |
| 只有部分手机异常 |
终端强制门户探测机制差异、HTTPS 处理方式 |
什么是「强制门户探测」
iOS、Android、鸿蒙在连接 WiFi 后会自动向各自的探测域名发起一次 HTTP 请求，如果被重定向就弹出认证页面。因此：
图片素材来自免费商用图库（pixabay，摄影师 Sunriseforever），非本站项目实拍。
- 探测域名必须解析得通且不被误拦；
- 认证服务器自身的地址必须在白名单里，否则认证页面自己也打不开；
- 纯 HTTPS 环境无法被传统 Portal 直接重定向，需依赖上述探测机制。
酒店特有的合规要求
酒店访客网络在多数地区需要满足实名认证与上网日志留存要求。认证方式可以简化，但不能省略：常见做法是手机号短信认证或微信连 WiFi，同时保证认证记录（时间、手机号/标识、终端 MAC、上下线）可留存、可导出、可按要求查询。
上线前的回归清单
- iOS / Android / 鸿蒙各一台真机；
- 系统浏览器与微信内置浏览器各测一次；
- 验证断线重连后是否需要重新认证；
- 验证认证记录确实落库，日志留存周期符合备案要求。
本文由 58120 智能网络 原创发布。转载请注明出处并保留原文链接。
评论 0
还没有评论，来抢沙发吧。