应对ddos，关键不是临时加大服务器配置，而是尽量让恶意流量在到达业务主机前被识别、分流或丢弃。个人网站、游戏服务、企业门户和公开API面临的风险并不相同，防护方案应先看服务入口、网络带宽和业务能否接受短时降级。
先判断攻击打在哪里
ddos通常指多台设备同时向一个目标发送请求，目的可能是挤满网络链路，也可能是耗尽连接或应用资源。网络层和传输层攻击常表现为带宽、连接数异常；应用层攻击则可能由大量看似正常的HTTP请求构成，服务器CPU或数据库先达到瓶颈。只盯着主机负载，可能错过入口链路已经拥塞的情况。
先画出访问路径：域名解析、边缘节点或防护设备、负载均衡、源站和数据库。确认哪些端口必须对公网开放，哪些管理入口可以限制到固定地址或专用网络。源站若能被绕过防护入口直接访问，前置防护就可能失去作用。
按层建立防护
网络入口：吸收和清洗流量
选择具备流量清洗能力的网络服务或托管防护，将公网入口指向其提供的防护地址，由系统过滤异常包或连接。适合带宽攻击风险较高、业务需要持续对外开放的服务。评估时要问清防护覆盖的协议和端口、触发清洗的条件、误拦截时如何恢复，以及是否支持源站隐藏。普通防火墙能按规则拦截流量，但无法单独解决上游链路被塞满的问题。
应用入口：限制异常请求
对网站和API，可结合WAF、速率限制、连接超时、请求体大小限制和缓存。按登录、搜索、验证码等不同接口设置规则，不要给所有路径套同一阈值；正常用户会共享出口地址，单纯按IP封禁容易误伤。应用层防护适合处理高频请求，但不能替代网络侧的流量清洗。
上线前的可执行检查
- 盘点公网域名、IP、端口和依赖服务，关闭不需要的入口，并为管理面设置访问限制。
- 记录正常时段的带宽、连接数、请求频率和错误率。至少覆盖工作日与业务高峰；周期更长有助于区分日常波动和异常。
- 与网络服务商确认ddos事件的告警渠道、值班联系人、清洗方式及源站保护设置，明确由谁执行DNS或路由切换。
- 为关键接口设置分级限流与降级策略，例如暂缓非必要的批量查询，优先保留登录、支付或核心查询能力；具体优先级按业务确定。
- 定期核对告警是否有人接收，并在变更窗口验证防护入口、源站访问限制和回退步骤。未经授权，不要对公网目标发起压力测试。
攻击发生时怎么处理
发现流量或错误率突增后，先核对监控、服务商告警和近期配置变更，确认受影响的是链路、连接还是应用资源。随后联系网络服务商启动相应的流量清洗或黑洞路由处置。黑洞路由会丢弃发往目标的流量，能避免攻击继续影响其他网络资源，但该目标也会暂时无法正常访问，应作为损害控制手段，而非无影响的常规方案。
同时保留时间、流量趋势、受影响端口、错误日志和处置记录，避免在证据不足时反复封禁大范围地址。攻击缓解后检查源站是否仍可被直接访问，撤销临时规则前确认业务恢复，并复盘误拦截、告警延迟和责任交接问题。ddos防护的效果取决于入口、规则和响应流程是否配合，不能只看某一台服务器的配置。
常见问题
小型网站需要专门防护吗？
先做好源站隐藏、最小化开放端口、备份和服务商联络方式。是否购买额外防护，应结合业务中断影响和现有网络服务能力判断。
加宽带宽能防住ddos吗？
加带宽只能提高部分攻击的拥塞门槛；若流量超过上游链路容量，仍可能无法访问。它不能替代清洗和应用层限流。
开启WAF就够了吗？
不够。WAF主要处理应用请求规则，网络链路拥塞需要网络侧能力共同应对。
怎样判断防护是否有效？
检查异常流量是否被拦截、核心业务是否可用、误拦截是否可控，以及告警和切换流程是否按预案执行。