混合云架构下的网站防护难点在于流量路径不统一，回源地址分散在公有云和自建机房，传统单点接入的DDoS云防护要么强制所有流量绕行公有云节点，要么对自建机房链路的清洗能力不足。真正可落地的适配方案不是把混合云改造成公有云，而是基于“就近清洗、统一调度、分段回源”的思路重新设计防护链路。
先厘清混合云部署中DDoS防护失效的三个根因
第一个根因是DNS解析与业务入口割裂。很多混合云网站把主域名解析到公有云负载均衡，同时又把部分API或管理后台通过CNAME指向自建机房入口。DDoS云防护通常要求域名CNAME到防护节点，但运维团队往往只把主站接入，忽略了子域名和API网关，攻击者直接对未接入的子域名发起大流量请求，防护形同虚设。
第二个根因是回源链路不可控。公有云上的DDoS防护服务清洗完流量后，需要把干净流量回源到真实服务器。如果真实服务器一部分在公有云、一部分在自建机房，回源流量经过公网传输时可能再次拥塞，甚至触发运营商黑洞路由。尤其当自建机房出口带宽只有几百兆时，清洗后的流量依然能打满出口。
第三个根因是会话状态和防护策略不同步。混合云中前端应用可能在公有云，数据库和缓存留在自建机房，跨机房调用本身就有延迟。DDoS防护开启严格模式后，可能会误伤跨机房的内网API调用，导致业务出现间歇性超时。很多团队为了“安全”直接开启全站JS挑战或验证码，结果把正常的内部服务调用也拦截了。
适配方案第一步：建立统一的接入层，而不是分别接入
混合云部署的网站要接入DDoS云防护，最忌讳的是“哪台服务器在公有云就接公有云防护，哪台在机房就接机房防火墙”。正确做法是在DNS层面统一收敛入口。把主域名和所有子域名的NS记录指向同一套智能解析服务，在解析层根据线路和地域把流量导向不同的清洗节点。清洗节点可以部署在公有云、第三方DDoS防护服务商或自建机房前置的云清洗中心，但用户侧看到的始终是同一个CNAME链。
具体操作上，建议把网站域名拆成三层：用户入口域名统一CNAME到DDoS云防护的接入域名；API域名同样CNAME到防护接入，但开启独立的防护模板；内部服务域名不对外解析，只在混合云内网使用。这样攻击者无法通过子域名枚举找到未防护的入口，因为所有对外可见的域名都指向了防护节点。
适配方案第二步：回源链路上用专线或加密隧道替代公网直连
DDoS云防护清洗后的流量要回源到自建机房时，如果直接走公网，等于把清洗节点的压力转移到了机房出口。推荐的方案是在清洗节点和自建机房之间建立IPsec VPN或专线连接，让清洗后的干净流量通过隧道回源。对于公有云上的源站，直接使用云厂商的内网回源地址，避免流量再次经过公网。
如果自建机房没有专线条件，至少要在机房入口部署一层流量整形设备，对回源流量做二次限速和协议校验。很多DDoS云防护服务商支持“回源限速”功能，可以设置每源IP的最大回源速率，防止清洗后的流量突发打满机房带宽。这个参数需要根据机房实际出口带宽来调，一般设置为出口带宽的60%到70%，留出余量给正常业务和运维访问。
适配方案第三步：把防护策略拆成“边界清洗”和“源站二次校验”两层
混合云环境下，DDoS云防护负责第一层大流量清洗，但清洗规则不能太激进，否则会误伤跨机房调用。建议在防护节点上只开启针对网络层和传输层的攻击防护，比如SYN Flood、UDP Flood、ACK Flood、NTP反射放大等，应用层只开启基础的CC频率限制和IP信誉库拦截。更精细的应用层防护放到源站前面的WAF或Nginx层来做。
举个例子，在公有云源站前部署WAF，开启针对登录接口的暴力破解防护和SQL注入检测；在自建机房源站前部署Nginx，通过limit_req模块限制单IP的请求速率。这样DDoS云防护处理掉大流量攻击，源站层只面对清洗后的正常流量和少量漏网的应用层攻击，压力小很多，误伤概率也低。
适配方案第四步：自建机房源站要做“黑洞路由”前的最后一公里防护
即使有DDoS云防护，自建机房的IP地址一旦暴露，攻击者仍然可以绕过云防护直接攻击源站IP。很多机房在检测到大流量攻击时会自动触发黑洞路由，把被攻击IP屏蔽一段时间，这期间业务完全不可用。要避免这种情况，必须做到源站IP完全不对外可见。
具体做法包括：所有对外服务只绑定DDoS云防护的回源IP白名单，机房防火墙只允许清洗节点的IP段访问80和443端口；源站服务器不配置公网IP，或者配置了公网IP也不在DNS中暴露；如果业务需要主动外联，使用独立的NAT网关出口，与入站流量隔离。对于已经暴露过的历史IP，建议直接更换，因为攻击者可能已经记录并会持续攻击。
适配方案第五步：混合云之间的会话保持和健康检查要单独规划
DDoS云防护通常会对源站做健康检查，如果检查失败就停止转发流量。混合云架构中，公有云源站和自建机房源站可能互为备份，健康检查的路径和阈值需要单独设置。建议把健康检查的探测源设置为清洗节点的内网地址，探测路径指向源站的一个轻量级健康检查接口，而不是首页。首页可能包含大量动态内容，响应慢会导致健康检查误判。
会话保持方面，如果网站使用了基于源IP的会话保持，DDoS云防护的接入会改变用户源IP，导致会话丢失。解决方式是在防护节点开启X-Forwarded-For头传递，源站从该头中获取真实用户IP做会话保持。对于跨机房的会话共享，建议使用集中式Redis或数据库存储会话，而不是依赖单机内存。
适配方案第六步：监控和应急切换要自动化，不能靠人工操作
混合云部署的网站在遭受DDoS攻击时，最怕的是运维团队手动切换DNS或者手动调整防护策略，响应时间太长。建议在监控系统中设置自动触发规则：当检测到入站流量超过阈值或者源站响应时间异常时，自动将流量切换到DDoS云防护的高防节点，同时通知运维人员。切换动作可以通过DNS API或者负载均衡的权重调整来实现。
应急切换的脚本要提前写好并测试，包括切换后的回源地址变更、防火墙白名单更新、会话存储切换等步骤。如果条件允许，可以在公有云上保留一套最小化的静态页面环境，当自建机房完全不可用时，至少能提供降级服务，而不是整个网站打不开。
适配方案第七步：成本控制的关键在于按需启用高防节点
DDoS云防护的高防节点通常按带宽或攻击流量计费，如果全天候启用高防线路，成本会非常高。混合云部署的优势在于可以把日常流量走基础防护节点，只有在检测到攻击时才切换到高防节点。具体实现上，可以在DNS解析层设置默认线路走基础防护，当监控系统发现攻击时，通过API修改解析记录，把流量切换到高防线路。
切换过程会有几分钟的DNS生效时间，这段时间内攻击流量可能已经打到源站。为了缩短切换时间，可以提前把高防节点的IP和基础防护节点的IP配置在同一个负载均衡池中，通过权重控制流量分配。攻击发生时，直接调整权重，把流量全部导向高防节点，DNS不用变更，切换速度可以控制在秒级。
适配方案第八步：针对混合云特有的“东西向流量”做防护策略隔离
混合云中除了用户访问网站的南北向流量，还有大量公有云和自建机房之间的东西向流量，比如数据库同步、缓存更新、消息队列消费等。这些流量如果经过DDoS云防护，不仅增加延迟，还可能被防护策略误拦截。正确的做法是东西向流量走内网专线或VPC对等连接，完全不经过公网和DDoS防护节点。
如果专线条件不具备，必须走公网传输，建议使用独立的加密通道，并在防火墙中只放行特定源IP和目的端口。DDoS防护策略中要明确排除这些内部服务IP段，避免清洗规则把正常的数据库同步流量当成攻击拦截。很多混合云故障的根源就是防护策略没有区分内外流量，一刀切地开启了全量检测。
实际部署中的配置示例
以一个典型的混合云网站为例：前端应用部署在公有云，数据库和文件存储部署在自建机房。DDoS云防护接入后的流量路径如下：用户请求先到达DDoS云防护节点，清洗后通过内网回源到公有云前端应用；前端应用处理业务逻辑时，通过专线访问自建机房的数据库和文件存储。整个链路中，用户侧只看到DDoS云防护的IP，公有云源站和自建机房源站都不暴露公网IP。
在防护策略上，DDoS云防护开启网络层攻击防护和基础CC防护，应用层WAF部署在公有云前端应用之前，自建机房入口只放行来自公有云VPC的专线流量。当攻击发生时，DDoS云防护自动切换到高防节点，同时公有云前端应用根据负载情况自动扩容，自建机房数据库通过读写分离和缓存层吸收压力。
这种架构下，攻击者无法直接攻击自建机房，因为机房IP不对外可见；也无法通过攻击公有云源站绕过DDoS防护，因为源站只接受来自清洗节点的回源流量。即使攻击者通过某种方式拿到了源站真实IP，机房防火墙的IP白名单机制也能把攻击流量挡在门外。
最后要避免的几个常见误区
不要认为接入DDoS云防护就万事大吉，混合云环境下防护策略必须持续调优。攻击者会不断变化攻击手法，防护规则也需要定期更新。建议每月做一次防护策略审计，检查是否有未接入的子域名、是否有新的源站IP暴露、回源白名单是否需要更新。
不要把DDoS云防护当成WAF来用。DDoS云防护的核心能力是大流量清洗和网络层攻击防御，应用层攻击的精细防护需要独立的WAF设备或服务。两者配合使用才能覆盖完整的攻击面。
不要忽视日志和流量分析。DDoS攻击发生前往往有预兆，比如特定IP的请求频率突然升高、特定端口的连接数异常增长。通过分析DDoS云防护的日志和流量数据，可以提前发现攻击迹象，在攻击造成实际影响前调整防护策略。
混合云部署网站的DDoS云防护适配，本质上是一个流量调度和策略分层的问题。把入口统一、把回源路径控制好、把防护策略分层部署、把监控和切换自动化，这四件事做到位，混合云架构下的DDoS防护能力不会比纯公有云差，甚至在源站分散的情况下，抗攻击的弹性反而更强。
