网络准入认证系统上线之后，问题往往不是一次涌现的，而是分批来的——今天这个部门说连不上网，明天那个终端弹不出认证页面，后天又发现某台交换机没响应 RADIUS 请求。这些故障看着五花八门，但归结起来，其实也就几类。把这几个故障模式摸清楚了，排查效率会高很多。

认证客户端无法弹出 Portal 认证页面

这是 Portal 认证方式下最常见的问题。终端连上无线或插上网线后，浏览器自动跳转到认证页面，或者手动打开网页被重定向到认证页面——这个过程看起来简单，但在网络环境里有很多环节可能出问题。

首先排查 DNS。如果终端拿到的是内网 DNS 地址，但 DNS 服务本身不稳定或者解析策略有问题，终端访问任意 URL 时无法被重定向，Portal 页面就打不开。最简单的验证方式是在终端上 ping 一下内网 DNS，如果能通，再手动在浏览器里输入认证服务器的 IP 地址，看能否直接访问。如果 IP 能打开但域名不行，问题就在 DNS。

其次是 HTTPS。现在大部分网页都走 HTTPS，但 Portal 重定向依赖 HTTP 流量——只有 HTTP 请求才能被拦截到 Portal 页面，HTTPS 请求会产生证书警告，终端看到安全提示后就卡住了。排查方法是在终端的浏览器里输入一个纯 HTTP 的地址（比如 http://neverssl.com），如果能正常跳转到 Portal，说明 HTTPS 是罪魁祸首。临时处理方式是让认证网关在拦截 HTTPS 时返回一个 HTTP 302 跳转到 Portal 页面的 IP 地址，而不是尝试解析 HTTPS 证书。

还有一个容易被忽略的原因是浏览器缓存。终端之前可能访问过认证服务器，浏览器记住了 Cookie 或者 HSTS 策略，导致 Portal 页面显示异常。测试方法是换一个从未使用过的浏览器或者开隐私模式再试。

802.1X 认证反复失败、反复重试

802.1X 认证失败的原因比 Portal 更隐蔽，因为大部分交互发生在系统后台。终端日志里如果显示"认证超时"或者"RADIUS 服务器无响应"，问题的方向可能有好几个。

首先要确认接入交换机上 802.1X 是否已经开启，并且端口是否配置了正确的认证服务器 IP 和共享密钥。交换机上的 RADIUS 配置如果指向了错误的服务器或者密钥不匹配，认证报文发不出去，终端就会反复重试。

其次是终端侧的证书问题。如果认证方式选的是 EAP-TLS（证书认证），终端没有导入正确的客户端证书或者 CA 证书，服务端无法验证，认证就会失败。排查方法是查看 Windows 的"事件查看器"里 EAPHost 的相关日志，或者 mac 设备上 wireless diagnostics 的日志，里面会有认证失败的具体错误码。

还有一种情况是交换机和 RADIUS 服务器之间的网络连通性问题。RADIUS 用的是 UDP 1812 和 1813 端口，UDP 报文在某些网络中间设备上容易被丢弃。测试方法是从交换机上 ping RADIUS 服务器的 IP，如果能 ping 通，再用网络协议分析工具抓包确认 RADIUS 报文是否正常往返。

合规检查误判导致正常设备被隔离

合规检查是准入系统最容易产生误判的环节。最常见的误判场景有三个：补丁检查不匹配、杀毒软件识别错误、合规基线版本过期。

补丁检查误判通常是因为合规检查规则的更新滞后。Windows 每个月发布补丁，如果准入系统里的补丁基线没有及时更新，终端明明已经打了最新补丁，但系统不认。处理方法是检查合规基线规则的版本号，和终端实际安装的补丁列表做比对，找出哪些 KB 编号被遗漏了。

杀毒软件识别错误也常见——终端装了某厂商的 AV 产品，但准入系统 Agent 识别不出来，或者识别成了另一个版本。这种情况需要确认 Agent 的检测逻辑，是读注册表还是读进程列表，再查终端上 AV 的注册表 key 是否在检测范围之内。必要时可以联系厂商更新 Agent 的 AV 识别库。

如果合规检查大规模误判，临时应急处理方式不是关掉整个系统，而是把误判设备加入"临时豁免"列表，允许它正常接入，再逐一排查原因。很多运维团队在一开始碰到误判时选择了关掉合规检查模块，这是最不推荐的，因为合规检查一旦关掉，就很难再开起来。

交换机端口被锁定后设备无法恢复

在 802.1X 模式下，如果设备连续认证失败超过交换机配置的阈值，交换机会对端口执行安全动作——通常是 shutdown 或者将端口放入 Guest VLAN。问题是，端口一旦被锁定，即使终端修复了认证问题，也需要手动解除端口的锁定状态，终端不能自动恢复。

这个情况在系统上线初期最常见，因为认证策略还在调整，很多终端会触发失败阈值。处理流程是：先在交换机上查看端口状态和错误日志，确认是被 802.1X 安全策略锁定的；然后用适当的命令解除端口锁定；最后回到准入管理系统里排查该设备认证失败的原因，修复后再让设备重试。

为了避免类似问题反复出现，建议在 802.1X 配置中把最大重试次数设得宽松一些，把端口安全动作从 shutdown 改为发送告警但不断网。等认证策略稳定后，再收紧配置。

Agent 兼容性问题

准入系统的终端 Agent 需要安装在各种操作系统版本上——Windows 7/10/11、macOS 多版本、某些特殊 Linux 发行版。Agent 的兼容性问题是上线后最常见的故障来源之一。

常见的问题包括：Agent 安装后无法启动、启动后无法连接到管理服务器、Agent 占用过高 CPU 导致终端变慢、Agent 和其他安全软件冲突导致蓝屏。

排查 Agent 兼容性问题的第一步是查看 Agent 自身的日志文件，确认报错信息。其次是在该终端的应用列表里看看有没有安装了其他安全类软件，常见冲突的软件包括某些厂商的终端安全平台、加密软件、VPN 客户端。如果确认是冲突，需要把冲突程序加入准入系统 Agent 的排除列表，或者反过来把 Agent 加入其他安全软件的信任名单。

对于 CPU 占用过高的问题，通常是因为 Agent 在做全盘扫描或合规检查时计算量过大，应该检查 Agent 的配置里是否有相关扫描频率的设定，可以适当降低频率或者限定扫描时间窗口。

大规模认证风暴导致 RADIUS 服务不响应

这种情况通常发生在系统上线初期，或者某个断电/网络恢复事件之后——大量设备同时发起认证请求，RADIUS 服务器瞬间被打满，后续请求全部超时。

排查时先看 RADIUS 服务器的 CPU 和内存使用率，确认是资源不足还是参数配置问题。然后检查 RADIUS 服务器的最大并发连接数设置，这个参数通常默认比较保守，线上环境应该根据设备数量调整到合理值。

预防措施是开启认证风暴控制，比如对交换机配置认证请求速率限制，或者对认证服务器做负载均衡。但最有效的还是上线前做一次压测，按实际设备总量的 50% 模拟并发认证，确认 RADIUS 服务器能承受这个量级的压力。

网络准入认证系统的故障排查，靠的不是聪明，而是经验的积累和对网络协议的熟悉。把上面的几类典型问题摸清楚了，剩下的无非是具体环节的具体排查。