云技术博客在云原生架构和传统IDC混合部署的场景下，WAF（Web应用防火墙）、CDN（内容分发网络）和DDoS高防往往是“三件套”。很多新手甚至资深运维容易陷入一个误区：认为把这三个产品都买上、都开启，就万事大吉了。
实际上，配置顺序不对、回源IP未正确透传、防护层级重叠或真空，不仅会导致业务延迟飙升、被误拦截，甚至在遭受大规模攻击时出现“防御失效”的尴尬局面。
要避免配置冲突，核心逻辑只有一条：明确流量入口、理清IP归属、分层防御。
下面我从实战角度，拆解几种常见组合模式的正确姿势。
一、 先搞清三个角色的本质边界
在谈配置前，必须对齐认知，否则后续全是坑：
- DDoS高防：负责抗网络层/传输层的大流量攻击（SYN Flood, UDP Flood等）。它的核心能力是清洗大流量，保护后端服务器不被打挂。它通常有一个独立的“高防IP”。
- CDN：负责提速和边缘缓存。它将静态资源推送到边缘节点，减少回源压力。同时，CDN本身也具备一定的L7基础防护能力，但主要目的是提速。
- WAF：负责应用层的深度检测（SQL注入, XSS, CC攻击等）。它需要看到完整的HTTP请求头、Body才能做规则匹配。
关键冲突点在于：当这三者串联时，谁看到的IP是真实的？谁在清洗流量？
二、 三种典型架构的正确配置方案
场景 1：标准互联网接入（CDN + WAF + 源站）
适用场景：常规业务，无超大流量DDoS风险，或依赖云厂商基础DDoS防护即可。
这是最常见的架构。流量走向：用户 -> CDN -> WAF -> 源站 或者 用户 -> CDN -> 源站（WAF旁路或集成在CDN中）。
正确配置要点：
-
WAF与CDN的关系：
- 推荐模式：WAF作为CDN的后置服务（或集成模式）。 目前主流云厂商（阿里云、腾讯云等）都支持将WAF直接绑定到CDN域名。
- 为什么？ 如果WAF放在CDN前面，CDN的缓存价值可能受损（因为WAF可能动态判断），且增加了跳数。如果WAF放在CDN后面（即CDN回源到WAF IP，WAF再回源到真实服务器），则能确保所有经过CDN的流量都经过WAF检测。
- 注意回源IP： 如果你选择CDN回源到WAF，你需要将WAF提供的CNAME或IP配置为CDN的回源地址。此时，源站收到的请求来自WAF IP，而不是最终用户IP。因此，源站必须信任WAF IP段，或者通过Header透传（如
X-Forwarded-For）获取真实用户IP。
-
避免CC攻击误杀：
- CDN本身有频率限制。如果WAF检测到CC攻击并封禁IP，而CDN节点分散，可能导致部分CDN节点正常转发，部分被WAF阻断，造成用户体验不一致。
- 解法： 开启CDN的“自适应提速”或“智能调度”，并在WAF中设置合理的阈值，避免对同一用户的频繁刷新进行过度拦截。
-
HTTPS配置一致性：
- CDN和WAF都需要处理SSL/TLS卸载。务必确保两者的证书一致，且SNI（Server Name Indication）配置正确，否则会出现握手失败。
场景 2：高防+CDN+WAF（抗D需求强）
适用场景：游戏、XX、直播等行业，面临高频DDoS攻击，同时有复杂的Web应用防护需求。
这是最复杂也最容易出错的组合。流量走向：用户 -> DDoS高防IP -> CDN -> WAF -> 源站 或 用户 -> DDoS高防IP -> WAF -> CDN -> 源站。
核心原则：高防IP必须在最外层。
正确配置步骤：
-
第一层：DDoS高防
- 将你的业务域名解析到高防提供的独立IP（而非CDN CNAME）。
- 在高防控制台配置“转发规则”，将TCP/UDP流量转发给下一层设备（通常是CDN或WAF的IP）。
- 关键点： 高防IP只负责清洗大流量，不关心HTTP内容。它只需要知道把干净的流量扔给谁。
-
第二层：CDN 或 WAF（取决于你的优先级）
-
方案A（优先提速）：高防 -> CDN -> WAF -> 源站
- 将CDN域名的CNAME指向高防转发的目标（通常是CDN自己的接入点，但这里需要特殊配置）。
- 更常见的做法是： 高防IP转发给CDN的源站IP，但这个源站IP其实是WAF的XXIP，或者直接指向源站（如果WAF集成在CDN中）。
- 最佳实践： 使用云厂商的“高防+CDN联动”功能。例如，阿里云的高防IP可以直接绑定CDN域名，由CDN处理提速，WAF作为CDN的一个模块启用。这样，高防清洗后的流量直接进入CDN边缘，再由CDN回源时经过WAF。
-
方案B（优先安全）：高防 -> WAF -> CDN -> 源站
- 这种较少见，因为WAF通常不具备全球提速能力，会让延迟变高。除非你的业务对安全要求极高，且流量相对集中。
-
-
致命陷阱：回源IP伪装与CC攻击绕过
- 当流量经过高防->CDN->WAF时，每一层都会修改
X-Forwarded-For头。 - 问题： 攻击者可能伪造
X-Forwarded-For头，试图让WAF误以为请求来自可信IP（如CDN节点IP），从而绕过WAF的IP黑名单。 - 解法：
- 在WAF中，不要仅依赖
X-Forwarded-For来判断用户IP。应启用“客户端IP识别”功能，该功能会自动解析多层XX中的真实IP。 - 确保高防和CDN之间的链路是可信的，只在最后一级（WAF或源站）进行严格的IP信誉检查。
- 在WAF中，不要仅依赖
- 当流量经过高防->CDN->WAF时，每一层都会修改
-
端口与协议匹配
- 高防支持TCP/UDP/HTTP/HTTPS。
- CDN主要处理HTTP/HTTPS。
- 如果业务包含非HTTP协议（如WebSocket、自定义TCP协议），确保高防的配置覆盖了这些端口，并且CDN/WAF没有错误地拦截它们。
场景 3：仅WAF + 源站（无CDN，有DDoS高防）
适用场景：内部系统、小流量业务，不需要全球提速，但需要防DDoS。
- 流量走向：
用户 -> DDoS高防IP -> WAF -> 源站 - 配置重点：
- 高防IP解析到业务域名。
- 高防配置80/443端口转发到WAF的IP。
- WAF配置80/443监听，并设置回源到真实服务器IP。
- 注意： 这种情况下，WAF看到的是高防IP，需要通过Header透传获取真实IP。务必在WAF中开启“获取真实IP”功能，并配置可信XXIP段（即高防IP段）。
三、 避坑指南：常见配置冲突及解决
| 冲突现象 | 原因分析 | 解决方案 |
|---|---|---|
| 访问超时/502 Bad Gateway | CDN回源到WAF，WAF回源到源站，链路过长；或某一层SSL证书过期/不匹配。 | 1. 检查各层SSL证书有效性。 2. 调整CDN和WAF的超时时间，确保逐级递增（源站>WAF>CDN）。 3. 简化架构，尽量使用云厂商集成的“CDN+WAF”一体化服务。 |
| WAF拦截正常用户（误杀） | 用户IP被CC攻击池污染，或被WAF规则误判。由于经过多层XX，WAF看到的IP可能是高防或CDN节点的IP，导致批量封禁。 | 1. 在WAF中启用“IP白名单”，将CDN和DDoS高防的IP段加入白名单。 2. 使用WAF的“行为分析”而非单纯IP封禁。 3. 确保源站信任XXIP，通过Header获取真实IP进行风控。 |
| CDN缓存不更新 | WAF启用了动态内容过滤或URL重写，导致CDN无法正确识别缓存Key。 | 1. 在CDN中配置正确的缓存规则，排除WAF处理的动态API路径。 2. 确保WAF没有对静态资源进行不必要的修改。 |
| DDoS攻击下，WAF依然被压垮 | 高防IP带宽不足，或高防与WAF之间的链路成为瓶颈。 | 1. 提高高防IP的带宽峰值。 2. 确保高防到WAF的网络链路是专线或高质量公网链路，避免中间环节丢包。 3. 考虑启用“高防+CDN”联动，利用CDN的边缘节点分担部分流量压力。 |
四、 总结：最佳实践建议
-
首选云厂商一体化方案：
如果你使用的是阿里云、腾讯云、华为云等，强烈建议使用其提供的“CDN+WAF”或“高防+CDN+WAF”联动产品。这些产品在底层已经打通了IP透传、日志关联和策略同步，避免了手动配置带来的碎片化问题。 -
IP透传是生命线：
无论怎么组合，真实用户IP必须能准确传递到最后一道防线（通常是WAF或源站的安全组/防火墙）。务必配置好X-Forwarded-For、X-Real-IP等Header的透传，并在接收端启用相应的解析功能。 -
分层测试：
上线前，逐层测试：- 直连源站：验证业务是否正常。
- 经WAF：验证WAF规则是否生效，IP是否正确。
- 经CDN：验证缓存是否命中，延迟是否降低。
- 经高防：模拟DDoS攻击，验证清洗效果。
-
文档化与监控：
绘制清晰的流量拓扑图，记录每一层的IP范围、端口、协议。配置统一的日志收集（如ELK），将CDN日志、WAF日志、高防日志关联起来，以便在发生问题时快速定位是哪一层导致的故障。
记住，没有银弹。WAF、CDN、DDoS高防的组合是为了构建纵深防御体系，而不是简单的叠加。理解每一层的作用和局限，才能做到真正的“正确组合”。