WX3510-portal登录提示 系统繁忙，请稍后重试

本地portal还是远程portal

看下认证服务器上认证失败原因是什么

. 检查设备基础状态（首先排除）
登录设备命令行，执行以下命令，检查设备CPU、内存是否真的过高。
display cpu-usage
display memory-usage
如果CPU或内存持续高于80%，可能是遭受攻击或存在环路，需要进一步排查高负载进程：display process cpu
如果资源正常，则问题出在认证流程本身。
2. 检查Portal服务与License
确认Portal服务已开启：
display portal server
检查License是否充足：Portal认证需要独立的用户License。
display license
查看“Portal用户数”或类似条目，确认授权是否在有效期内且数量足够。
3. 检查关键配置（最常见问题点）
请仔细核对以下配置，任何一处不匹配都可能导致此错误：
Portal服务器配置：确保AC上配置的Portal服务器IP、端口、URL、共享密钥与实际的Portal服务器（如IMC、第三方系统）设置完全一致。
display portal server
重定向ACL：Portal认证依赖重定向ACL将用户HTTP请求劫持到认证页面。检查该ACL规则是否正确，是否允许了用户网段访问Portal服务器和DNS。
display acl <acl-number>
认证域与RADIUS服务器：检查用户所属的认证域（domain）以及域下绑定的RADIUS服务器状态是否正常。
display domain <domain-name>
display radius scheme <scheme-name>
4. 检查网络连通性
AC与Portal服务器：在AC上ping和telnet测试Portal服务器的IP和端口，确保网络可达。
AC与RADIUS服务器：同样测试AC到RADIUS服务器的1812/1813端口连通性。
用户与Portal服务器：从待认证的用户电脑上，尝试直接访问Portal服务器的URL，看是否能打开登录页面（此时应能打开，但无法认证）。
5. 检查时间同步
如果使用RADIUS协议进行认证，AC设备与RADIUS服务器的时间差不能太大（通常建议在5分钟以内），否则可能导致认证失败。
display clock
如果时间不一致，请配置NTP同步。
6. 收集日志与诊断信息（最直接有效）
开启相关模块的调试日志，这是定位问题最准确的方法。
# 开启终端监控
terminal monitor
terminal debugging

# 开启Portal和RADIUS调试信息
debug portal all
debug radius all

# 此时，让用户再次尝试登录，观察控制台输出的详细错误信息。
# 日志会明确显示是“接收服务器消息超时”、“密钥错误”、“重定向失败”还是“RADIUS无响应”等。
注意：调试完成后，务必关闭调试以节省资源。
undo debug all
常见原因总结
根据经验，按概率排序：
共享密钥错误：AC与Portal服务器/Radius服务器之间的密钥配置不一致。
网络不通：AC、Portal服务器、Radius服务器三者之间存在防火墙策略拦截或路由问题。
服务器问题：Portal认证服务或Radius服务未启动、异常或性能瓶颈。
配置遗漏：如未应用认证域、接口未启用Portal、重定向ACL配置错误等。
License不足：Portal用户数超过授权限制。
建议您首先执行第6步（开启调试日志），根据具体的错误代码或提示，可以快速将问题范围缩小到上述某一个环节，然后进行针对性解决。如果日志显示与服务器通信失败，请重点检查服务器状态和网络配置。

Portal本地用户认证登录失败提示“系统繁忙，请稍后重试”，可按以下步骤排查：

1. **检查是否配置认证失败重试延迟**：
查看是否配置了 `attack-defense login reauthentication-delay`，若已配置，用户在多次失败后需等待指定时间才能重新认证，此期间尝试登录会提示“系统繁忙”。可通过命令查看：
```
display attack-defense login
```
如需调整或取消延迟时间，可修改或删除该配置。

2. **检查设备系统资源状态**：
使用以下命令检查CPU、内存使用率是否过高：
```
display cpu-usage
display memory-usage
```
资源过高可能导致认证处理延迟或失败。

3. **检查Portal服务状态**：
确认本地Portal服务器功能已启用：
```
display portal local-server
```
确保状态正常，无关闭或异常提示。

4. **检查在线用户数及会话数**：
查看是否达到设备最大用户数限制：
```
display portal user-count
```
超限可能导致新用户无法认证。

5. **查看日志信息定位原因**：
执行：
```
display logbuffer
```
查找与Portal认证失败相关的日志，确认具体错误原因。

建议：若近期配置过 `idle-cut` 或调整过DHCP租约，需确保 `idle-cut` 时长小于DHCP租期一半（建议为租期的1/3），并清除旧Portal表项后重启认证，避免因会话残留导致认证异常。

如仍无法解决，请收集配置与日志并联系400技术支持。