直播中断未必是源站故障：入口可能被请求洪泛挤满，清洗设备也可能误拦正常观众。设计直播平台遭遇网络攻击时的防护架构，关键是把接入、清洗和回源分开，逐层判断流量、处置风险，并确保源站不因入口暴露而成为薄弱点。
先按直播链路划分责任
一条常见链路是观众请求播放地址，边缘节点提供 HLS 分片，未命中缓存时再向源站取内容；低延迟场景也可能采用 WebRTC，直播推流端则可能使用 RTMP。协议不同，连接特征与保护方式也不同，不能把所有流量都套用同一条限速规则。
- 接入层：承接观众与推流端连接，执行基础校验、连接数限制和协议分流。
- 清洗层：识别异常连接或请求洪泛，在不影响正常播放的前提下阻断或限速。
- 回源层：限制边缘节点和业务服务对源站的访问，避免绕过前两层直接冲击源站。
这三层共同构成直播平台遭遇网络攻击时的防护架构。接入层负责分流，不应独自承担大规模攻击清洗；清洗层处理异常流量，但不应替代应用自身的身份验证和权限控制。
接入层：区分观众、推流与管理请求
按域名、端口和协议把播放、推流、登录及管理入口分开，分别配置访问策略。比如，HLS 播放通常由大量短请求组成，可关注单个来源的请求速率、重复访问路径及响应状态；WebRTC 会维持实时连接，应重点观察并发连接、握手失败和媒体转发资源。管理后台则应独立限制访问来源，并启用多因素验证。
使用 Envoy 或 HAProxy 等代理时，可在入口设连接超时、请求体上限和并发保护；具体阈值应结合基线、观众规模与协议压测确定，不宜照搬通用数值。初次部署可先记录正常高峰下各入口的请求率、连接数和错误率，再设置告警线与限流线，并保留人工放宽策略，降低误伤风险。
清洗层：先识别变化，再逐步处置
清洗策略要结合多个信号：单位时间请求数、连接建立失败率、请求路径分布、单账号或单令牌的并发，以及边缘回源比例。单看来源地址可能误判，因为企业网络、校园网络和移动运营商出口可能由许多用户共享。
- 建立分协议、分业务的正常流量基线，并设置值班告警。
- 告警触发后，核对流量增长位置、受影响入口及错误类型，区分播放、推流和登录故障。
- 优先启用针对异常路径、无效令牌或过高并发的规则；按小范围、短时段观察误拦情况。
- 若入口容量持续逼近上限，切换到预先验证的上游清洗服务或备用接入点，并同步告知相关运维人员。
- 流量恢复后逐项撤销临时规则，复盘告警、切换耗时和业务影响，更新预案。
规则最好从监测模式开始，再逐步转为拦截。若所有观众共用同一个播放令牌，简单限制令牌请求数可能造成大面积断播；应结合令牌有效期、内容权限和播放器重试行为评估。
回源层：让源站只接受必要流量
源站不应作为公开入口供观众直接访问。可通过访问控制，只允许可信边缘节点或清洗后的流量到达源站，并分别限制播放内容、推流服务和管理接口。对于 HLS，检查边缘缓存命中与回源请求是否异常偏离基线；对实时推流，则关注上游连接数和单路流的资源消耗。源站仍须保留应用层校验，不能因前置代理已过滤流量就取消权限检查。
回源限速需要给正常的热门直播留出余量。缓存失效、切片集中更新或活动开始时，回源可能自然上升。应先验证缓存策略、源站容量和备用路径，再设置告警；过紧的限制可能把攻击挡在门外，也可能让真实观众无法取流。
把防护变成可执行预案
可靠的直播平台遭遇网络攻击时的防护架构不只是设备清单，还要明确谁判断、谁切换、何时回退。至少记录各层流量负责人、供应商联络方式、规则变更权限、回源白名单维护流程及观众通知渠道。定期在自有或获授权的测试环境演练，不要对未经授权的公共系统施加测试流量。
常见问题
问：接入层限流和清洗层有什么区别？
答：接入层主要执行入口分流与基础限制；清洗层根据流量特征识别并处置异常流量，适合承担更专门的过滤任务。
问：源站隐藏后就足够安全吗？
答：不够。还需限制源站仅接受可信回源访问，并保留应用权限校验、监控和备用方案。
问：怎样减少限流误伤？
答：按协议和业务建立基线，先监测再拦截，观察正常高峰与播放器重试影响，并准备快速回退步骤。
分层的目的，是让异常流量尽可能在靠近入口处被识别，同时让必要请求有受控路径到达源站。明确职责、逐步验证并持续复盘，才能让直播平台遭遇网络攻击时的防护架构在防护与稳定播放之间取得平衡。
