CDN GraphQL看似简单，真正落地时却很容易踩坑。当你第一次接触GraphQL，很可能会被它的灵活性吸引：客户端可以精确指定需要的字段，一个请求就能拿到所有关联数据，再也不需要REST里的多次往返。但这份灵活的背后，藏着一个容易被忽视的安全漏洞——查询复杂度（Query Complexity）。攻击者不需要发送海量请求，单次精心构造的复杂查询就可能让你的服务器CPU飙升、数据库连接耗尽，形成一种“低流量、高杀伤”的DDoS攻击。
传统的DDoS防御通常关注每秒请求数（RPS）和带宽，对这类应用层攻击并不敏感。好在，CDN边缘节点不仅能加速内容分发，还能充当第一道安全哨兵。本文会用最直白的语言，带你理解Query Complexity的原理，以及如何利用CDN边缘的计算能力，在请求到达你的GraphQL服务器之前就将其拦截。
一头雾水的“查询复杂度”到底是什么？
我的处理经验
GraphQL的查询结构像一棵树。你可以从根节点开始，请求某个对象的字段，然后通过关联关系继续嵌套更多的子对象。比如一个博客API：
query {
user(id: 1) {
name
posts {
title
comments {
content
author {
name
posts {
title
// 继续无限嵌套
}
}
}
}
}
}理论上，客户端可以无限向下嵌套。每次展开都可能触发数据库的多次查询（N+1问题更是雪上加霜）。GraphQL服务器通常会在执行前解析整个查询结构，构建执行计划，这个过程本身也需要消耗CPU和内存。如果某个查询嵌套了10层，每个字段又请求多个关联对象，总的数据加载量可能呈指数级增长。
Query Complexity就是量化一次查询“有多重”的指标。常见算法有：
- 字段计数法：统计查询中所有请求的字段数量，达到阈值则拒绝。
- 深度限制法：只允许最大嵌套层数（例如5层），超过则报错。
- 加权复杂度法：给每个字段预先分配一个权重，根据用户角色或字段类型动态计算总分。
其实，大部分GraphQL框架（如graphql-ruby、graphql-java、Apollo Server）都内置了复杂度限制插件。然而，这些限制是在服务器端执行的——也就是恶意查询已经穿透了网络层，到达你的应用进程，消耗了计算资源后才会被拒绝。
补充参考：此处可内链到“CDN GraphQL故障排查实例”。
为什么有人拿它打DDoS？
故障定位思路
假设你的GraphQL API没有限制查询复杂度，攻击者可以编写一个只有几十行但嵌套极深的查询，将其封装成很小的HTTP请求（通常几KB）。然后以每秒几个请求的低速率持续发送。从网络流量上看，完全正常，甚至无法触发传统的CC防护策略。但你的服务器每处理这样一个查询，可能需要数百毫秒甚至几秒的数据库查询时间，CPU和连接池很快被耗尽。
这种攻击的杀伤力在于：
- 流量伪装性强：请求量低，防火墙和负载均衡器很难识别为攻击。
- 耗尽后端资源而非带宽：攻击者只需要几台普通机器就能瘫痪你的API。
- 绕过速率限制：传统的基于IP的速率限制对低频率攻击效果很差。
你可能会想：“我可以在服务器端加上复杂度限制和深度限制啊。” 对，但这意味着恶意请求依然消耗了你的服务器资源（CPU、内存），只是比没有限制时少一些。理想的做法是在请求到达服务器之前就把它挡在外面。
CDN边缘节点为什么要管这档事？
验证与回滚
CDN边缘节点分布在全球各地，离用户最近。它们不仅仅缓存静态资源，现代CDN（如Cloudflare、Akamai、Fastly，以及国内的阿里云CDN、腾讯云CDN等）都提供了在边缘运行自定义代码的能力——通常称为边缘计算（Edge Computing）或边缘函数（Edge Functions）。
这意味着，你可以在CDN节点上写一段程序，当请求到达时，先解析它的HTTP Body（GraphQL查询体），判断查询复杂度，如果超过阈值就直接返回403或429状态码，不再回源。整个过程发生在距离用户最近的边缘节点，源站甚至根本不知道有这次请求。
这样做有两个核心价值：
- 过滤靠近攻击源：恶意流量在边缘就被丢弃，减轻了骨干网和源带宽的压力。
- 不消耗源站资源：无论攻击者构造多少个复杂查询，你的应用服务器CPU永远维持在正常水平。
实战：在边缘节点实现Query Complexity检查
以下是一个基于Cloudflare Workers的示例（其他边缘计算平台逻辑类似）。我们假设你的GraphQL API接受POST请求，Content-Type为application/json，body中包含{“query”:”…”}。
第一步：解析请求中的GraphQL查询
async function handleRequest(request) {
if (request.method === 'POST' && request.headers.get('content-type').includes('application/json')) {
const body = await request.json();
const query = body.query;
if (!query) {
return new Response('Missing query', { status: 400 });
}
// 开始复杂度检查
const complexity = calculateQueryComplexity(query);
if (complexity > MAX_COMPLEXITY) {
return new Response('Query too complex', { status: 429 });
}
// 通过后，继续回源
return fetch(request);
}
// 非GraphQL请求直接回源
return fetch(request);
}第二步：计算查询复杂度
我们不需要实现完整的GraphQL解析器（那样太重了），一个简单的策略是：
- 使用正则或轻量解析提取所有字段名，统计总数。
- 同时检查嵌套深度：通过大括号匹配，记录最大嵌套层级。
但更好的方式是引入一个微型GraphQL解析器（如graphql-js的parse函数），不过边缘函数环境有1MB代码大小限制，直接包含完整解析器可能超限。可以自己写一个简单的状态机，只关心字段和嵌套，忽略变量、指令等。以下是一个极简实现：
function calculateQueryComplexity(query) {
const fieldRegex = /b(w+)s*(?=()?/g; // 简单匹配标识符
let depth = 0;
let maxDepth = 0;
let fieldCount = 0;
// 去掉字符串字面量和注释，避免误匹配
const cleaned = query.replace(/".*?"/g, '').replace(/#.*?n/g, '');
for (let char of cleaned) {
if (char === '{') {
depth++;
maxDepth = Math.max(maxDepth, depth);
} else if (char === '}') {
depth--;
}
}
// 简单统计字段（非精确，仅供演示）
const fields = query.match(/b[a-zA-Z_][a-zA-Z0-9_]*b/g);
fieldCount = fields ? fields.length : 0;
// 最终复杂度 = 字段数 * (1 + 深度权重)
return fieldCount * (1 + maxDepth);
}注意：这个实现非常粗糙，仅用于说明原理。生产环境下建议使用经过验证的GraphQL解析器（如graphql-js的parse），通过评估AST来计算复杂度。很多CDN平台允许你上传npm包，你可以将graphql-js的parse和validate函数部署到边缘。
第三步：设定合理的阈值
阈值取决于你的API设计。比如你允许的最大查询复杂度为1000。假设平均每个查询包含20个字段，最大深度4层，那么复杂度约20*5=100。如果某个查询突然达到2000，几乎可以肯定是恶意的。你可以在边缘节点上为不同路径或API版本设置不同的阈值。
同时，为了避免误伤正常复杂查询（比如管理后台的数据看板），可以维护一个白名单机制：将某些API Key或token识别出来，跳过复杂度检查。在边缘函数中通过请求头或Cookie判断。
CDN GraphQL：需要注意的实际问题
性能开销
在边缘节点执行GraphQL解析会增加请求延迟。但由于边缘节点通常离用户很近，且只做文本解析（不涉及数据库），额外耗时通常在毫秒级别。相比被恶意查询拖垮源站的风险，这个开销完全可以接受。如果你的API请求量极大，可以设置一个缓存：对完全相同的查询体，第一次计算后缓存结果，后续直接放行或拦截。
支持批量查询
一些GraphQL客户端会使用批量查询（batch query）在一个请求中发送多个查询。此时需要将整个请求数组遍历，累加每个查询的复杂度。如果总复杂度超过阈值，拒绝整个批次。
与后端限制的配合
边缘防御不是银弹。建议在源站GraphQL服务器上也设置鲁棒的复杂度限制和持久化缓等，作为最后一道防线。边缘节点主要用来过滤明显异常的流量，减少对源站的冲击。
日志与告警
边缘节点记录被拒绝的请求（包括客户端IP、查询体摘要、复杂度数值），定期分析这些日志，可以调整阈值、发现新的攻击模式。
进阶阅读：此处可内链到“CDN GraphQL性能优化”指南。
延伸阅读：此处可内链到“CDN GraphQL配置案例”相关文章。
CDN GraphQL：总结：让CDN边缘成为你的GraphQL保镖
配置前的检查
GraphQL的Query Complexity DDoS攻击，利用的是应用层语义漏洞，传统网络层防御很容易漏防。借助CDN边缘节点的计算能力，我们可以将复杂度检查前置到距离用户最近的地方，在不增加源站负担的前提下，快速过滤恶意查询。
这种方案特别适合那些已经使用CDN加速的GraphQL API，不需要额外部署硬件或中间件，只需在边缘函数中写几百行代码就能获得显著的防护效果。当然，实际部署时还需要根据你的API特性反复调参，并配合其他安全措施（如身份验证、速率限制）。但无论如何，让边缘节点承担起“第一道哨兵”的角色，是应对这类新兴攻击的明智选择。
下一次当你的GraphQL服务器感受到莫名卡顿时，不妨先看看是不是有人给你送了一颗“复杂查询炸弹”。在CDN边缘把它拆掉，比等它爆炸后重建系统要划算得多。真正做好CDN GraphQL，靠的不是参数堆砌，而是持续验证。
延伸阅读