批量环境里最容易出的问题，是所有应用共用同一条出口。在大白加速器里把不同应用分别指到不同线路上，是把代理IP线路的用量和业务负载对上号的基础做法。本篇按”先列清单，再建分组，最后逐项验证”的顺序讲大白加速器的多应用出口指定，代理IP线路的分组结果同时决定后续统计口径好不好做。
三步指定与两类收尾检查
第一步是把应用清单列全。软件里能看到的应用只是当时在运行的，历史用过但当前没开的应用容易漏，漏掉的结果是它默认走原始出口，和业务预期不一致。清单建议直接从任务的窗口列表里导出，比手工回忆可靠。
第二步是在软件里建应用分组，而不是逐条给应用配线路。分组的意义在于一次维护多处生效：同一类业务用同一条线路，换线路时只改分组绑定，不用挨个改应用。分组名建议直接用业务用途命名，别用线路名命名，否则换线路之后名字就错了。
第三步是逐项验证。这一步的常见错误是只看软件里显示”已连接”，不去确认实际出口。正确做法是分组里随机抽两三个应用，跑一次真实业务请求，检查出口归属与预期分组是否一致。抽验的数量按分组规模定，一般小分组抽一个就够，大分组抽两到三个。验证记录要落到分组层面，写”某分组已抽验通过”，而不是逐个应用打勾，否则下次改动后不知道该重验哪些。
收尾两类检查：一是默认线路检查，确认软件里没有指定分组的应用走的是可接受的默认出口；二是重启检查，软件重启后分组绑定的还原情况要在真实环境里确认一次，个别版本对自定义配置项的还原不一致。这两项做完，多应用出口指定才算是稳定可用的状态。
后续维护中，分组要随业务变化调整。新业务接入时先判断它归到哪一组，而不是给它单开一条线路；线路数量膨胀会让绑定关系难以核对，批量环境的经验是线路分组数量控制在个位数，比线路本身的数量更值得约束。业务增长后先扩容分组内的线路，而不是新建分组，这个顺序能减少配置项数量失控。
统计口径也要跟着分组走。出口归属的核对、异常影响的评估，都按分组来做，这样从软件到台账的命名能对齐。多应用出口指定这件事，一半是配置，一半是命名一致，命名不一致的分组，代理IP线路用久了就说不清哪条给谁用了。
问：同一个应用出现在两个分组里会怎样？
以软件里生效次序靠前的分组为准，但不同应用不会提示冲突，属于隐性配置错误。建议每个应用只归一个分组，并在建组时用导出清单核对一次，避免重复归属。
问：指定出口后业务变慢，先查什么？
先查指定线路的并发占用，再查应用所在分组是否有多个高并发应用同用一条线路。多应用出口指定解决的是归属问题，不解决容量问题，容量要单独按线路做限制。