选WiFi认证系统的时候，几乎每个供应商都会提到两种认证方式：portal门户认证和RADIUS 802.1X认证。很多人分不清两者的区别，也不确定自己的场景该选哪个。其实这不是一道非此即彼的题，更多是要看现有网络基础和运营能力。

Portal门户认证的工作方式

Portal是商用场景中最普遍的认证方式。用户连上WiFi后，不管打开什么网页都会被重定向到一个登录页面，输入手机号获取短信验证码，提交后网关放行该设备的流量。

好处是对客户端几乎没有要求，任何能跑浏览器的设备都可以完成认证，不需要装额外软件，不需要特殊配置。酒店、咖啡馆、商场这类用户设备类型杂、技术水平参差不齐的场景，portal几乎是默认选项。部署也相对简单，大部分情况下只需要在网络出口部署一台认证网关，对现有无线设备影响最小。

但portal的安全性和可控性有限。因为认证发生在应用层，攻击面比较大——存在钓鱼门户的风险（恶意AP伪造同名SSID引导用户到假登录页），会话劫持的可能性也比底层认证方式高一些。另外portal做不到精细化的接入控制，要么认证过全部放行，要么没认证全部阻断，很难基于用户身份做差异化的网络权限分配。

RADIUS 802.1X的工作方式

RADIUS是基于网络层的认证协议，工作在链路层。设备连接WiFi时，AP会先拦截它的网络访问请求并启动EAP握手，向RADIUS服务器验证用户身份，通过后才允许设备进入数据网络。

这种方式的安全性明显高于portal。认证发生在设备联网之前，未通过认证的设备拿不到IP地址，不存在绕过门户直接上网的可能。同时RADIUS天然支持基于身份的策略控制，不同用户组可以分配不同VLAN、不同带宽上限、不同访问ACL。企业办公园区、学校教学网这类需要精细化管理网络权限的场景，802.1X的优势很明显。

选择时的现实考量

RADIUS的门槛不低。AP和交换机必须支持802.1X，老建筑里可能需要更换相当一部分无线设备。客户端兼容性也是问题：Windows和macOS原生支持比较好，但一些老旧手机型号或者智能设备（智能电视、游戏机、IoT传感器）可能完全不支持802.1X，需要配一套MAB策略来兜底，这又增加了运维复杂度。

出了问题之后排查也更麻烦。portal模式下大部分问题集中在网关一层，看日志基本能定位；而802.1X的问题可能分布在认证服务器、交换机、AP、客户端任意一端，需要同时对多份日志做关联分析才能找到根因。

实际项目里，选择逻辑通常是这样的：如果主要是公众开放场景，用户群体不可控且设备类型多样，优先portal；如果是有明确组织边界的场景，终端设备相对可控且有IT运维团队支撑，802.1X值得投入。也有混合部署的做法，员工用802.1X、访客用portal，两套并存互不干扰。

选WiFi认证系统不用纠结哪种方式更好，而是要搞清楚自己网络的现状是什么、未来几年有没有升级计划、运维团队能不能撑住对应方案的日常维护成本。这些问题的答案比功能列表上的参数更有用。