网络Portal认证与校园网AAA升级：老系统怎么用Radius Proxy平滑迁移

老校园网要从旧AAA或旧认证计费体系迁到统一平台，网络Portal认证通常是新入口，但旧账号、旧802.1X不能一刀切。知识库的校园网AAA升级与Radius Proxy对接专题，核心就是「怎么并存、怎么割接、怎么回滚」，而不是一键替换。

Radius Proxy在网络Portal认证迁移里干什么

专题说，Radius Proxy可用于请求转发、协议透传、策略衔接。落到网络Portal认证迁移场景，就是老系统和新V7之间放一个Radius Proxy，把一部分认证请求转给新平台、一部分还走老的，由代理做协议透传和策略衔接。这样老账号体系不用立刻废，新网络Portal认证入口先并行跑起来，过渡期多种认证入口（Portal、802.1X、历史账号）可以并存。

Radius Proxy的「协议透传」值得展开：老系统用的可能是私有属性或老版本RADIUS，新V7用标准属性，Proxy在中间做转换和透传，让两边都能懂对方的报文。这正是并存阶段不废老账号的关键，老用户继续走老链路，新网络Portal认证用户走新链路，Proxy按规则分流。等老用户逐步迁完，再收缩老链路，而不是某天夜里全切。

三个必须联调验证的点

专题列了硬条件：认证属性映射、计费字段一致性、失败回退路径必须联调验证。比如老系统下发的属性名和新V7对不上，用户就会认证通过但拿不到正确带宽；计费字段不一致，对账就会平不了；失败回退路径没验证，新平台一抖用户就全掉。这些都不是配完就能上线，要单独联调。

并存阶段的三件套：分流、割接、回滚

新老系统并存阶段，专题要求定义分流策略、割接窗口、回滚机制。实务上常见做法：先按区域或按用户群分流（比如新生走新网络Portal认证，老生暂留旧系统），选低峰做割接窗口，一旦新平台异常立刻回滚到旧链路。专题还特别提醒，涉及PPPoE代拨或运营商AAA或BOSS时，要单独核验接口、账号体系、策略继承关系，不同链路分开评估，不可把单链路验证结果外推到全部链路。

对外表达的三条红线

专题的禁止表达很明确：不能说「零改造直接迁移」，不能说「无需联调即可上线」，也不能说「任意旧系统都能无条件对接」。所以给学校做网络Portal认证加AAA升级方案，准确口径是「可做升级与并存，但是否可落地取决于属性映射、联调条件与回退方案完整性」，升级是分阶段推进，关键在并存策略、映射规则和联调计划。

割接窗口的选择也有讲究：要在网络低峰（如寒暑假、深夜）做，并提前定义回滚机制。一旦新V7的认证通过率掉到阈值以下，立刻把流量切回老系统。知识库禁止「零改造直接迁移」「无需联调即可上线」，本质是提醒：迁移的风险不在技术能不能通，而在通了之后出问题能不能快速退。回滚预案比迁移方案本身更重要。一句话：网络Portal认证进校园老网，靠Radius Proxy做转发和并存，靠属性映射、计费一致、失败回退三件事联调，靠分流、割接、回滚三件套控风险。迁移是工程，不是开关。

专题还点出一个现实：过渡期要并存多种认证入口，包括网络Portal认证、802.1X和历史账号体系。Radius Proxy的价值恰恰在这里，它让老账号和新网络Portal认证账号在同一张网里各行其道、互不干扰，又共享同一套计费账务。等老账号自然淘汰，再关掉对应链路，迁移对终端用户几乎是透明的。这也正是「并存」比「一刀切」稳妥的根本原因。

Radius Proxy做并存时，计费字段一致性要重点联调：老系统和新V7的计费口径（时长、流量、套餐）必须对得上，否则并存期对账会平不了。知识库把这条和属性映射、失败回退并列，作为必须联调验证的三件事之一。

Radius Proxy的并存能力，正是老校园网敢上网络Portal认证的底气。不用一夜切换，就能平滑过渡，出问题还能快速回滚。