Portal 反复弹窗是什么问题
认证成功之后页面又重新出现，或者没过多久再次要求登录。这类问题几乎都出在会话管理上：会话超时设置过短、终端 MAC 发生变化导致会话无法延续、控制器与 Portal 服务器的会话表不一致。表面上看像认证失败，实际上认证是成功的，只是会话很快就不被识别了。
常见根因
| 会话超时 | Idle-Timeout 或 Session-Timeout 设得过短，静默一段时间即被回收 |
|---|---|
| MAC 变化 | 终端开启随机 MAC 且每次连接都变化，会话无法延续 |
| 状态不同步 | 控制器与 Portal 服务器会话表不一致，实际在线却仍被重定向 |
| 排查顺序 | 先看会话表，再比对终端 MAC，最后检查超时配置 |
| 缓解方向 | 把访客会话与设备指纹解耦，或适度延长会话超时 |
现象与可能原因
| 现象 | 可能原因 | 验证方法 |
|---|---|---|
| 认证后立刻又弹窗 | 会话未成功建立 | 查控制器会话表是否存在该终端 |
| 几分钟后要求重新认证 | 会话超时过短 | 核对 Idle-Timeout 与 Session-Timeout |
| 同一终端每次都重新认证 | 随机 MAC 轮换 | 对比两次连接使用的 MAC |
| 只有某机型反复弹窗 | 该机型随机化策略激进 | 换终端对照验证 |
| Portal 显示在线但页面仍弹 | 两侧会话表不同步 | 比对控制器与 Portal 的在线列表 |
会话核对
会话核对
# 控制器侧查看该终端的在线会话与剩余时间（命令随厂商不同）
show client detail <终端MAC>
show portal session
# 核对要点
# 1. 会话是否存在
# 2. 会话剩余时间还剩多少
# 3. 会话记录的 MAC 与终端当前 MAC 是否一致随机 MAC 场景可以把访客会话与设备指纹解耦，或者适度延长会话超时，用更宽容的判定换取更低的重复弹窗率。两种做法都要先确认符合本单位的审计要求。
把 Portal 重复弹窗当作认证失败来排查会走错方向：多数情况是会话表不同步或超时参数问题，而不是凭据或服务器故障，改 RADIUS 配置只会白费功夫。