直播推流业务抵御大流量攻击的容灾设计，不能只看主线路断开后能否换到备用线路。若攻击流量仍抵达同一入口、共享带宽或认证服务，切换可能只是把故障搬到另一处；切换条件设得不当，还可能让正常直播一起中断。
线路切换解决不了的四类故障
备用线路和主线路共用瓶颈
两条线路如果落在同一接入点、同一运营商汇聚链路或同一推流集群，遇到入口拥塞时可能同时失效。设计时要逐项核对路径是否真正分离：接入网络、机房或云区域、负载均衡、推流节点及其上游带宽。线路数量不等于故障域数量。
只看带宽，不看连接与处理能力
大流量可能先挤满网络，也可能先耗尽连接数、会话处理能力、鉴权服务或转码资源。以使用 OBS Studio 向平台推流为例，推流端持续重连会增加入口和鉴权压力；若转码任务也集中在同一组资源，新增流量还可能挤占正常直播的处理能力。因此，容量评估应覆盖整条链路，而不只比较线路标称带宽。
切换造成重连风暴
大量推流端同时切到备用入口，会在短时间内重建连接。备用侧若没有连接限速、分批接入和资源预留，可能在切换时过载。RTMP 与 SRT 的连接和重连表现并不相同，实际阈值应按编码器、网络条件和接入配置压测验证，不能直接照搬一个固定数值。
把直播连续性等同于线路可达
新线路能接收流，不代表观众端马上恢复：流状态、转码任务、播放分发和监控告警都可能各自滞后。若推流入口后还有 CDN 分发，容灾方案还应分别确认源站接流正常、下游能取到新流，以及播放器可以恢复播放。
更稳妥的容灾设计：先分层，再演练
直播推流业务抵御大流量攻击的容灾设计，应把流量清洗、推流接入、媒体处理和播放分发作为不同层次来规划。备用资源要在平时明确用途和容量，不能等主路故障后才临时申请。
- 画出依赖链。从编码器开始，记录接入网络、入口节点、鉴权、转码及分发环节，并标注每项服务的共享资源和故障域。
- 区分故障信号。同时观察入口带宽、连接建立成功率、推流端重连率、处理队列和播放端状态。单一流量告警可能把拥塞误判为线路故障。
- 设置分级保护。优先使用接入侧具备的大流量清洗或流量吸收能力，再按业务重要性为推流入口和处理资源设置独立容量、连接限制与扩容策略。保护措施应避免误伤合法推流。
- 制定切换顺序。先确认备用入口可用，再按批次迁移推流端；为自动重连设置退避，避免客户端同步冲击备用侧。关键直播可保留经验证的备用编码配置或第二条独立上行路径。
- 演练回切。在低风险时段验证故障触发、通知、切换、播放恢复和回切。记录每一步耗时与失败原因，并根据实测调整告警阈值和容量预留。
容易忽略的设计取舍
自动切换响应快，但若告警信号不可靠，可能频繁来回切换；人工切换更容易确认影响范围，却依赖值守响应。可采用“明确故障自动切换、模糊故障人工确认”的方式，并设置稳定观察期后再回切。
容量也不宜只按日常平均流量规划。应结合直播并发规模、码率档位、峰值持续时间和备用侧可扩容速度，分别估算正常接入、故障迁移及攻击期间的资源需求。若备用容量不足以承接全部业务，可以预先定义优先级，例如先保障重要直播和低延迟链路，并明确降级后的画质或功能影响。
常见问题
只准备备用线路，能否作为容灾方案？
不够。还要确认备用线路与主线路是否独立，并验证入口、处理资源和分发链路能否承接迁移流量。
什么时候应该自动切换？
当多项指标共同指向明确故障，且备用入口已通过健康检查时，可考虑自动切换；仅凭带宽升高触发，误切风险较大。
备用线路需要始终承载流量吗？
不一定。冷备成本较低但启用和验证较慢；热备恢复较快，但需持续承担资源和维护成本。选择应取决于允许中断时间与预算。
如何判断演练是否有效？
不仅检查链路是否通，还要核对推流恢复时间、播放端恢复情况、告警是否触达值守人员，以及回切是否会再次造成中断。持续复盘这些结果，才算完成直播推流业务抵御大流量攻击的容灾设计。