GraphQL 的灵活查询能力带来了一个副作用：单个请求可以构造出极其复杂的查询，消耗大量服务端资源。这种查询复杂度攻击（Query Complexity Attack）本质上是一种应用层（Layer 7）DDoS 攻击。CDN 边缘节点作为流量入口，能否有效抵御这类攻击？答案是有条件的。本文先明确 CDN 在应用层 DDoS 防护中的边界，再给出可执行的配置方案。
GraphQL 查询复杂度攻击的典型特征
攻击者构造嵌套深度大、字段数量多或使用了别名（Alias）的查询，使得单个请求的解析和计算成本远高于普通请求。由于请求体积小、频率可控，传统的网络层 DDoS 防护（如基于流量清洗）很难识别。AWS 的 DDoS 事件响应指南指出，对于应用层（Layer 7）DDoS 攻击，默认不会自动应用缓解措施，以避免误伤正常用户流量（来源：AWS DDoS 事件响应指南）。这意味着，依赖云厂商的自动防护是不够的，需要主动配置针对应用层的策略。
CDN 边缘节点能做什么：三层防线
CDN 边缘节点分布在离用户更近的位置，可以在此处拦截恶意流量，避免其到达源站。具体可以从三个层面入手：
1. 缓存与内容分发：减少源站计算压力
Cloudflare 的缓存文档指出，缓存将频繁访问的内容（如图片、视频或网页）存储在分布式数据中心，从而减少源站负载（来源：Cloudflare 缓存文档）。对于 GraphQL 的 GET 查询（如果支持），可以配置缓存规则，将相同查询的结果缓存起来。但要注意：GraphQL 通常使用 POST 请求，且查询往往带有变量，缓存命中率可能很低。因此，缓存只能缓解部分只读查询的重复请求，无法应对动态查询。
2. 速率限制与请求特征过滤
CDN 边缘节点可以按 IP、用户代理或自定义请求头进行速率限制。例如，限制单个 IP 每秒的请求数，或对包含特定深度字段的查询进行拦截。但攻击者可能分散在大量 IP 上，且查询特征可能不断变化，因此需要结合 WAF 规则。
3. WAF 规则与托管规则集
许多 CDN 提供 WAF 功能，可以检测并阻止恶意请求。例如，配置规则拦截包含深层嵌套或大量别名的查询。AWS 的防护选项提到，对于应用层攻击，你可以提供自己的缓解措施（来源：AWS DDoS 事件响应指南）。这意味着，使用 CDN 的 WAF 规则是可行的，但需要精细调优，避免误杀正常复杂查询。
边界条件：CDN 无法替代源站防护
CDN 边缘节点的防护能力并非万能。首先，CDN 无法解析 GraphQL 查询的实际计算成本，只能基于请求特征进行粗粒度过滤。其次，如果攻击流量直接绕过 CDN（例如攻击源站 IP），CDN 便无能为力。因此，CDN 防护通常需要与源站自身的防护（如查询深度限制、成本分析）配合。AWS 的 Well-Architected 框架强调，架构设计需要权衡取舍（来源：AWS 安全性支柱），这意味着不能依赖单一措施。
可执行方案：三步配置 CDN 边缘节点
以下是一个基于 CDN 的实践步骤，适用于使用 Cloudflare 或类似服务的场景：
- 启用缓存：为 GraphQL 的 GET 请求（如果支持）配置缓存规则，设置合理的 TTL（如 60 秒），并仅缓存幂等查询。参考 Cloudflare 的缓存文档，使用 Cache Rules 指定缓存哪些资源（来源：Cloudflare 缓存文档）。
- 配置 WAF 规则：在 CDN 的 WAF 中创建规则，拦截包含可疑特征的请求，例如查询深度超过 10 的 JSON 请求体。可以先用日志模式观察误报率，再切换为阻断。
- 设置速率限制：对 GraphQL 端点（如 /graphql）设置每秒请求数限制，例如每个 IP 每秒 10 个请求。对于来源分散的攻击，可以结合 IP 信誉库。
常见误区与失败条件
一个常见误区是认为 CDN 缓存可以解决所有 GraphQL DDoS。实际上，缓存只适用于可缓存的查询，且攻击往往使用随机变量，导致缓存失效。另一个误区是过度依赖速率限制，可能误伤正常用户（例如学校或企业出口 IP）。失败条件包括：未配置源站防护、CDN 规则过于宽松导致攻击穿透、或规则过于严格导致正常业务中断。因此，建议在实施前进行充分的测试。
总结
CDN 边缘节点可以在一定程度上抵御 GraphQL Query Complexity DDoS 攻击，但它是整体防护的一部分，而非全部。通过缓存、WAF 和速率限制的组合，可以显著降低攻击影响，但必须明确边界，并配合源站防护。最后，建议持续监控和调整规则，以适应不断变化的攻击模式。
参考资料
延伸阅读