某电商站点开启WAF后，攻击确实少了，但结算接口的P95时延增加了近一倍。复盘发现，同一请求先在CDN做一次解密，又被转发到独立WAF再次解密，日志字段还无法对应。问题不是WAF无效，而是两套系统被简单串在一起，没有按业务重新设计流量路径。
CDN与WAF联合部署的目标，应是让明显异常流量尽早结束，让缓存请求少走弯路，让动态敏感接口得到更深检测，同时确保源站不可绕过。下面从架构、策略、证书、日志和降级五个方面说明如何落地。
先确定WAF部署在哪一层
常见方案有边缘内置WAF、CDN后独立云WAF、源站前本地WAF。边缘内置路径短、扩展快，适合大多数互联网流量；独立云WAF便于集中管理复杂规则；本地WAF能结合内部网络，但必须保证入口带宽不会先被打满。选择时应看动态请求比例、合规边界、规则复杂度和运维能力。
不要让同一流量无意义地重复检测。可以让边缘负责协议异常、已知攻击、Bot和速率，深度业务规则由后端WAF处理。若需要多层检测，应统一请求ID并清楚定义每层职责。
一条请求应如何经过CDN、WAF与源站
请求首先完成DNS调度和TLS握手，再进入网络层清洗与访问控制。静态公开资源在必要检查后可直接命中缓存；动态请求进入WAF，完成规范化、规则匹配和会话判断，最后通过受信回源连接到应用。源站只接受CDN或WAF出口，并验证Host、证书或签名。
响应方向同样需要设计。带有Set-Cookie、账号信息或个性化内容的响应不应被公共缓存；安全头、内容类型和缓存指令要在最终出口复核，避免中间系统覆盖应用原意。
规则分层比规则数量更重要
第一层处理协议和格式异常，第二层覆盖SQL注入、XSS、路径遍历等通用攻击，第三层约束登录、下单、查询等业务动作，第四层结合Bot和账号风险。规则越靠后，越需要业务上下文，不能只依赖通用特征。
上线新规则时先观察再阻断。记录命中请求、用户影响和源站结果，排除搜索引擎、合作方回调和移动端旧版本。对于高风险接口，可先要求挑战或提高验证，而不是立刻封禁整个IP段。
证书、真实IP与日志最容易出错
证书应有明确托管边界和自动续期告警。真实客户端IP只能从可信代理写入的字段读取，并在最后一个可信节点覆盖外部同名请求头。否则攻击者可伪造IP绕过限速或污染审计。
CDN、WAF和源站日志至少共享请求ID、时间、客户端地址、Host、路径、状态码和规则结果。没有统一关联键，故障时只能人工拼接，既慢又容易误判。敏感字段在入库前应脱敏，并按用途控制保留期限。
故障与攻击同时发生时如何降级
WAF不可用时直接旁路看似能恢复业务，却可能让攻击流量直达源站。更稳妥的做法是按业务分级：静态资源继续缓存，已知安全接口使用上一版策略，支付和后台保持严格校验，非核心动态接口限速或暂停。
演练应覆盖规则误杀、证书异常、回源链路中断、控制面不可用和大流量攻击。每种场景都需要负责人、触发阈值、降级动作和回滚条件。联合部署是否成熟，最终看的是异常时能否保持可预测。
落地检查清单
- 画出包含响应方向的完整流量路径
- 为CDN与WAF划分清晰检测职责
- 限制源站仅接受受信回源
- 统一真实IP规则与请求ID
- 新规则先观察、再灰度、最后阻断
- 演练WAF故障与攻击并发场景
结语
CDN+WAF不是两款产品叠加，而是一条需要共同设计的交付链路。职责分层、源站封闭、日志贯通和可控降级同时成立，才能在提高安全性的同时避免新的性能与可用性问题。
