应用防火墙与CDN不是二选一，而是把“缓存分流、边缘清洗、回源检测、日志联动”串成一条链路；CDN挡住重复流量和基础攻击，WAF守住业务入口的精细规则，两者协同后源站压力更小、误杀更可控。 这套思路听起来像架构问题，落到操作上其实是一组域名接入、回源白名单、规则调优和日志告警的细节。
应用防火墙和CDN有什么区别与联系？先厘清边界
分发网络,负责就近缓存、静态加速、流量调度，部分套餐自带基础DDoS清洗和WAF能力，WAF是Web应用防火墙，重点看HTTP/HTTPS层攻击，比如SQL注入、XSS、CC、爬虫和API滥用，两者协同不是把设备叠在一起，而是让请求先到边缘节点，静态内容直接返回，动态请求经过WAF检测后再回源。
| 维度 | CDN | WAF | 协同价值 |
|---|---|---|---|
| 主要位置 | 边缘节点 | 边缘或源站前 | 分层过滤 |
| 核心能力 | 缓存、加速、调度、基础清洗 | 应用层规则、CC防护、Bot管理 | 降低源站暴露 |
| 典型盲区 | 动态攻击、复杂业务逻辑 | 大流量重复请求消耗 | 能力互补 |
| 部署方式 | CNAME接入 | 域名接入、反向代理、SDK | 同一域名链路闭环 |
CDN更像前置缓存和流量调度层
图片、JS、CSS、视频切片这类静态资源，适合在CDN边缘设置较长缓存。较大比例的静态请求可以在边缘直接返回，源站只处理动态接口和缓存未命中请求，问题在于，如果源站IP暴露，攻击者可以绕过CDN直打源站，所以CDN接入后必须同步做回源保护。
WAF更像业务入口的检测与拦截层
WAF会看URL、参数、Header和Body，匹配SQL注入、XSS、命令注入、恶意爬虫等规则，它放在CDN边缘时能更早拦截，但规则不能一上来就全拦截，比较稳妥的做法是先开观察模式，看拦截日志和误杀情况，再逐步切到拦截模式。
两者协同的底层逻辑：边缘分流、清洗、回源
一条典型请求链路可以拆成下面几步：
- DNS解析到CDN提供的CNAME。
- 边缘节点判断缓存,静态资源命中就直接返回。
- 动态请求进入边缘WAF规则组,做CC限速和Bot识别。
- 可疑请求触发验证码、挑战或拦截。
- 干净请求回源,源站安全组只放行CDN回源IP段。
- CDN日志、WAF日志、源站日志汇总告警。
WAF与CDN协同防护怎么配置？从请求链路看分工
第一步：域名接入CDN并开启回源保护
在CDN控制台添加加速域名,配置源站地址、回源协议和回源Host，DNS侧把业务域名解析到CDN的CNAME，源站安全组只放行CDN回源IP段，其他公网访问默认拒绝，回源IP段会变化，建议用厂商API定期同步，不要手工写死。
以Linux源站为例,策略思路是只允许CDN回源地址访问443端口：
iptables -A INPUT -p tcp --dport 443 -s CDN回源IP段 -j ACCEPT iptables -A INPUT -p tcp --dport 443 -j DROP
云服务器上更常见的是安全组入方向规则,源地址填CDN回源IP段，协议端口填TCP:443。
第二步：在CDN边缘启用WAF防护策略
控制台路径通常是“CDN域名管理 → 安全防护 → WAF → 防护策略”，先开启OWASP基础规则集，观察一段时间，登录、支付、搜索、下单接口单独建规则组，不要全站一套规则打到底。
| 路径 | 缓存策略 | WAF策略 | 限速建议 |
|---|---|---|---|
| /static/ | 长缓存 | 基础规则 | 不限 |
| /api/login | 不缓存 | 严格规则加验证码 | 按IP限速 |
| /api/order | 不缓存 | 业务规则加Bot管理 | 按用户令牌限速 |
| /api/search | 短缓存 | 防爬与CC规则 | 按URL加IP限速 |
第三步：配置回源白名单与真实IP获取
请求经过CDN后,源站看到的可能是CDN节点IP，Nginx可以用real_ip模块还原客户端地址：
set_real_ip_from CDN回源IP段; real_ip_header X-Forwarded-For; real_ip_recursive on;
应用层读取X-Real-IP或X-Forwarded-For第一跳，日志格式里加入$http_x_forwarded_for，方便和WAF日志关联，注意只信任CDN回源IP传来的Header，不要信任客户端自己伪造的X-Forwarded-For。
第四步：日志联动与告警处置
CDN访问日志、WAF拦截日志、源站Nginx日志要能对上同一个请求，告警可以盯三个信号：WAF拦截量突增、回源5xx升高、缓存命中率下降，处置时先看观察模式日志，确认误杀就加白名单，确认攻击就调CC阈值，源站再用限流兜底。
tail -f /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head
nginx -T | grep limit_req
电商大促场景下WAF与CDN如何协同防护
大促页面的特点是静态资源多、秒杀接口高频、库存查询集中，商品图、CSS、JS提前预热到CDN，设置长缓存；登录、下单、库存接口不缓存，走WAF严格规则和CC限速，秒杀入口加令牌、验证码、设备指纹，源站用队列削峰。
- 静态资源按后缀和目录设置缓存,活动前做CDN预热。
- 动态API按URL加IP加User-Agent做频率控制。
- 回源设置QPS上限,源站数据库连接池保留余量。
- 先放1%流量观察WAF误杀，再逐步放量。
- 源站Nginx配置限流兜底：
limit_req_zone $binary_remote_addr zone=api:10m rate=20r/s;
location /api/ {
limit_req zone=api burst=40 nodelay;
}
业内专家指出,大促防护的关键不是堆规则，而是让缓存和限速先削峰，WAF再做精细拦截。
企业部署WAF加CDN一年多少钱？成本与选型思路
企业部署WAF加CDN一年多少钱,取决于流量规模、防护等级和日志留存要求，不能只看套餐标价，常见成本项包括CDN流量或带宽、WAF套餐、Bot管理、日志存储和重保服务。
| 成本项 | 常见计费 | 影响因素 | 控制方法 |
|---|---|---|---|
| CDN流量/带宽 | 按量或包月 | 流量峰值、缓存命中率 | 提高缓存命中、压缩图片 |
| WAF套餐 | 包年包月或按量 | 域名数、QPS、规则数 | 按业务域名分级 |
| Bot管理/CC | 增值项 | 请求量、策略复杂度 | 只对关键接口开启 |
| 日志存储 | 按存储量 | 保留天数 | 冷热分层 |
| 专家服务 | 按次或包年 | 重保、应急 | 重保期临时启用 |
流量波动大的业务更适合按量付费,稳定业务用包年包月更容易做预算，行业共识认为，缓存命中率提升能明显降低CDN回源成本，这比单纯压单价更有效。
北京地区WAF与CDN协同防护方案怎么选
北京地区WAF与CDN协同防护方案怎么选,先看用户分布和合规要求，华北节点覆盖、BGP线路质量、备案与等保日志留存、本地技术响应，都是实际选型时要问清楚的，控制台里确认CDN华北节点、回源线路、IPv6和HTTPS证书支持情况；等保场景下检查WAF日志保留周期和导出方式，北京业务如果面向全国，不要只看本地节点，还要看跨区域回源质量。
应用防火墙与CDN协同防护的核心，是让CDN做流量前置和缓存削峰，让WAF做应用层精细拦截，再用回源白名单和日志联动把链路闭合。 对多数面向公众的业务，这套组合比单独堆设备更稳。
应用防火墙与内容分发网络协同防护常见问题
WAF和CDN必须一起用吗？
不是必须,静态内容多、流量波动大、源站需要隐藏时，CDN价值明显；业务接口复杂、攻击以应用层为主时，WAF更关键，电商、金融、SaaS这类暴露面大的业务更适合组合使用，小型站点可以先用CDN基础防护加源站安全组。
CDN已经清洗了DDoS，WAF还要开吗？
要区分流量层和应用层,CDN和云清洗主要处理大流量DDoS，WAF处理SQL注入、XSS、CC、爬虫等应用层攻击，多数情况下，DDoS清洗不能替代WAF规则，即使CDN套餐包含WAF，也要检查规则是否开启并按业务调优。
协同防护后源站真实IP怎么隐藏？
源站安全组只放行CDN回源IP段,DNS只保留CNAME，不在邮件、论坛、代码仓库暴露源站IP，回源使用HTTPS并校验回源Host，定期从外部探测源站端口是否可直连，源站端口对公网不可达，是隐藏真实IP的基础条件。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/783404.html
