不少场所的网络出口不止一条，有的接了多家运营商的宽带，有的是主备两条专线。多出口能提升带宽和可靠性，但它会给 Portal 认证系统带来一个额外的问题：认证相关的流量到底走哪条线，走错了会怎样。这个问题在单出口环境下不存在，在多出口环境下如果不专门处理，就会出现用户认证时好时坏、怎么查都查不出规律的怪现象。
认证流量和上网流量要分开看
首先需要区分两类流量。一类是用户上网产生的业务流量，它可以按策略分摊到不同出口，走哪条都行。另一类是认证相关的流量，包括用户终端访问认证页面的请求、接入设备与认证平台之间的交互、以及平台下发的放行和策略指令。后一类流量对路径的稳定性要求高得多，它一旦走了不稳定的路径或者来回变，认证就会失败或者变慢。两类流量不应该用同一套策略。
路径来回变是最大的隐患
多出口环境下最常见的故障模式是路径不一致。用户的请求从一条线路出去，回应从另一条线路回来，或者有段时间走这条、过段时间走那条。对于普通上网流量，这种不对称通常不影响体验，但对认证这类有状态的交互，路径变化可能让平台看到的来源地址和之前不一致，会话就对不上了。表现出来的现象是有些用户能认证、有些不能，或者同一个人重试几次就成功了，非常有迷惑性。
给认证流量固定出口
最稳妥的处理方式是把认证相关的流量绑定到固定的出口上。具体做法是在出口策略里，把认证平台的地址、以及接入设备与平台交互涉及的地址，指定走一条固定的线路。这样无论业务流量怎么分担，认证这条路径始终是稳定的。绑定之后要验证：在这条线路正常时认证正常，在其他线路切换或者抖动时认证不受影响。这个验证要主动做，不能等故障来验证。
主备切换时要考虑会话
多出口通常带主备或者负载分担机制，配合线路质量检测做选路。这里要注意切换对已建立会话的影响：线路切换之后，在线用户的会话会不会中断、需不需要重新认证、重新认证时会不会因为并发突然升高而冲击系统。这些都要在配置阶段确认和验证。如果切换会导致大量用户同时重新认证，就要评估那个瞬时压力系统扛不扛得住，扛不住就要考虑错开切换或者提前主动切换。
切换阈值要结合实际质量
线路质量检测是选路的基础，但检测什么、多久检测一次、达到什么条件切换，这些参数要结合实际情况来定。检测太频繁会给链路本身增加负担，检测太稀疏则发现不了短暂的劣化。切换阈值定得太敏感，会导致线路频繁来回切，而每次切换都可能影响在线用户；定得太迟钝，线路已经很差了还不切，用户体验先崩。参数要在线路实际的波动范围内调，不能照抄默认值。
备份链路要预留带宽
多出口环境下容易忽略的一点是备份链路的容量。很多项目的备线带宽明显小于主线，平时分流没问题，一旦主线故障全部流量压到备线上，备线直接被打满，结果比单出口还糟。所以设计时要明确：主线故障后，备线需要承载多少流量，是全量还是只保关键业务。如果只能保关键业务，就要提前配好降级策略，让非关键流量在主线故障时受限而不是把所有流量一起挤爆备线。
验收时要专门测切换
多出口的项目，验收清单里一定要有切换测试这一项：人为让主线路不可用，观察系统是否按预期切换、认证是否依然正常、在线用户受到多大影响、恢复之后是否能自动切回。这个测试看起来简单，但它能一次性暴露选路策略、会话处理、带宽预留这几方面的配置问题。不做这项测试，这些问题会一直埋着，直到某次真实的线路故障一起爆发。
认证平台地址要在所有出口都可达
多出口环境里有个必须验证的前提：认证平台的地址，从每一条出口出去都要能访问到。如果因为策略配置的原因，平台地址只能从某一条线路访问，那么这条线路一旦故障，认证就整体失效，多出口的可靠性优势完全失效。云端部署的平台还要额外确认它的公网可达性，不同运营商线路访问同一个公网地址的稳定性可能有差异，这个差异要在部署前实测而不是假设。
多出口下的日志和追溯
最后要提醒一件容易被漏掉的事：多出口会影响日志的完整性。同一批用户的流量可能从不同出口出去，不同出口上的地址转换记录各不相同。如果后续要做上网行为追溯，必须把用户、时间、地址、端口和出口信息一起记录并且在事后能对上，否则查到一半发现两段的记录对不起来，追溯就断了。这一项在设计阶段提出来成本很低，上线之后再补会很麻烦。