DDoS攻击的形态在过去两年发生了非常明显的变化，单纯依靠某一种防护手段已经很难应对现在的攻击流量。攻击者不再只是用大流量把带宽塞满，而是越来越频繁地利用应用层漏洞、慢速连接、混合协议和短时脉冲式攻击来绕过传统防护。很多企业部署了本地防火墙或入侵防御系统，但遇到超过带宽上限的攻击时，设备本身就成了瓶颈。另一些企业把业务完全接入云清洗，日常流量也绕行云端，结果延迟增加，而且对内部东西向流量和API接口的精细控制反而变弱。真正有效的做法是把云清洗和本地策略结合起来，形成一套分层、联动、可自动切换的混合防护架构。

云清洗的核心价值在于它能够处理超大规模流量。当攻击流量达到几十Gbps甚至上百Gbps时，本地出口带宽早已被占满，任何本地设备都来不及分析报文，因为链路层已经拥塞。云清洗平台通常部署在骨干网边缘，具备Tbps级别的吸收能力，通过BGP宣告或DNS牵引把流量引入清洗中心，过滤后再回注到源站。这个过程的关键在于路由切换的速度和回注链路的稳定性。如果切换需要人工介入，攻击开始后的前几分钟业务就已经中断了。因此混合架构的第一条原则是自动化检测与切换，而不是等运维人员发现异常后再去操作。

本地策略的作用则完全不同。它不是用来扛大流量的，而是用来处理那些云清洗看不到或不该看的流量。比如内部系统之间的API调用、数据库同步、微服务之间的东西向通信，这些流量通常不经过云端清洗路径。如果攻击者已经渗透到内网，或者利用僵尸主机从内部发起慢速攻击，云清洗平台根本感知不到。本地部署的Web应用防火墙、速率限制模块和行为分析引擎可以针对这些细粒度流量做精准控制。更重要的是，本地策略可以保护那些不适合绕行云端的敏感数据接口，避免所有流量都经过第三方清洗中心带来的合规风险。

混合架构的落地并不是简单地在前面挂一个云清洗服务，然后在本地放一台防火墙。真正的难点在于联动机制。一个可用的方案是：本地检测设备持续监控入站流量，当带宽占用、连接数、新建速率或应用层错误率超过预设阈值时，通过API自动向云清洗平台发送告警，触发流量牵引。同时本地设备开始执行第一轮过滤，丢弃明显非法的报文，减轻后续清洗压力。云清洗平台接管流量后，根据攻击特征生成过滤规则，只把清洗后的干净流量回注到本地网络。本地设备再对回注流量做二次校验，防止清洗平台漏掉的低速攻击进入业务系统。

在这个过程中，阈值设定非常关键。阈值太低会导致正常业务流量频繁被牵引到云端，增加延迟和成本；阈值太高则可能在攻击已经造成损害后才触发切换。比较务实的做法是分两级阈值。第一级是预警阈值，比如入站带宽达到出口总带宽的60%，或者TCP连接数在30秒内增长超过日常峰值的两倍，此时只启动本地限速和连接重置，不牵引流量。第二级是切换阈值，比如带宽占用超过80%，或者应用层超时率超过15%，此时立即触发云清洗。这种分级策略可以在小规模攻击时保持业务路径不变，在大规模攻击时快速切换，兼顾性能和成本。

云清洗平台的选择也有讲究。并不是所有清洗服务都支持细粒度的应用层过滤。很多基础型清洗服务只做网络层的流量清洗，比如过滤SYN Flood、UDP Flood和ICMP Flood，但对HTTP慢速攻击、TLS握手耗尽和API参数滥用几乎没有效果。如果业务以HTTPS为主，就必须选择支持SSL解密和HTTP协议深度检测的清洗服务。这意味着需要把SSL证书私钥托管给清洗平台，或者使用Keyless SSL方案。对于金融、医疗等强合规行业，私钥托管可能不被允许，这时可以考虑只把非敏感域名接入云端清洗，敏感域名保留在本地，通过DNS分流实现部分流量绕行。

本地策略中，连接状态管理是容易被忽视的一环。很多攻击利用的是半开连接和空闲连接占用资源。本地设备如果只做包过滤，不维护连接状态，就无法识别哪些连接是真实的、哪些是攻击者伪造的。状态防火墙或应用层网关可以跟踪TCP握手状态、HTTP会话状态和TLS会话票据，对不符合状态机转换的报文直接丢弃。更进一步，可以结合IP信誉库和地理位置信息，对来自高风险区域的流量执行更严格的验证，比如要求完成JavaScript挑战或CAPTCHA验证。这些验证逻辑放在本地执行比放在云端更灵活，因为可以根据业务路径实时调整。

另一个容易被低估的问题是回注流量的路径。云清洗完成后，干净流量需要通过隧道或专线回注到本地网络。如果回注链路本身带宽不足，清洗就失去了意义。很多企业购买了100Gbps的清洗能力，但回注专线只有10Gbps，攻击流量清洗后仍然无法全部回注。因此混合架构设计时必须同步规划回注带宽，至少保证回注链路能够承载业务正常峰值的1.5倍以上。同时要配置回注链路的冗余，避免单点故障。对于多数据中心部署的场景，可以考虑让清洗平台把流量回注到最近的可用节点，而不是固定回注到主数据中心。

从成本角度看，混合架构的优势在于按需使用云资源。日常流量走本地链路，只有攻击发生时才触发云清洗，这样云清洗的费用是弹性的，而不是固定月租。但要注意，云清洗服务通常按攻击时长或清洗流量计费，如果攻击频繁发生，费用可能迅速上升。因此本地策略中必须包含攻击溯源和封禁能力，尽量在攻击早期就阻断源IP或源段，减少需要牵引到云端的时间。比如本地设备检测到某个C段持续发送异常流量，可以立即通过BGP黑洞路由或ACL封禁该网段，同时通知上游运营商协同封禁。这种本地快速响应可以显著降低云清洗的调用频率。

应用层防护是混合架构中最难做好的部分。HTTP Flood、CC攻击和慢速攻击的流量并不大，但足以耗尽应用服务器的线程池和数据库连接。云清洗平台即使能识别这些攻击，也需要解密HTTPS流量才能看到请求内容。本地设备则天然具备解密能力，可以在流量进入应用服务器之前完成请求合法性校验。一个有效的策略是：本地WAF对所有入站HTTP请求执行速率限制、UA校验、Referer校验和Cookie挑战，只有通过校验的请求才转发到后端。对于API接口，可以进一步限制每个API Key的调用频率和参数长度，防止接口被滥用。这些策略的执行位置越靠近业务服务器，效果越好，因为可以结合业务逻辑判断请求是否合理。

混合架构还需要考虑DNS层的防护。很多DDoS攻击直接针对DNS服务器，如果DNS解析失败，即使业务服务器正常，用户也无法访问。本地DNS服务器通常带宽有限，容易成为攻击目标。一种做法是把DNS解析托管到云端，利用云平台的分布式解析能力吸收攻击。同时本地保留权威DNS的备份，当云端解析异常时自动切换回本地。DNS层面的切换比HTTP层面更快，因为DNS缓存的存在使得切换对用户的影响较小。但要注意DNS记录的TTL设置，过长的TTL会导致切换后用户仍然使用旧的解析结果，过短的TTL则增加解析延迟和查询量。通常建议在攻击期间临时降低TTL到60秒以内，攻击结束后恢复正常值。

对于已经具备一定安全团队的企业，可以在混合架构中加入自定义的检测与响应逻辑。比如通过NetFlow或sFlow采集流量数据，实时分析流量模式，识别异常协议分布和源IP熵值变化。当检测到攻击特征时，自动生成过滤规则并下发到本地设备和云清洗平台。这种自动化响应能力是混合架构的核心竞争力，因为攻击窗口往往只有几分钟，人工响应根本来不及。实现自动化需要统一的安全编排层，能够对接本地防火墙、WAF、路由器和云清洗API，形成闭环。目前很多安全厂商提供了SOAR平台，可以编排这些动作，但需要企业根据自身网络环境做适配。

最后要强调的是，混合防护架构不是一次性建设完成的，它需要持续运营和演练。很多企业部署了混合架构，但从未进行过攻击演练，真正遇到攻击时发现切换流程不通、API密钥过期、回注链路未配置或清洗规则不生效。建议每季度至少进行一次模拟攻击演练，验证从检测到切换再到回注的完整链路。演练时可以使用低强度攻击流量，避免影响正常业务，但要覆盖所有关键路径。演练后根据发现的问题调整阈值、优化规则、更新文档。只有经过反复验证的混合架构，才能在真实攻击中发挥作用。