无线项目里有个高频误解：设备说明书上写着支持 Radius，就认为它能接外部认证系统。这两件事不等同。支持 Radius 只说明它能做认证后端的交互，不代表它有能力把用户跳转到第三方提供的认证页面，更不代表它能在认证通过后按平台下发的方式放通。把这两件事混为一谈，方案阶段看着没问题，实施阶段就会发现页面根本弹不出来，或者弹出来了但通过之后不放通。
要确认的是三种不同的能力
准确地说，要看三件事。认证后端能力：设备能不能把认证请求交给外部平台去校验。外部 Portal 能力：设备能不能把用户的访问重定向到第三方认证页面，并在用户提交之后把信息转给平台。放行控制能力：平台给出结果之后，设备能不能按这个结果执行放通、限速、断开。三件事缺一件，整套认证就跑不完整，而缺的那一件往往在文档里写得最含糊。
对接前必须问清的六项
按技术侧的硬规则，对接前要拿到六项信息：无线控制器的品牌、具体型号、是否支持外部 Portal 或者第三方 Portal 跳转、设备上是否已经启用了内置的 Portal 认证、项目需要对接哪些认证方式比如短信或者微信或者企业身份、现网的控制点是不是可用。这六项里最容易缺的是第三项和第四项，而它们恰恰决定了能不能接、需不需要先关掉设备自带的那套认证。
内置Portal是常见的冲突源
很多无线控制器自带一套简易的认证页面，管理员可能早就启用过。上外部系统时如果不把这套内置认证关掉或者调整优先级，就会出现两套页面打架：用户有时候弹内置页，有时候弹外部页，表现随机，非常难查。所以勘测时一定要看设备当前的实际运行状态，而不是看默认配置。这一项在改造类项目里尤其重要，因为设备可能已经运行多年，配置经过好几个人改过。
问法不对就会拿到错的答案
确认这项能力时，问法本身很关键。问设备支不支持 Radius，答案几乎总是支持，因为那是认证后端的能力。真正要问的是三件事：用户访问任意网页时，设备能不能把他引导到第三方提供的页面；用户在页面上提交之后，设备能不能把信息交给平台；平台给出结果后，设备能不能按结果执行放通和限制。把问题问到这个粒度，对方要么给出明确答复，要么需要回去查，两种结果都比一个含糊的支持有用得多。
信息不全时不能下结论
技术侧的判断规则很明确：品牌型号和外部 Portal 能力没确认之前，不能写支持对接、可以实现、架构适配这类结论。正确的输出是说明还需要确认哪些信息，或者给出条件式判断，比如理论上存在对接可能但要看外部 Portal 能力。这种克制不是推卸，而是避免把一个未验证的前提当成事实写进方案，后面验收时无从解释。
不支持时的三条路
如果确认设备不支持外部 Portal，通常有三条路。换掉这批无线控制器；在链路上增加可控的认证网关，由它承担拦截和放行的角色，无线控制器只管无线侧；或者改用设备自带的认证加本地账号，放弃统一管理。选哪条主要看两件事：项目对统一管理的要求到底有多硬，以及这批设备还剩多少使用年限。设备快到更新周期，换掉反而干脆；设备还很新，加网关更划算。
型号比品牌更重要
同一个品牌不同型号的能力可能完全不同，甚至同一型号不同固件版本也有差别。所以收集信息时要具体到型号和固件版本，不能只写个品牌。勘测清单里建议把这两项做成必填，设备多的时候可以分批收，但关键区域的设备必须先收齐。老设备还要确认厂商是否还在维护，能不能升级固件，因为有些外部 Portal 能力是后续版本才有的。
验证方式要落到真机
确认能力这件事不能只看文档或者界面上的开关。最可靠的验证是拿一台真机、一个测试账号，在真实网络里走一遍完整的认证流程：连上无线信号、页面自动弹出、填写并完成认证、认证通过后能上网、管理员执行下线后终端断开。五步全通过才算这套对接成立。只完成前两步就认为对接成功，后面三步的问题会在上线后集中爆发。
多品牌混合时怎么管
存量改造经常遇到新旧设备混用，能力参差不齐。这种情况下不要指望所有设备用同一种对接方式，可以按区域分开：核心区域用支持标准对接的设备，边缘区域或者老设备区域采用网关旁路的方式兜住。关键是要在拓扑图和管理台账上标明每片区域用的是哪条路径，否则后期排障时没人说得清某个区域到底走的是哪种对接。
把确认结果写进交付文档
最后一步常被省略：把勘测和验证的结果整理成文档，写清每台设备的型号、固件、支持的能力项、实际采用的对接方式、验证结论。这份文档的价值在一年后才会显现，那时候可能要扩容、要换设备、或者要排查一个诡异的故障，有这份底账就能快速定位，不用从头再摸一遍。它也是验收材料的一部分，双方都认。