TG咨询DDoS攻击防护方案的第一步不是立即封禁，而是判断流量来自哪里、使用什么协议、是否具备正常业务特征。相同的流量规模，可能分别表现为UDP报文暴增、TCP连接耗尽，或带有大量真实请求特征的HTTP访问。如果没有先做流量识别，直接按IP或总带宽拦截，容易把移动网络、企业出口或共享代理后的正常用户一起挡住。
先建立正常流量画像
部署防护前，应至少观察一个完整业务周期，较稳妥的范围是7至14天；如果业务存在明显的周末、月末或活动波动，则应覆盖这些时段。记录内容不应只包括带宽，还要包括每秒新建连接数、并发连接数、TCP与UDP比例、HTTP请求路径、状态码、来源地区和单个地址的请求频率。
例如，公开API通常会出现稳定的短连接和明确的认证请求，图片服务可能以较大的响应流量为主，管理后台则往往只允许少数办公网段访问。可分别计算工作日、夜间和高峰期的正常区间，再把异常判断设置为动态规则。某项指标短时达到平时约2至3倍，可以进入观察或挑战流程；是否直接阻断，还要结合协议、请求内容和持续时间判断。
按攻击类型分层处理
网络层和传输层
面对UDP Flood、ICMP Flood或异常TCP报文，重点是丢弃无效协议、限制异常端口，并保护连接表和出口资源。对于SYN Flood，可启用SYN Cookie、半连接超时和单源新建连接上限。规则应优先作用于不提供服务的端口，不能因为某个端口出现异常就关闭全部业务端口。
TCP连接耗尽与带宽型攻击的处理重点也不同。前者要关注每秒新建连接和半连接数量，后者要关注入口带宽、包速率及清洗后的可转发能力。查看服务商参数时，应同时确认可防护的协议类型、接入端口速率、最大包速率、回源链路和故障切换时间，不能只比较一个峰值数字。
应用层请求
HTTP Flood、慢速请求和异常API调用可能使用真实TCP连接，甚至带有正常浏览器的请求头，因此不能只靠网络层规则解决。应用层防护应结合URL、方法、身份状态、Cookie、响应码和行为频率。例如，登录接口可对同一账户、设备指纹和来源地址分别限速；搜索接口可设置更严格的单位时间请求数；静态文件则应避免套用过低的请求上限。
验证码、JavaScript挑战和登录校验适合放在高风险请求路径，不宜对所有访问统一启用。对无法完成挑战的客户端，可先降低权限或延迟响应，再根据持续行为决定是否拦截。这样比单纯封锁某个国家、运营商或整个地址段更能减少误伤。
一套可执行的部署流程
- 梳理资产。列出域名、IP、端口、协议、源站位置和必须保持开放的业务路径，明确哪些系统可以暂停，哪些接口不能中断。
- 采集基线。按分钟记录带宽、包速率、连接数、请求数和错误率，并分别保存高峰与低谷数据。短时尖峰不应直接被当成攻击。
- 设计分层规则。先用协议和端口规则处理明显无效流量，再用连接上限和速率限制控制资源消耗，最后在应用层检查身份、路径和行为。
- 设置例外。为支付回调、监控探针、合作方接口和办公出口配置经过审核的例外，但例外也应限定端口、路径、时间或来源范围。
- 验证故障路径。在维护窗口模拟连接突增、接口频率过高和异常报文，检查告警、规则生效、日志记录、人工解除和回滚是否正常。不得用未经授权的真实攻击测试公网系统。
- 复盘并调阈值。事件结束后对比拦截量、误拦截、延迟、错误率和源站资源占用，按业务时段调整规则，而不是永久保留临时封禁。
方案选择要看位置和代价
网络边界设备适合快速执行端口、协议和连接规则，优点是路径短、控制直接，缺点是设备容量和链路带宽有限。反向代理或内容分发节点适合处理HTTP请求，能够识别路径、会话和应用行为，但不一定覆盖所有非HTTP协议，并可能增加配置复杂度。云端清洗适合需要较大上游承载能力的公网服务，不过要重点核对路由切换方式、清洗后回源链路、延迟变化和业务连续性。
较稳妥的DDoS攻击防护方案通常不是单一产品，而是把资产暴露面、网络规则、应用策略、日志告警和应急权限组合起来。源站隔离也很关键：只允许代理节点或明确的业务网络访问源站，避免攻击者绕过前端防护直接打源站地址。若源站地址已经公开，应先评估更换地址、收紧访问控制和更新内部引用的影响。
常见问题
是否只看带宽就能判断攻击？
不能。低带宽的连接耗尽或慢速请求同样可能影响服务，还应观察连接数、包速率、请求频率和错误率。
把异常来源IP全部封掉是否有效？
只适合处理来源稳定、特征明确的少量滥用。面对代理、NAT或分布式来源，应结合身份、路径和行为判断，否则误伤概率较高。
速率限制应该设置成固定值吗？
不建议。登录、搜索、文件下载和后台接口的正常频率差异很大，应依据基线分路径设置，并保留观察和调整空间。
怎样判断规则没有挡住正常业务？
同时检查成功率、延迟、验证码通过率、关键接口错误码和客服反馈。只有攻击流量下降且核心业务指标稳定，才说明拦截策略基本合适。
归根结底，DDoS攻击防护方案应遵循“先识别、再分层、可验证、能回滚”的原则：先理解流量，再选择拦截位置和强度，才能在控制攻击影响的同时保留正常访问。
