RADIUS协议是网络计费系统中最基础的认证计费协议，几乎所有网络接入控制设备都支持它。但RADIUS的工作机制看似简单，实际排错时却经常让人头疼。一个用户上不了网，可能是认证服务器的问题，可能是网络设备的问题，也可能是计费策略配置的问题。不搞清楚RADIUS的完整工作流程，排错就只能靠猜。

一、RADIUS认证的三次握手到底在做什么

用户输入账号密码点击连接时，网络接入设备（比如AC或BRAS）会向RADIUS服务器发送一个Access-Request报文，里面包含用户名、加密后的密码、NAS-IP-Address、Called-Station-Id等信息。RADIUS服务器收到请求后，查询用户数据库验证账号密码。验证通过则返回Access-Accept，不通过返回Access-Reject。

Access-Accept报文里不只是简单的"通过"信号，还携带了授权信息，比如分配的IP地址、带宽限速策略、会话超时时间等。这些属性叫RADIUS属性，是计费策略落地的关键。很多排错场景中，用户认证通过了但带宽策略没生效，问题就出在Access-Accept里的属性没配对，或者网络设备不支持某个属性。

二、计费报文：开始、中间和结束

认证通过后，网络设备会向RADIUS服务器发送Accounting-Start报文，表示用户开始上网。用户在线期间，设备会定期发送Accounting-Interim报文，报告当前会话的时长和流量。用户下线时，设备发送Accounting-Stop报文，报告最终的使用量。

这三个报文构成了计费的基础数据。计费系统根据这些报文计算用户的费用和流量消耗。排错时最常见的问题是Accounting-Interim报文丢失或延迟。如果中间报文丢了，计费系统记录的流量就会跟实际有偏差。用户觉得自己只用了5GB，系统显示用了8GB，投诉就来了。

另一个常见问题是Accounting-Stop报文没发出来。用户突然断网（比如拔网线、关电脑），设备可能来不及发送Stop报文。计费系统不知道用户已经下线，继续计算时长，用户下次登录时发现账号还在使用中，无法登录。这种"僵尸会话"是运维团队最头疼的问题之一。

三、排错的基本路径

用户报故障说上不了网，排错的第一步是看RADIUS服务器有没有收到认证请求。如果服务器没收到请求，问题在网络设备到服务器之间的网络链路，或者设备上的RADIUS配置有误。检查设备的RADIUS服务器地址、共享密钥、认证端口是否配对。

如果服务器收到了请求但返回了Reject，看Reject的原因。最常见的是密码错误、账号过期、账号余额不足。如果是账号余额不足，但用户说自己刚充了值，检查计费系统的充值到账延迟。有些支付渠道的回调有延迟，钱扣了但系统还没更新余额。

如果服务器返回了Accept但用户还是上不了网，问题大概率在网络设备侧。设备可能不支持服务器下发的某个属性，或者本地策略跟RADIUS下发的策略冲突。抓包看Access-Accept报文的具体内容，逐个属性核对设备的支持情况。

四、共享密钥和报文格式的坑

RADIUS报文用共享密钥做认证和加密。网络设备和RADIUS服务器两端的共享密钥必须完全一致，否则报文会被丢弃。这个看起来很简单的问题，在实际部署中经常出错。原因是密钥里可能包含特殊字符，在不同设备的配置界面里转义方式不一样。一个密钥里有感叹号，在设备A上直接输入就行，在设备B上需要加引号或反斜杠。

报文格式问题更隐蔽。有些网络设备在发送Access-Request时，Called-Station-Id字段的格式是MAC地址加SSID，比如"00-11-22-33-44-55:网络名称"。但RADIUS服务器期望的格式可能是"001122334455"。格式不匹配时，服务器无法正确识别用户来源，可能直接返回Reject。这种问题在跨厂商设备对接时特别常见。

五、日志是排错的最终武器

RADIUS服务器的认证日志和计费日志是排错的核心依据。好的计费系统会记录每一条请求的完整报文，包括请求时间、来源IP、用户名、返回结果和耗时。排错时按照时间线追踪一个用户的完整认证流程，基本能定位到问题出在哪个环节。

但有些计费系统的日志不够详细，只记录了通过或拒绝的结果，没有记录具体原因。运维人员看到日志里一堆Reject，但不知道为什么被拒。这种情况只能靠抓包来分析，效率很低。选型时一定要关注日志的详细程度，这是运维效率的决定性因素。

RADIUS不是一个复杂协议，但它的排错难度在于涉及的环节多。从用户终端到网络设备到RADIUS服务器到后端数据库，任何一个环节出问题都会导致认证失败。养成"按链路逐段排查"的习惯，比盲目重启设备有效得多。