超时发生在哪一轮
802.1X 认证偶发超时或恢复慢，典型画面是「第一次连不上、重试就好」或「漫游到另一个 AP 就失败」。EAP 报文要在终端、AP/控制器、RADIUS 之间来回好几轮，任何一段的超时与重传参数不匹配，都会让某一轮悄悄丢掉再重来。调参的前提是先测出正常时各段的响应耗时，而不是凭感觉把超时往大里加。
基本信息
| 典型现象 | 首连超时、重试成功；漫游到新 AP 时偶发失败 |
|---|---|
| 参数分布 | 终端 EAP 超时、AP/AC 超时与重传、RADIUS 超时 |
| 核对方法 | 各段超时值与实测 P95 响应时间逐项对比 |
| 调整原则 | 服务器慢先优化服务器，再考虑放大客户端超时 |
| 关键点 | 超时值应显著大于正常响应时间的 P95 |
典型使用场景
- 员工反馈 Wi-Fi 图标转圈半天才连上，重连一次即好
- 跨 AP 漫游时偶发认证失败，抓包可见 EAP 重传
- 更换 RADIUS 服务器或迁移 AD 后认证整体变慢
- 员工与访客共用认证组件，高峰期超时比例上升
- 需要区分「认证超时」与「凭据或配置错误」
核对顺序
核对顺序
# 终端侧：查 802.1X 客户端日志里的 EAP 重传与超时次数
# 控制器侧：核对 EAP 超时、最大重传次数配置
# RADIUS 侧：统计 Access-Challenge/Accept 的响应耗时分布
# 对比：超时阈值应显著大于正常 P95，通常留 2~3 倍余量参数位置对照
| 位置 | 参数类型 | 调大后的影响 |
|---|---|---|
| 终端 | EAP 超时、重传次数 | 失败判定变慢，用户等待更久 |
| AP/AC | EAP 超时、认证帧重传 | 掩盖上游慢的问题 |
| RADIUS | 上游超时、重传 | 请求堆积，连累其他客户端 |
| 账号服务器 | 连接池与查询超时 | 根治性手段，优先动这里 |
先把一切正常时的认证耗时测出来当基线，再决定超时取多少；没有基线的调参等于在猜，改完也不知道是变好还是变坏。
超时的表现形式在各系统不一致：Windows 会明确报 802.1X 超时，Android 往往只显示「认证失败」，先看客户端与 RADIUS 两侧日志再定性。
盲目放大超时阈值会把真实的服务器性能问题藏起来：用户等 30 秒最后还是失败，体验反而更差。优先查 RADIUS 与账号系统的响应时间。