搭建DDoS防御体系之前必须明确一个前提：不存在单点设备或单一方案能彻底解决所有类型的DDoS攻击。真正有效的防御是把流量清洗、协议校验、资源隔离、动态扩容和应急响应串成一条完整的处理链。这篇文章直接拆解每一层该怎么落地，包括自建机房、云上部署和混合架构的具体做法。

先分清攻击类型，防御手段才不会用错方向

DDoS攻击从协议层到应用层差异极大。网络层攻击主要靠超大流量拥塞带宽，比如UDP Flood、ICMP Flood、伪造源IP的SYN Flood。传输层攻击利用TCP握手缺陷或连接表耗尽，典型的是SYN Flood、ACK Flood、RST Flood。应用层攻击则针对HTTP、DNS、游戏协议等具体业务，例如HTTP Flood、Slowloris、DNS Query Flood。很多攻击是混合发起的，所以防御体系必须同时覆盖网络层、传输层和应用层。

自建机房场景下，第一道防线是运营商的上游清洗。你需要和带宽供应商签订DDoS清洗服务，当攻击流量超过阈值时，运营商通过BGP社区或黑洞路由把流量牵引到清洗中心，过滤后再回注正常流量。这里的关键是阈值设置和牵引速度。阈值太高，攻击已经打垮你的边界设备；阈值太低，正常流量波动也会触发清洗。一般建议以日常峰值带宽的1.5到2倍作为触发点，同时要求运营商支持秒级检测和自动牵引。

边界设备要做协议级限速和状态表保护

即使上游清洗了大部分流量，进入机房的残余流量仍然可能耗尽防火墙或路由器的连接表。边界路由器上必须配置严格的入站过滤。对于UDP流量，按目的IP和端口做限速，非业务端口的UDP直接丢弃。对于ICMP，只放行必要的分片不可达和回声应答，其余限速在每秒几百个包以内。对于TCP，开启SYN Cookie或SYN Proxy功能，把半开连接限制在设备可承受范围内。

防火墙层面要启用连接状态表保护。很多硬件防火墙默认的连接表大小有限，攻击者用大量伪造源IP的SYN包就能把表填满。配置上需要缩短SYN超时时间，从默认的30秒降到5到10秒；对单个源IP的最大并发连接数做限制；开启TCP序列号校验和窗口大小检查。如果业务允许，可以在防火墙前面再加一层专门的抗D设备，比如基于FPGA或NP芯片的硬件清洗设备，它们处理新建连接的速度远高于通用防火墙。

应用层防御必须贴近业务逻辑

HTTP Flood和Slowloris这类攻击靠边界设备很难识别，因为它们建立的TCP连接是完整的，请求格式也合法。防御重点要放到Web服务器和反向代理层。Nginx或OpenResty上需要配置连接超时、请求体大小限制、并发连接数限制。针对Slowloris，把client_header_timeout和client_body_timeout设置得足够短，比如5秒以内，同时限制单个IP的同时连接数。

更有效的方式是在反向代理层做请求速率限制。Nginx的limit_req模块可以按IP或会话维度限制每秒请求数。但要注意，移动网络出口IP经常是共享的，单纯按IP限速容易误伤正常用户。建议结合Cookie或设备指纹做更细粒度的限速，例如同一Cookie在10秒内请求超过50次就触发验证码或直接拒绝。对于API接口，可以要求客户端携带签名和时间戳，服务端校验时间窗口，超出窗口的请求直接丢弃，这样能有效防御重放型应用层攻击。

DNS防护是多数人忽略的薄弱环节

很多业务依赖DNS解析，但DNS服务器本身也是DDoS的常见目标。自建DNS的场景下，权威DNS和递归DNS要分开部署。权威DNS只响应自己域名的查询，递归DNS只服务内部用户，不对外开放。权威DNS前面可以部署多台缓存服务器，缓存TTL设置得足够长，减少回源压力。对于DNS Query Flood，限制每个源IP的查询速率，对ANY查询、DNSSEC不支持的查询类型直接拒绝。如果条件允许，使用任播技术把DNS节点分布到多个机房，攻击流量会被分散到最近的节点，单点被打挂的概率大幅降低。

云上防御的核心是弹性扩容和自动清洗

云平台的优势在于带宽储备和清洗能力远超自建机房。部署在云上的业务，应该把入口流量全部接入云厂商的DDoS防护产品。这类产品通常提供基础防护和高级防护两个等级。基础防护一般免费，能抵御几Gbps到几十Gbps的常见攻击。高级防护按需付费，能处理数百Gbps甚至Tbps级别的攻击，并且支持更精细的协议校验和业务特征识别。

云上架构的关键是不要把业务直接暴露在公网IP上。所有入站流量先经过负载均衡或高防IP，再转发到后端实例。后端实例放在私有网络中，不分配公网地址。这样即使攻击者拿到源站IP，也无法直接打到业务服务器。同时开启云平台的自动伸缩功能，当CPU、带宽或连接数指标异常升高时，自动增加后端实例数量，配合高防IP的流量清洗，可以扛住大部分突发攻击。

混合架构下要把清洗节点前置到云

很多公司既有自建机房又有云上业务，攻击者往往会选择自建机房作为突破口，因为自建带宽有限。混合架构的推荐做法是把云高防作为所有流量的统一入口。域名解析指向云高防IP，高防清洗后通过专线或公网回源到自建机房。这样自建机房的公网IP可以完全隐藏，攻击者只能看到云高防的地址。回源流量走专线更安全，但成本较高；走公网则需要在高防和源站之间配置IP白名单和加密隧道，防止攻击者绕过云高防直接打源站。

回源链路的稳定性至关重要。如果云高防到源站的连接被攻击者通过CC攻击打满，即使前端清洗了网络层攻击，源站仍然会因应用层压力而不可用。所以源站侧必须保留基础防护能力，比如Nginx限速、连接数限制、业务降级开关。同时准备备用回源线路，主线路中断时自动切换到备用线路。

应急响应流程要提前演练，不能等攻击来了再想

DDoS攻击发生时，前几分钟的处理效率直接决定业务影响范围。团队里必须有人能在收到告警后立即判断攻击类型和规模。监控系统需要同时采集网络流量、连接数、请求量、响应时间和错误率。告警阈值要分级，第一级是异常波动，第二级是明显攻击特征，第三级是业务不可用。每一级对应不同的响应动作，比如第一级只通知运维观察，第二级启动上游清洗和限速策略，第三级切换高防IP或启用备用入口。

切换高防IP是常见的应急手段，但DNS切换有生效延迟，通常需要几分钟到几十分钟。为了缩短切换时间，可以提前配置多个高防IP，通过智能DNS或HTTP 302跳转实现快速切换。更彻底的做法是业务入口使用CNAME指向一个固定的高防域名，攻击时只需要在高防控制台修改回源地址，不用改DNS记录。

应急响应中还有一个容易犯的错误是过度封禁。攻击流量里往往混杂着正常用户请求，如果为了快速止损而封掉整个IP段或地区，会导致大量正常用户无法访问。正确的做法是先限速后封禁，先针对攻击特征明显的源IP做精确封禁，再逐步扩大范围。同时保留封禁日志，攻击结束后及时解封。

防御体系需要持续优化，不能一次搭建就完事

攻击者的手法在不断变化，防御策略也要跟着调整。每个月至少做一次攻击复盘，分析攻击类型、流量峰值、持续时间、清洗效果和业务影响。根据复盘结果调整阈值、限速规则和应急流程。每季度做一次压力测试，模拟不同类型的DDoS攻击，验证防御链路是否有效。测试时要注意控制流量规模，避免影响真实用户。

日志和数据是优化的基础。边界设备、清洗设备、Web服务器、负载均衡器的日志要统一收集，至少保留30天。攻击发生时，日志能帮助快速定位攻击特征和源IP分布。如果日志缺失，事后分析几乎无从下手。对于大规模攻击，可以借助流量分析工具生成攻击画像，包括协议分布、包大小分布、源IP地理位置分布等，这些数据对后续调整防御策略很有价值。

最后强调一点，DDoS防御不是纯技术问题，还涉及成本和业务容忍度的平衡。高防带宽、清洗设备、云防护服务都需要持续投入。你需要根据业务的重要性和攻击风险，决定哪些资产需要最高级别防护，哪些可以接受短时中断。把有限的资源集中在核心业务入口上，比试图保护所有资产更现实。