RADIUS协议在Wi-Fi认证场景里已经用了很多年，成熟度很高，但在实际项目中，把WiFi网络认证系统和RADIUS服务对接的过程里，出问题的频率依然不低。大部分问题不是RADIUS协议本身的问题，而是配置细节、网络环境、设备兼容性的问题。这些问题不难解决，但如果不熟悉常见套路，排查起来会很费时。

RADIUS在认证流程里的位置

在典型的部署架构里，无线接入设备（AP或AC）充当RADIUS客户端，WiFi网络认证系统的服务端充当RADIUS服务器。用户连上Wi-Fi后，AP把认证请求封装成RADIUS Access-Request报文发给认证服务器，服务器验证用户信息后返回Access-Accept或Access-Reject，AP根据返回结果决定是否允许用户联网。

这个流程看起来简单，但每个环节都有可能出问题。AC/AP的RADIUS配置、shared secret、接口地址、端口号、超时重试参数，任何一个不对都会导致认证失败，而且失败的现象看起来很相似，都是"认证不通过"或"认证超时"。

Shared Secret配置错误

Shared Secret是RADIUS客户端和服务器之间的共享密钥，用于对报文做签名验证。配置错误是最常见的问题之一，而且现象不够直观——从AP侧看，认证请求发出去了，但没有收到响应；从服务器侧看，收到了报文但验签失败，直接丢弃，不返回任何错误信息。

排查方法：在RADIUS服务器上打开调试日志，查看是否有"Received invalid authenticator"或类似的日志。如果有，确认AP侧的shared secret和服务器侧的配置完全一致，注意区分大小写，注意是否有空格或不可见字符混入（从某些管理界面复制粘贴时容易出现）。

RADIUS服务端口的问题

RADIUS标准端口是1812（认证）和1813（计费）。但有些老设备或定制化设备使用1645/1646这组端口，有些服务端也允许配置非标准端口。如果AP配置的端口和服务器监听的端口不一致，认证请求打出去了但没人接，超时后显示认证失败。

确认方法：在服务器上执行netstat或ss命令，查看RADIUS服务实际监听的端口；在AP管理界面确认配置的RADIUS服务器IP和端口；用tcpdump或抓包工具确认AP发出的报文到达了服务器的正确端口。

网络防火墙的拦截问题

RADIUS服务器通常在内网，但认证请求可能跨越了防火墙或安全策略边界。防火墙策略没有放开RADIUS端口的UDP流量是常见问题，尤其是在云端部署的认证服务器，安全组规则里很容易忽略UDP 1812/1813端口。

排查时要从AP到RADIUS服务器的整条链路检查防火墙规则，包括AP所在网段的出站规则、RADIUS服务器所在网段的入站规则、以及中间任何网络设备的ACL。RADIUS用UDP协议，有些防火墙的UDP超时设置很短，长时间没有流量时会把"连接"状态清除，下一个认证请求需要重新建立，可能导致第一个请求超时。

NAS-IP-Address和客户端白名单

RADIUS服务器通常会维护一个客户端白名单（NAS列表），只响应白名单内IP发来的请求。如果AP的IP不在这个白名单里，服务器会直接丢弃请求，不返回任何错误，现象和端口不通一样。

多AP部署时，这个问题更容易出现：项目里增加了新的AP或AC，IP变了，但RADIUS服务器的客户端白名单没有更新，导致部分设备无法认证。维护一个清晰的RADIUS客户端IP清单，并在网络设备变更时同步更新，是避免这类问题的有效手段。

属性不匹配和厂商扩展属性

RADIUS协议定义了标准属性（Attributes），但各厂商也有自己的扩展属性（Vendor-Specific Attributes，VSA）。当WiFi网络认证系统需要通过RADIUS传递一些额外信息（比如带宽限制、VLAN ID、上网时长限制）时，通常需要用到VSA。

问题在于：AP厂商A定义的VSA，在AP厂商B的设备上可能是另一个属性ID，甚至不被支持。如果认证系统发送了AP不认识的VSA，AP会直接忽略，不会报错，但预期的带宽限制或VLAN分配也不会生效。这类问题很难通过简单测试发现，需要专门验证每个功能点的实际效果。

排查方法：在认证服务器开启完整的报文日志，查看Access-Accept里包含了哪些属性和VSA；对照AP厂商的文档，确认AP能识别并处理这些属性；在测试环境里用一个账号验证带宽限制、VLAN分配等功能是否实际生效。

RADIUS计费（Accounting）的配置问题

计费是RADIUS除认证之外的另一个主要功能。AP在用户上线后、下线后、以及定期（Interim Update）都会向RADIUS服务器发送计费报文，服务器用这些报文记录用户的上网时长和流量。

计费配置的常见问题：一是AP的计费服务器地址配置错误或没有配置，导致只有认证记录没有计费记录，上网时长和流量统计不准；二是Interim Update间隔设置不合理，间隔太长会导致用户掉线但计费记录显示还在线，计费数据和实际不符；三是计费端口和认证端口混淆，把认证请求发到了计费端口，或反之。

并发认证场景下的性能问题

大型场所在高峰期（早晨开门/下课/入住高峰）认证请求量会集中爆发。如果RADIUS服务器的处理能力不足，会出现认证延迟甚至超时。AP的RADIUS超时重传机制会在超时后重发请求，大量重发又会进一步加剧服务器负担，形成恶性循环。

排查并发性能问题时，要关注RADIUS服务器的CPU和内存使用率、数据库查询延迟（账号验证通常需要查数据库）、以及AP侧的认证超时计数。如果发现是数据库查询慢导致的认证延迟，优先排查数据库索引是否完整（用户名、手机号字段必须有索引），以及连接池配置是否合理。

RADIUS对接的问题大多数不难解决，但需要系统性的排查思路。从IP连通性、端口连通性、Shared Secret、客户端白名单、属性配置这个顺序逐层排查，大多数问题都能在较短时间内定位。遇到复杂问题时，抓包是最直接的诊断手段，不要依赖设备界面上显示的模糊错误信息。