DDoS防御云清洗与源站防护协同方案

DDoS防御从来不是买一台设备或者开一个云清洗服务就能解决的问题。真正出过事的团队都清楚，攻击流量一旦超过某个阈值，源站哪怕还有一口气在，业务也已经等同于瘫痪。所以现在谈DDoS防护，核心已经不是“能不能扛住”，而是“清洗节点和源站之间怎么协同”。云清洗负责把流量里的攻击成分剥离，源站防护负责在剩余流量到达业务前端时再做一次精准拦截，两者配合的深度直接决定业务在攻击期间的可用性。

先看一个最常见的误判：很多企业上了云清洗之后，就把源站的安全策略放宽了。理由很直接，反正大流量有云端扛着，源站只需要处理“干净流量”。但现实是，云清洗的判定不可能百分之百准确，尤其是应用层攻击、慢速攻击、低频CC或者伪装成正常业务的Bot流量，清洗节点很难在短时间内区分。这些漏过来的流量一旦直接打到源站，源站如果没有独立的防护策略，数据库连接数、CPU、带宽都会被迅速耗尽。云清洗和源站防护不是替代关系，而是过滤层级关系。

云清洗的核心能力在于用海量带宽和分布式节点去吸收流量型攻击，比如SYN Flood、UDP Flood、ACK Flood、NTP反射、DNS放大这类。攻击流量被牵引到清洗中心后，通过特征匹配、协议校验、行为分析等手段丢弃恶意报文，只回注正常流量。这个过程对源站来说，理论上感知不到攻击的存在。

但问题在于，云清洗的判定模型依赖于流量特征和历史基线。如果是突发的新型攻击，或者攻击者把速率控制在清洗阈值以下，又或者攻击目标直接是业务逻辑漏洞，云清洗的拦截率就会下降。更麻烦的是HTTPS场景下的应用层攻击，清洗节点需要解密流量才能做深度检测，这会带来证书管理、性能损耗和合规风险。很多企业不愿意把证书私钥交给第三方清洗服务，导致云清洗在L7层的防护能力被大幅削弱。

所以云清洗更适合作为第一道防线，解决“带宽被打满”和“网络层协议攻击”的问题。它不能让源站裸奔，更不能替代源站侧的安全体系。

源站防护的核心价值在于“近业务端”的精细控制。因为源站离业务逻辑最近，能看到完整的请求上下文，包括会话状态、用户身份、业务参数、访问频率、资源消耗等。这些信息是云端清洗节点很难获取的，尤其是在加密流量场景下。

一个典型的例子是电商平台的秒杀接口。攻击者用大量僵尸网络模拟正常用户请求，每个请求的IP、UA、Cookie都是真实的，但请求频率远高于正常用户。云清洗可能只看到QPS突然升高，无法判断这是营销活动带来的正常流量还是CC攻击。而源站防护可以通过用户ID、设备指纹、行为序列、下单转化率等维度，识别出哪些是自动化攻击，哪些是真实用户，然后做精准限速或挑战验证。

源站防护的另一个关键作用是兜底。即使云清洗漏掉了一部分攻击流量，源站侧的WAF、RASP、限流模块、访问控制列表仍然可以执行二次过滤。这种纵深防御的思路，才是高可用架构的基础。

云清洗和源站防护要真正协同，首先要解决的是流量回注的准确性。清洗后的流量回注到源站时，源站看到的源IP往往是清洗节点的IP，而不是真实客户端IP。如果源站防护策略基于IP做限制，就会误伤所有经过清洗的流量。所以必须通过X-Forwarded-For、Proxy Protocol或者自定义Header来传递真实客户端IP，同时源站侧要信任这些字段并正确解析。

但这里有个安全细节：如果源站直接暴露在公网，攻击者可以绕过云清洗直接伪造X-Forwarded-For字段，让源站防护误判。因此源站应该只允许来自清洗节点IP段的流量访问，其他来源一律拒绝。这个可以通过安全组、防火墙或者源站前置的负载均衡器来实现。只有把回源路径锁死，协同方案才成立。

策略联动是更深一层的协同。云清洗检测到某个IP段持续发起攻击后，可以通过API把恶意IP列表推送到源站防护系统，源站侧提前将这些IP加入黑名单。反过来，源站防护发现某个业务接口被CC攻击，也可以把攻击特征同步给云清洗，让清洗节点在边缘就丢弃匹配的请求。这种双向的威胁情报共享，能大幅缩短攻击响应时间。

很多协同方案落地失败，不是产品不行，而是配置细节没做好。第一个常见问题是DNS解析。启用云清洗后，业务域名应该解析到清洗服务的CNAME，由清洗服务根据调度策略决定是否牵引流量。但如果源站IP曾经暴露过，攻击者可以直接针对源站IP发起攻击，绕过DNS解析。所以源站IP必须定期更换，并且严格限制对外暴露范围。

第二个问题是健康检查。清洗节点需要持续探测源站的可用性，一旦源站宕机，清洗节点应该返回缓存页面或者静态降级页面，而不是把请求继续转发到已经挂掉的源站。这个健康检查的间隔、超时时间、失败阈值都需要根据业务容忍度调整。太灵敏会导致误切换，太迟钝会导致用户长时间等待。

第三个问题是SSL处理。如果清洗节点需要做HTTPS解密，证书管理要跟上。更推荐的做法是源站和清洗节点都配置相同的证书，清洗节点做TLS终结后，回源时重新加密，这样既保证了检测能力，又避免了明文流量在公网传输。如果业务对证书私钥管控严格，可以考虑使用Keyless SSL方案，让清洗节点在不解密的情况下做部分检测，但防护效果会打折扣。

应用层CC攻击是现在最难防的类型之一。攻击者往往利用代理池、肉鸡模拟真实用户行为，请求的URL、参数、Header都经过精心构造，单看每一条请求都是合法的。这种攻击对云清洗和源站防护的协同要求最高。

一个有效的策略是分层限速。在云清洗节点做第一层粗粒度限速，比如单IP每秒请求数超过阈值就触发验证码或者丢弃。在源站防护做第二层细粒度限速，基于用户ID、会话Token、设备指纹做更精准的控制。两层限速的阈值要错开，云清洗的阈值可以放宽一些，避免误杀正常用户，源站侧的阈值可以收紧，因为能到达源站的流量已经经过了一轮过滤。

另一个容易被忽视的点是动态挑战。当源站防护检测到某个请求可疑时，可以返回JS挑战或者验证码页面。但这里要注意，如果云清洗节点缓存了源站返回的挑战页面，会导致后续请求都拿到缓存的挑战内容，用户无法正常完成验证。所以挑战页面的响应头必须设置Cache-Control: no-store，并且清洗节点要配置对这类响应的透传规则。

没有日志和监控，协同方案就是盲人摸象。云清洗和源站防护必须各自输出结构化的访问日志和攻击日志，并且汇总到同一个分析平台。这样才能还原一次攻击的完整路径：哪些流量在云端被丢弃了，哪些流量漏到了源站，源站又拦截了多少，最终有多少请求真正到达了业务后端。

这里有一个实操建议：在日志中统一记录一个唯一的请求ID，从清洗节点到源站防护再到业务系统，全程传递这个ID。这样排查问题时，可以用一个ID串起整条链路，快速定位是哪个环节出了问题。很多团队在攻击发生时手忙脚乱，就是因为日志分散在各个系统里，格式不统一，无法关联分析。

监控指标也要对齐。云清洗关注的是入向流量峰值、清洗率、回源流量、丢弃报文数。源站防护关注的是QPS、响应时间、错误率、连接数、CPU负载。两边指标要放在同一个Dashboard里对比，才能判断清洗是否有效、源站是否过载、是否需要调整策略。

协同方案还要考虑容量问题。云清洗的容量通常是弹性的，但源站的容量是有限的。如果攻击流量清洗后仍然超过源站的承载能力，业务还是会挂。所以源站侧也要做弹性扩展，比如自动扩容应用服务器、增加数据库只读副本、启用缓存层等。

一个常见的错误是源站只按日常流量预留容量，没有考虑攻击期间的突发流量。即使云清洗过滤掉了90%的攻击流量，剩下的10%也可能是日常流量的好几倍。源站防护系统本身也会消耗资源，WAF规则越多、检测深度越大，性能损耗越高。所以在攻击期间，可能需要动态调整源站防护的策略，比如关闭一些高消耗的检测模块，优先保证核心业务可用。

容量规划还要考虑回源带宽。清洗节点回源时，如果源站的入口带宽不足，即使应用服务器还有余力，流量也进不来。这个环节经常被忽略，结果就是云清洗显示清洗正常，但用户访问依然很慢，因为回源链路成了瓶颈。

第一步是梳理业务资产和攻击面。明确哪些域名、哪些接口、哪些源站IP需要纳入防护，哪些是核心业务不能中断，哪些可以降级。第二步是部署云清洗并完成流量牵引测试，确认DNS切换、回源路径、证书配置都正常。第三步是在源站侧部署防护组件，包括WAF、限流模块、访问控制，并配置只允许清洗节点回源。第四步是打通日志和监控，建立联合分析能力。第五步是定期做攻防演练，模拟不同类型的攻击，验证协同方案的实际效果。

这里要强调一点：协同方案不是一次性配置完就万事大吉。攻击手法在变，业务架构在变，防护策略也要持续迭代。每次攻击事件之后，都要复盘清洗节点的拦截日志和源站防护的拦截日志，找出漏网之鱼的共同特征，然后更新规则。只有把协同当成一个持续运营的过程，而不是一个静态的配置，才能真正扛住高强度的DDoS攻击。

云清洗和源站防护的协同，本质上是用分层防御的思路去对抗不确定的攻击。云端负责扛住大流量和协议攻击，源站负责精细识别和业务保护。两者之间的流量回注、策略联动、日志关联、容量匹配，每一个环节都决定了最终防护效果的上限。把细节做扎实，比堆砌安全设备更有价值。