Summary

  • RADEXT 工作草案拟将 RFC 7930实验性引入的 RADIUS Protocol-Error（数据包类型 52）标准化。IANA 登记表目前仍指向 RFC 7930。
  • 错误包必须带 Error-Cause 和 Original-Packet-Code。后者在不同请求类型复用相同 Identifier 时，帮助客户端认出真正出错的那一项。
  • 错误只管相邻一跳。代理收到原因码 502 或 505 时，应尝试另一条连接或目标；草案禁止把重试发回刚失败的同一条连接。

RADIUS 长期让接入设备面对一种不舒服的沉默。认证服务器可以接受、拒绝，也可以不回答。超时后，接入设备很难知道服务器正忙、请求本身有问题，还是代理链更远处断了。它只好照本地规则再试。各家系统各猜各的，故障时额外请求却常常一起涌向已经拥堵的路径。

草案第 00 版想让服务器明确说一句：请求到了，但我处理不了。Protocol-Error 能回应认证、计费、变更授权和断开连接等请求。计费系统写不进记录时，回一条处理错误，比装作交易已经入账更诚实；认证路径出了协议故障时，也不必把技术故障伪装成用户被拒绝。草案把 2016 年 RFC 7930 中的实验性 Code 52 提出来单独定义。IANA 现行登记仍保留原来的 RFC 指向，这一步尚未完成。

两项属性把错误落到具体请求上。Error-Cause 写原因，Original-Packet-Code 写发出请求时的数据包类型。RADIUS 的 Identifier 数值可以在不同请求类型中重复；只看同一个数字，可能把计费错误挂在认证请求上。错误响应还复制原请求的 Identifier。若原始数据包类型对不上任何未完成请求，草案要求客户端丢弃该响应。一张写得很清楚却贴错工单的故障单，会让自动重试走错门。

代理的下游坏了，不能让上游替它猜

草案第 4 节把 Code 52 明确为逐跳消息。代理不能直接转发收到的错误。它必须先看原因码，判断问题属于代理网络，还是来自归属服务器。这不是挑剔措辞：代理控制着自己通往下一跳的连接，而接入设备只知道它把请求交给了这个代理。两段关系的维修责任由不同的人承担。

草案点名两个代理网络原因：502 Request Not Routable (Proxy)，以及 505 Other Proxy Processing Error。收到这两种错误，代理应考虑换一条连接去同一目的地，或换一个目的地；重试不能走刚刚失败的原连接。这个限制给“自动恢复”装上刹车。若软件只是高速地把同一请求送回同一死路，仪表盘会显示它很努力，队列和带宽却在为这份努力买单。草案没有替运营方设定完整的故障切换策略；尝试次数、超时时间和备用路由仍要在部署中说清。

其他原因码通常应按归属服务器故障处理。代理向自己的客户端发出一条新的 Protocol-Error，带上相应原因。这与转发下游原包不同：代理交代的是它在本跳观察并处理后的结果。一次排障记录因此应同时显示原请求、下游原因、代理决策和接入设备最终收到的答复。错误包说明处理失败发生在哪里；它不会替最后一跳作出“用户已认证”或“计费已写入”的结论。

草案的迁移、协商与何时选择这种响应等段落仍留着 TBD。官方文件也没有跨两级代理的部署跟踪。下一份有用的证据，是受控测试里每一跳的请求类型和 Identifier、502/505 的处理、被避开的连接、新路由，以及接入设备最终动作。那份记录能证明协议里的责任分工是否真的落到了运行系统。

RADEXT 草案 · Datatracker 状态 · RFC 7930 · IANA RADIUS 登记表