Portal 认证的流程
Portal 认证通过把终端重定向到认证页来实现访客上网准入：终端先被放行 DNS 与 DHCP，随后任何 HTTP 访问被重定向到 Portal，用户完成认证（短信、微信或账号）后才被放行。它常见于酒店、商场与园区访客网。需要特别注意：现代终端依赖固定的探测地址来判断「是否需要登录」，这些域名必须放行，否则认证页不会自动弹出。
基本信息
| 基本流程 | 放行 DNS 与 DHCP → HTTP 重定向 → 认证 → 放行 |
|---|---|
| 实现方式 | AP/AC 内置 Portal，或使用独立 Portal 服务器 |
| 弹出机制 | 依赖终端连通性探测地址被放行 |
| 安全要求 | Portal 页面必须用 HTTPS 承载 |
| 常见问题 | 已连上但认证页不自动弹出 |
典型使用场景
- 酒店、商场与园区访客网的准入
- 排查「连上了但不弹认证页面」
- 评估短信认证与微信认证的落地
- Portal 与 OWE 组合部署
- 为访客网络满足实名与日志合规
常见故障现象
常见故障现象
# 已连上但一直不弹认证页
# → 检查终端是否跳过了联网探测
# → 确认 Portal 放行了各系统的连通性探测域名
# → 确认 80 与 443 都被放行，且页面走 HTTPS各系统探测依赖
| 系统 | 探测行为 | 配置要点 |
|---|---|---|
| iOS | 访问固定探测地址 | 需要在 Portal 放行该域名 |
| Android | 访问固定探测地址 | 同上，并注意 443 端口 |
| Windows | NCSI 连通性探测 | 放行对应域名与端口 |
| 部分机型自动加入 | 可能跳过 Portal | 引导用户手动打开浏览器 |
iOS 与 Android 的联网探测依赖固定地址，Portal 必须允许这些探测域名通过，否则认证页面不会自动弹出。
Portal 页面必须用 HTTPS 承载，否则凭据会在空口被旁听，这是访客网络最常见的安全疏漏。
Portal 与动态 VLAN 常配合使用：认证前终端在预置 VLAN，认证成功后由 RADIUS 下发业务 VLAN，VLAN 切换瞬间可能出现短暂的地址变化，属于正常现象。
Portal 认证成功后要把会话超时与断线重连策略一起配置：超时过短会让用户频繁重新认证，过长则削弱了准入的实际效果。
只放行 80 不放行 443，会导致部分终端检测不到 Portal：现代探测大多走 HTTPS。