CDN 防刷与带宽节省终极指南：302 重定向鉴权全解析
几乎所有网站都想要借助 CDN（内容分发网络） 来提升速度与可扩展性，但 “刷流量”攻击（脚本自动滥用 CDN 资源）却可能让这些优势瞬间变成高额账单。在这种攻击中，恶意方会反复请求托管在 CDN 上的文件（图片、视频等），人为 抬高带宽消耗，从而推高费用。
本文将带你了解如何阻止 CDN 被滥用、并有效节省成本。我们会先讨论一种常见但有一定缺陷的方案——在前端 JavaScript 中嵌入并注入 鉴权密钥（auth key） ；随后，再介绍更加安全的替代做法：服务器端 302 临时重定向 + 鉴权签名。本站目前分地区将国内重定向到阿里云CDN，国外重定向到Cloudflare R2。为什么要用CDN？因为阿里云送了免费的50G流量（:D）。
但是速率限制试了挺久，小了翻几页就影响正常访问，但是大了又起不到限制作用。最后折中了一下，国外都走R2，国内的阿里CDN每小时设置一个对正常访问宽松的量，超出后重定向到R2，超出总体速率限制之后就429。（例如，设置总体速率限制600次，国内CDN重定向每小时200次。每个国内ip每小时200次以内的图片访问都走阿里CDN，剩余的400次走国外的R2，超出600次后就返回429或者返回更小体积的缩略图。）
常见做法：前端嵌入鉴权密钥（上手容易，安全堪忧）
直接把 密钥／鉴权令牌 写进前端代码，用来给对 CDN 的请求“盖章”。典型做法是：
https://cdn.example.com/file.png?authKey=12345
这种方式简单，能挡住随手扒资源的小爬虫；然而，它的问题也同样显而易见：
- 密钥迟早会被扒走
任何送到浏览器的“秘密”，实际上都已公开。攻击者打开开发者工具或抓包，就能把 auth key 揣进兜里。正如安全社区常说的： “只要密钥落到客户端，用户就能看到；浏览器里不存在真正意义的保密。” 无论你如何压缩、混淆、花式加壳，执着的黑客总有办法把它“抠”出来。 - 滥用依旧轻而易举
一旦恶意 bot 拿到密钥，就可以直接“构造” CDN 访问，完全绕过你的站点。CDN 发现“合法”密钥，自然照单全收，带宽账单飞涨。说白了，锁没坏，是你把钥匙递了出去。 - 高频轮换密钥 + 复杂前端逻辑
为了降低风险，很多人不得不频繁轮换密钥或者生成一次性 token。结果可能前端代码天天改，或者客户端得反复拉取新密钥，既加大复杂度，也拖慢性能。更糟糕的是，若每次请求都带独特查询参数，浏览器缓存将形同虚设——可谓“赔了夫人又折兵”。 - Referer 伪造易如反掌
有人寄希望于“防盗链”——只允许带特定 Referer 的请求。然而 Referer 头一行脚本就能伪造。对于熟练写脚本的人来说，这道“门”几乎不存在。 - 真被刷时，费用依旧吓人
前端密钥或许能约束“君子”，却拦不住下定决心的攻击者。有开发者实测：循环下载一张 140 KB 图片一千次，仅用一分钟就耗掉 140 MB；若持续一个月，带宽费用可轻松突破 1000 美元。由此可见，泄露或伪造的密钥足以在短时间内榨干你的流量配额。
因此：把鉴权逻辑放在前端，部署快，却形同 “纸糊的篱笆” 。你得不停地换钥匙、补漏洞，结果仍像打地鼠一样疲于奔命。要想真正守好 CDN 大门，显然需要一种更可靠、无需频繁手动维护的方案。
更佳方案：服务器端 302 重定向 + 鉴权
与其把“万能钥匙”交给浏览器，不如牢牢掌握在服务器手中。思路很简单：让服务器充当守门人——客户端先向你的服务器请求资源，服务器审核通过后，再返回一条 HTTP 302 临时重定向 ，将浏览器引向真实的 CDN 地址，并在 URL 中附带一次性签名或令牌。这样浏览器依旧从 CDN 获取文件，但前提是服务器已点头放行。
具体流程如下：
客户端向你的服务器请求资源
页面上不再直接引用 CDN，而是指向 你自己的服务器（例如https://mysite.com/get-file/123）。该地址本身并不回传文件，而是负责鉴权与重定向。服务器进行检查并生成鉴权信息
请求抵达后台后，所有安全逻辑都在服务器端执行，你拥有完全控制权：- 可校验用户会话、IP、地理位置、请求频率等；
- 若某 IP 触发阈值，可立即拒绝；
- 若来自受限地区或黑名单，也可直接拦截。
一切正常后，服务器使用仅自己知道的密钥，为真正的 CDN 文件生成一次性或短效的签名 URL / 令牌。
服务器返回 302 重定向
服务器并不发送文件，而是返回 “HTTP 302 Found” ，在 Location 头 中给出 CDN 地址，例如
https://cdn.example.com/path/file.png?token=XYZ。
注意：令牌 XYZ 只存在于这条响应头中，前端 JavaScript 永远看不到。浏览器自动跟随重定向前往 CDN
浏览器按照规范自动跟随 302，将携带令牌的请求发往 CDN。CDN（或OSS）验证令牌是否合法且未过期，验证通过后直接回源文件。在用户眼中，图片或视频依旧飞速加载。内容按规输送，访问尽在掌控
数据依然由边缘节点分发，主站压力与 CDN 加速效果均得到保留。但任何试图绕过服务器、直接访问 CDN 的客户端都会因缺少有效令牌而失败。
该方案显著 提升了安全性与弹性：
鉴权密钥始终隐藏
签名密钥与鉴权逻辑从不落到客户端。攻击者看不了源码，也截不到脚本。即便截获某条重定向 URL，其中的 token 可以设为短效或一次性；想继续滥用，就得反复请求你的服务器，而这类异常流量极易监测并封禁。换言之，风险面已从裸露的前端移回受控的后端。服务器侧精细管控
请求先到你的服务器，你可以施行 细粒度规则：按国家／城市放行或封禁，按 IP／用户限流，要求登录或验证码……这些判断都在消耗任何 CDN 带宽之前完成。一旦命中规则，直接不发重定向（或指向轻量级错误页），立即省下可能的海量流量。动态路由，灵活分流
服务器可为不同场景返回不同目的地。例如中国大陆用户指向阿里云 OSS，全球用户指向 Cloudflare R2：
oss-cn-example.aliyuncs.com/... ↔︎cdn.cloudflare.com/...。
还可按内容类型区别对待——缩略图与原图走不同 Bucket，视频走专用 CDN。对于客户端，一切透明；纯前端方案很难达到这种灵活度。前端无需改动
鉴权算法、CDN 供应商、密钥轮换，都可只修改服务器。客户端仍调用静态的mysite.com/get-file/123，无需重发版本，也不会泄露密钥。即使怀疑泄露，只需更新服务器配置，下一次请求立刻生效，维护负担大幅降低。性能开销极小
302 响应极轻量，只多一次往返。文件仍由 CDN 边缘节点分发，带宽与时延几乎无感。浏览器自动跟随 302；因其为临时重定向，通常不会被长期缓存，你可随时收回授权控制（或通过 Cache-Control 自行配置）。SEO 友好
采用 302（临时）重定向 不会转移权重。搜索引擎抓取的网址仍是本站的相对路径，搜索引擎认定资源“位置未永久迁移”，索引保持原 URL，“SEO 权重”仍归你的网站；反之若用 301，权重可能转到 CDN，这正是我们想避免的。所以，用 302 分发静态资源既安全又不损排名；CDN URL 不会被视作“正本”，你的网站依旧是 Google 眼中的权威。（如有需要，可在页面配<link rel="canonical">；就静态文件而言通常无需额外处理。）302 与 307 简要区别： 两者都是临时重定向状态码，因此 Google 等搜索引擎会继续索引原始 URL，并且不会将长期的“链接权重”传递给目标地址，与前文对 302 的说明一致。实际差异在于技术层面：307 是 HTTP 1.1 标准中更“严格”的临时重定向——它保证浏览器在重定向时使用相同的 HTTP 方法和请求体（对 POST、PUT、DELETE 等方法尤为关键），而旧版客户端在收到 302 时有时会把 POST 转成 GET，导致行为不可预测。若只是重定向简单的 GET 资源（如图片、CSS、JS），使用 302 足矣。
为了直观对比两种方案，我们将它们并排示意如下：
左侧 展示的是 前端密钥方案：浏览器加载的页面内含 JavaScript 鉴权密钥，并直接凭该密钥向 CDN 请求文件。内容虽然成功送达，但攻击者可轻易从页面或网络请求中提取密钥，并通过脚本 反复调用 CDN，让带宽费用一路飙升（图中红色虚线箭头所示）。
右侧 则是 服务器端 302 重定向方案：密钥始终藏在服务器。浏览器先向 Web 服务器请求资源，服务器返回 302 临时重定向，URL 中附带一次性 token。浏览器随后携带该 token 访问 CDN 并获取内容。此模式下，服务器可强制执行安全检查（例如拦截 恶意机器人 的批量请求），而客户端代码依旧简洁无变化。
CDN 值得用——关键是要把门看好
因担心被恶意刷流量，就彻底弃用 CDN 吗？完全没必要。 CDN 能显著加速内容分发、减轻源站压力；如果配置得当，缓存命中还能反过来帮你省钱。正确的做法 不是远离 CDN，而是武装它。
通过“服务器端重定向 + 鉴权”这一核心手段，再加上 CDN 自带的限流、WAF 规则等方法，你就能确保 CDN 为你和用户服务，而非被攻击者牟利。恶意刷流量会在第一时间被拦截，大大降低异常带宽费用与服务降速的风险；真正的访问者则依旧享受飞快、稳定的加载体验。
因此，继续用 CDN，但不要敞开大门。把鉴权密钥牢牢握在服务器端，明确访问权限，利用 HTTP 重定向把用户无缝导向合适的节点。这样，你既能安全、低成本地获得 CDN 的性能红利，也能在夜深人静时安心入睡——毕竟，网站与钱包都已远离恶意流量的威胁。