Portal 认证的三种部署架构：旁挂、串联与网关内置怎么选

同一套 Portal 协议，落到不同部署位置，能力差别很大。选错形态，认证能过但用起来别扭。

一、三种形态

二、选型判据

要计费与流量统计、需要 NAT 与出口管控 → 串联或网关内置；只想做准入与可追溯、且不能接受网关单点 → 旁挂；要微信连 WiFi、短信、会员打通等复杂能力 → 必须有独立 Portal 服务器（旁挂或串联外挂均可）；小型场所不想额外采购 → 内置式先跑起来，但账号规模与并发有限。

三、故障域影响

旁挂式的价值就在这里：认证服务器或盒子挂了，终端仍可出网（若策略是 fail-open），可用性最高，但要注意别让旁挂失效变成「全网无认证可进」的隐患——应有本地策略兜底。串联式把认证和出口绑在一起，认证侧异常会直接表现为「访客连不上网」，所以认证服务器要做双机或至少部署在稳定环境、并有本地兜底策略。

四、混合部署建议

大型站点常见做法：员工与办公走交换机/AC 内置或旁挂的 802.1X，访客走独立 Portal 服务器的串联网关，两者地址与策略完全隔离，日志汇总到同一平台。设计时把「谁是唯一出口」「谁是唯一认证入口」写清楚，避免出现双出口、账号两套、账单两本的问题。

五、混合部署：把「唯一出口」和「唯一认证入口」写清楚

大型站点最常见的组合是：员工与办公走接入设备侧的 802.1X（可旁挂），访客走独立 Portal 服务器串联网关；两者地址段完全隔离，日志汇总到同一平台。设计文档里必须写明三件事：谁是唯一出口（避免双出口导致策略分叉）、谁是唯一认证入口（避免两套账号两本账）、故障时各走什么降级策略。

六、选型决策的四个问题

① 要不要按流量计费？（要 → 串联）② 认证侧故障时能不能接受访客断网？（不能 → 旁挂 + fail-open，但要配合隔离）③ 需要微信/短信/会员打通吗？（需要 → 必须独立 Portal 服务器）④ 峰值并发多少人？（百人以内可评估内置式，千人以上建议独立服务器 + 负载）。四个问题答完，形态自然定下来。