把API网关直接架在源站机房里，等于让所有流量都长驱直入到业务服务器跟前。一旦有人拿着脚本对你最核心的下单接口、登录接口做高频调用，源站的CPU和带宽会率先被消耗殆尽，正常的身份认证逻辑反而来不及执行。更合理的做法是把安全能力下沉到CDN边缘节点：利用CDN在全球分布的节点，在请求离源站还有几百毫秒网络距离的时候，就完成身份认证判断和速率限制计数，只有合法且未超频的请求才会被回源转发。这篇文章就来完整聊聊这套架构怎么落地。
一、为什么安全策略要放在CDN边缘而不是源站
传统的API网关部署模式是“DNS直连源站，网关挡在最前面”，这个模式在中小流量下没什么问题，但它有三个天然缺陷。第一，所有请求无论好坏都要消耗源站入口带宽，攻击者用极低的成本（比如几台肉鸡发起CC攻击）就能换取你真实机房的带宽成本。第二，认证逻辑本身也是计算，JWT签名验证、RSA解密都是CPU密集操作，洪水般的非法请求会让网关进程把资源耗在解析垃圾请求上。第三，单点机房的网关在地域覆盖上存在延迟劣势，华南用户访问华北机房的接口，光网络往返就要几十毫秒。
把身份认证和速率限制前置到CDN边缘后，局面完全不同。CDN节点天然是分布式的，攻击流量会被打散到几百个边缘节点上，每个节点只需要处理本地用户的那一部分请求，限流计数也可以按节点维度进行，不存在集中式计数器的性能瓶颈。同时，边缘节点离用户更近，认证通过的请求走CDN骨干网回源，整体链路延迟反而更低。目前主流的CDN服务商（如Cloudflare、Akamai、阿里云CDN的边缘函数）都支持在边缘执行自定义逻辑，这为在边缘做Token校验提供了技术基础。
需要注意的一点是，边缘认证解决的是“请求合法性”的快速判断，它不能完全替代源站网关的完整鉴权。边缘节点上适合做轻量级的校验，比如JWT签名验证、API Key格式检查、基础的频率统计；而涉及数据库查询的复杂权限校验（比如用户是否有权限访问某个租户的数据）依然应该留在源站。这是一个分层过滤的设计思想：边缘过滤掉90%明显非法或超频的请求，源站只处理剩下的精细逻辑。
二、边缘身份认证的三种实现方式
1. API Key静态校验
最简单的方式是给每个接入方分配一个API Key，CDN边缘规则检查请求头中的Key是否存在、格式是否合法。这种方式实现成本最低，适合做第一道粗筛。但单纯的静态Key容易被泄露和伪造，所以通常配合IP白名单或者HMAC签名一起使用。
2. HMAC请求签名验证
签名机制能有效防止请求被篡改和重放。客户端用密钥对“请求路径+时间戳+请求体摘要”计算HMAC签名，放在请求头中传递；边缘节点用同样的算法重新计算并比对。时间戳参数可以顺便做重放防护，超过五分钟的请求直接拒绝。下面是一个边缘函数（以类JavaScript语法为例）验证签名的核心逻辑：
// CDN边缘函数：HMAC签名校验
async function handleRequest(request) {
const accessKey = request.headers.get('X-Access-Key');
const timestamp = request.headers.get('X-Timestamp');
const signature = request.headers.get('X-Signature');
const body = await request.text();
// 时间戳有效性检查，防止重放攻击
const now = Math.floor(Date.now() / 1000);
if (Math.abs(now - parseInt(timestamp)) > 300) {
return new Response(JSON.stringify({code: 401, msg: '请求已过期'}), {status: 401});
}
// 用密钥重新计算签名并比对
const secret = await getSecretByKey(accessKey);
const encoder = new TextEncoder();
const key = await crypto.subtle.importKey(
'raw', encoder.encode(secret),
{name: 'HMAC', hash: 'SHA-256'}, false, ['sign']
);
const data = encoder.encode(request.url + timestamp + body);
const signBuffer = await crypto.subtle.sign('HMAC', key, data);
const expected = btoa(String.fromCharCode(...new Uint8Array(signBuffer)));
if (signature !== expected) {
return new Response(JSON.stringify({code: 401, msg: '签名校验失败'}), {status: 401});
}
return fetch(request); // 校验通过，回源
}3. JWT令牌在边缘验证
JWT的签名验证只依赖公钥，不需要查数据库，非常适合放在边缘执行。只要源站的认证服务用RSA私钥签发令牌，把公钥分发到各边缘节点，边缘函数就能独立完成验证。验证通过后还可以把解析出的用户信息注入自定义请求头传给源站，源站省去重复解析的步骤：
// 边缘验证JWT（RS256算法）
async function verifyJwt(token, publicKeyPem) {
const parts = token.split('.');
if (parts.length !== 3) return null;
// Base64Url解码Header和Payload
const payload = JSON.parse(atob(parts[1].replace(/-/g, '+').replace(/_/g, '/')));
// 验证过期时间
if (payload.exp && payload.exp < Date.now() / 1000) {
return null;
}
// 实际生产中还需调用crypto.subtle.verify验证RS256签名
// 验证通过后返回payload，供后续注入回源请求头
return payload;
}三种方式各有适用场景：内部系统间的服务调用用API Key加IP白名单就够了；对外开放的API建议强制HMAC签名；面向C端用户的接口用JWT最顺手，因为登录后拿到的token可以直接复用。
三、速率限制的算法选型与边缘配置
固定窗口与滑动窗口
固定窗口计数是最直观的限流方式：每分钟一个计数器，超过阈值就拒绝。它的缺陷在于窗口边界问题——恶意请求可以集中在两个窗口的交界处（比如第59秒到第61秒）发起双倍流量，统计上完全合规但实际压垮服务。滑动窗口通过记录每个请求的精确时间戳，统计“最近60秒内”的请求数，避免了边界突刺，代价是需要存储更多数据。在边缘节点上，可以用简化的滑动窗口：把一分钟拆成六个10秒的子桶，计数时取当前子桶和前五个子桶之和，兼顾精度和存储成本。
令牌桶算法
令牌桶更适合需要允许短时突发的场景。桶的容量决定了最大突发量，往桶里匀速放令牌的速率决定了长期平均速率。比如设置桶容量20、速率每秒10个令牌，那么偶尔的瞬时20次突发能被放过，但持续调用不可能超过每秒10次。CDN边缘函数实现令牌桶时，状态需要存在边缘KV存储中，多个请求并发读写同一把桶时要注意用原子操作，否则计数会不准。
// 边缘令牌桶限流（状态存于边缘KV）
async function rateLimit(clientId) {
const CAPACITY = 20; // 桶容量
const RATE = 10; // 每秒补充令牌数
const now = Date.now() / 1000;
const bucket = await KV.get(clientId, 'json') || {tokens: CAPACITY, last: now};
// 按时间差补充令牌
bucket.tokens = Math.min(CAPACITY, bucket.tokens + (now - bucket.last) * RATE);
bucket.last = now;
if (bucket.tokens < 1) {
return {allowed: false, retryAfter: Math.ceil((1 - bucket.tokens) / RATE)};
}
bucket.tokens -= 1;
await KV.put(clientId, JSON.stringify(bucket));
return {allowed: true};
}限流维度怎么选
按什么维度限流直接决定效果。按单个IP限流最简单，但会被家宽共享IP误伤，同一小区的用户可能共用一个出口IP。按API Key或用户ID限流更精准，但需要在认证之后才能判断身份，这正好和前面的边缘认证串联起来：先验签名，验过了再按Key计数。实践中推荐多级限流叠加——IP维度设一个宽松的兜底阈值（比如每分钟600次），用户维度设业务阈值（比如每分钟60次），接口维度再针对敏感接口单独收紧（登录接口每分钟5次）。被限流的请求应返回429状态码并携带Retry-After响应头，给客户端明确的退避指引。
四、认证与限流的联动架构及踩坑经验
把前面的能力串起来，一个完整的边缘安全处理链路是这样的：请求到达CDN节点后，先经过WAF规则过滤明显的SQL注入和恶意特征，然后执行边缘函数做身份认证（签名或JWT验证），认证通过后提取身份标识，进入限流判断，最后命中缓存规则或回源。这个链路的顺序很重要——先WAF后认证可以避免攻击流量浪费边缘函数的计算配额，先认证后限流可以按真实身份而非IP来计数。
落地时有几个坑值得提前知道。第一，边缘KV是最终一致性存储，限流计数在多个节点间可能短暂不一致，极端情况下同一用户的实际限流阈值会有百分之几的误差。如果你的业务对精度要求极高（比如秒杀场景），可以考虑把关键接口的计数回退到源站的Redis集中处理，边缘只做粗粒度限流。第二，边缘函数的执行时长通常有硬性限制（一般50毫秒以内），所以边缘认证逻辑要尽量轻量，避免在边缘发起额外的网络请求。第三，密钥管理要小心，HMAC密钥和JWT公钥的分发要走专门的配置通道，不要硬编码在函数代码里，轮换密钥时新旧并行一段时间，避免客户端升级不同步导致的认证失败风暴。
最后建议为限流和认证失败都建立监控告警。某个API Key在短时间内认证失败次数激增，往往意味着密钥泄露或撞库攻击；某类接口的429占比突然升高，可能是下游系统出现了循环调用的bug。这些信号比攻击本身更早暴露问题，也是边缘安全体系持续迭代优化的依据。通过CDN边缘做前置防护，配合源站网关的完整鉴权，两层过滤下来，绝大多数恶意流量在触及业务服务器之前就已经被消化掉了。