代拨网关是整套系统的咽喉

在校园WiFi计费体系里，代拨网关不是一个边角料设备，而是整套系统里最关键的节点。它一头对接运营商的BRAS，一头连接校园内网，所有学生的上网请求都要经过它。

这个位置决定了它的性能上限和稳定性下限，直接影响学生体验、计费准确性和运维工作量。但这个设备选型的时候，很多学校的IT部门不一定有足够的判断依据。

有几个关键参数，选型的时候要逐项确认清楚。

并发用户数，不是写出来好看的数字

供应商的方案里，代拨网关的并发数字很好看——"支持5万并发""支持10万并发"。但这个数字是怎么测出来的，有没有在真实校园网环境里跑过，要打个问号。

并发用户数不是网关能连多少个设备，而是能同时维持多少个有效的PPPoE代拨会话。学生在宿舍用网高峰期，可能一个账号带2-3台设备，但真正耗性能的是NAT转换和日志记录，每一个会话都要占用内存和CPU资源。

建议在合同里要求做一次真实的压力测试，或者让供应商提供同量级学校的案例来核实。上了线以后再发现并发撑不住，要么扩容成本高，要么就得忍着用卡顿的网络。

代拨成功率，99%和99.9%差很远

代拨成功率和代拨稳定性是两个概念。有些设备能代拨成功，但代拨质量不稳定，学生上网过程中莫名其妙断线重拨，体验很差。

运营商BRAS的认证机制各家有差异，网关能不能吃透这些差异、跨运营商访问的时候路由策略怎么走，这些都是影响成功率的因素。

代拨成功率低于预期的时候，学生投诉会非常集中——"我的账号明明没欠费，为什么连不上"——这类问题排查起来比想象中麻烦，因为不是单点故障，而是系统性的处理能力不足。

选型的时候要让供应商提供实测数据，并且问清楚代拨质量波动的根本原因是什么，是设备性能瓶颈、BRAS对接问题，还是路由策略配置问题。

防私接模块，靠谱和不靠谱的差别很大

校园网里的防私接是个老问题，主要诉求是把"一个账号带多台设备"和"用路由器做代理"这两种行为识别出来并处理掉。

低端产品的防私接逻辑很简单，看终端数量，超过N台就阻断。但学生有合理的用网需求——一台手机加一台电脑，这是正常需求。防私接误判会把正常用户阻断，学生投诉、运维人员被追问，士气受损。

好一点的网关会用多维度检测：TTL值、包头特征、应用层协议特征、Cookie检测等等，综合判断是不是真实用户在用网，而不是路由器在跑代理。识别准确率和误判率这两个指标，选型的时候要拿到具体数字。

还有一个维度是检测频率。网关多久检测一次，是固定时间间隔还是持续监控，这个参数影响的是响应速度——出了问题能不能秒级阻断，还是等几分钟才反应过来。

日志留存，合规要求和实际能力要匹配

《网络安全法》对上网日志留存的要求是180天起。等保2.0对校园网场景有更细化的要求，具体天数和字段完整性各地略有差异。

网关本身一般不具备大规模日志存储能力，所以要配独立的日志审计系统。这个系统能不能对接代拨网关的日志输出格式、日志字段够不够完整、查询响应速度怎么样，这些是硬指标。

有些供应商的方案里把日志审计当作"增值模块"单独报价，选型的时候要把这部分成本算进去。如果日志审计能力不达标，上线以后被监管检查卡住，代价更大。

能不能和现有网络设备做对接

校园网的出口侧一般已经有BRAS设备，有的是运营商提供的，有的是学校自建的。新上的代拨网关能不能对接这些既有设备，有几种接入方式：

串联模式：网关串在BRAS前面，所有流量经过网关，好处是管控彻底，但单点风险高，一旦网关故障全部断网。

旁挂模式：网关旁挂在核心交换机上，通过镜像或策略路由引一部分流量过来，好处是对现有网络改动小，但管控能力相对弱一点。

还有一种情况是学校已经有认证计费平台，新网关能不能通过RADIUS协议接入这个既有平台，而不是重新建一套。能不能平滑迁移老用户数据，这个细节决定上线的时候能不能平滑切换，而不是一夜之间几万人集体投诉。

说在最后

代拨网关的参数很多，但主要判断维度就几个：性能够不够用、成功率高不高、防私接准不准、日志能不能合规、对接方不方便。这几个问题答清楚了，选型决策就有一个靠谱的基础。