技术帮助 · 发布时间：
遭受SYN洪泛时边界设备与清洗平台的协同，重点不是把所有防护规则都堆在同一处，而是让边界设备负责快速限流和业务保护，让清洗平台承担大规模流量识别与过滤。两者要共享判断依据，并约定谁启动引流、谁调整策略、何时恢复。
先分清两端各自负责什么
边界设备通常位于网络入口，可能是路由器、防火墙或具备抗攻击能力的负载均衡设备。它靠近业务，可按目的地址、端口和连接状态执行过滤，也能保护后端服务器免于连接状态耗尽。但设备处理能力有限，面对高包速率或超出链路容量的攻击，仅靠本地规则未必够用。
清洗平台通常接收被引导过去的流量，在更大容量的网络节点上识别并丢弃攻击包，再把可用流量送回业务网络。它能缓解上游链路被挤满的问题，但引流和回送需要边界设备及网络路由配合。边界可执行SYN cookies或SYN proxy等措施；它们能缓解握手资源压力，但不能替代链路侧清洗。
按攻击表现选择配合方式
链路尚未拥塞：先由边界止损
如果入口带宽仍有余量，且边界设备的包处理能力正常，可先启用针对受影响业务的连接速率限制、异常新建连接检测或SYN proxy。规则应尽量限定到目标服务，避免一刀切地阻断新连接。监控新连接成功率、半开连接数量、设备丢包和正常请求延迟；若指标持续恶化，升级到平台清洗。
入口链路被打满：平台清洗并由边界接回
当攻击流量已影响正常流量抵达，边界上的过滤通常无法解决链路拥塞，应按预案通过BGP引流，或使用服务商提供的隧道等方式将流量送往清洗平台。平台完成过滤后，将净化流量回送到指定边界。回送路径要预先验证路由可达性和回程路径，避免流量绕过清洗、形成路由环路，或因非对称路径导致状态防火墙误丢包。黑洞路由虽然能快速保护网络，却会连同正常流量一起丢弃，只适合作为明确授权的最后手段。
处置时按步骤闭环
- 确认影响范围。查看边界接口流量、包速率、设备丢包和业务连接失败情况，核实受影响的目的地址与服务，不要仅凭流量变大就扩大封禁范围。
- 启动预案并通知平台。提供攻击目标、时间范围、观察到的流量特征和当前路由状态；按双方约定确认引流方式、回送路径及联系人。
- 分层执行防护。边界先保留必要的基础规则，平台负责清洗大流量；若平台反馈某类正常请求被误判，再有针对性地调整策略，不要同时大幅改动多个环节。
- 联合验证业务。从外部检查握手和页面或接口可用性，同时检查边界回程流量、服务器负载及清洗后的丢弃统计。确认正常流量恢复，而不是只看攻击流量下降。
- 逐步撤销临时配置。攻击减弱后，先确认链路稳定，再按预案撤销引流或收紧临时规则；观察一段时间，避免过早切回后再次拥塞。
预案里要写清的交接点
演练或交接文档应记录引流授权人、变更顺序、回送地址、路由撤销方式和异常回退条件。还要约定统一的时间记录与指标口径，例如入口流量、清洗后流量、丢弃包数和业务成功率。平台统计与边界观测位置不同，数值不一定相等；判断效果时应结合观测点，而非要求数据完全一致。
最终，遭受SYN洪泛时边界设备与清洗平台的协同，应以“边界稳住业务、平台消化规模、双方共同验证和恢复”为原则。提前确认授权、回程路径和退出条件，比攻击发生后临时猜测配置更可靠。
常见问题
边界设备有SYN cookies，还需要清洗平台吗？
如果链路仍畅通且设备有余量，本地防护可能足够；链路拥塞或处理能力不足时，仍需上游清洗。
清洗平台启动后，边界规则要全部关闭吗？
不必。保留必要的访问控制与业务保护规则，但应检查它们是否会误拦清洗平台回送的流量。
什么时候可以撤销引流？
在攻击指标回落、链路和业务稳定且符合双方预案的观察条件后，再逐步撤销，并持续监测是否反弹。
为什么平台显示已清洗，业务仍然不通？
还需检查回程路由、边界状态策略、服务器负载和业务本身；清洗完成不等于端到端链路必然正常。
