网站炸了，不是 DDoS，也不是黑客攻击，只是访问量稍微上来了一点，源站就开始频繁超时、丢包、崩溃重启。更离谱的是——你明明接了 CDN，流量却还是打在源站上。到底问题出在哪？答案常常隐藏在「CDN 回源策略」这个容易被忽略但至关重要的配置里。
很多人以为用了 CDN，网站就有了“免疫力”，但实际 CDN 并不是万能盾牌。如果回源配置不合理，它甚至会变成“放大器”：原本只需要处理几个请求的源站，可能会因为回源策略失控，瞬间面对几十倍的压力——这就是我们今天要聊的核心问题。
为什么 CDN 还会把源站打爆？你可能忽略了这些点
CDN 的基本逻辑是缓存、加速、分发。静态资源被缓存后，从边缘节点响应用户请求，从而减轻源站压力、加快加载速度。
但问题是：不是所有请求都能命中缓存。
动态内容？没缓存。
缓存过期？要回源重新拉取。
多个节点同时缓存失效？大家一起“涌向”源站。
这就像一个水库（CDN）管道断了，所有人同时转头去水源（源站）打水——源站不爆才怪。
所以我们不是在讨论「要不要 CDN」，而是「CDN 的回源策略怎么设计」才能真正减轻源站负担，而不是拖垮它。
一、回源请求的真相：它远比你想象的多
你以为 CDN 命中率 95%，源站就只承受 5% 的请求？理论上是这样，但实战不是。
以下是几个常见的「回源放大器」场景：
1.1 缓存雪崩
多个热门资源设置了相同的缓存过期时间，一到点，数百个边缘节点同时回源请求同一个文件，造成瞬时源站请求暴增。
就像整栋楼的水表同时坏了，所有住户一起冲去物业要水，物业（源站）能不疯？
1.2 不合理的缓存配置
如果你给资源配置了 Cache-Control: no-cache，CDN 节点每次请求都要去源站确认是否有变更。
再加上没有设置 ETag 或 Last-Modified，那就不是“确认”，是“重拉”——等于 CDN 每次都绕过自己，去找源站拿新资源。
1.3 查询参数污染缓存命中
不同的查询参数会导致缓存 miss，比如：
bash /api/data?page=1 /api/data?page=2
这些可能是相同逻辑的接口，但 CDN 会认为它们是不同的 URL，分别缓存。
更糟糕的是，如果你没有正确配置 CDN 对 URL 的参数忽略逻辑，每一个分页请求都回源一次，缓存形同虚设。
二、自定义回源策略的核心：控制“什么时候、怎么回”
合理的回源策略并不是禁止回源，而是让回源更聪明、更可控。我们可以从几个关键点入手：
2.1 优化缓存规则，减少不必要的回源
这是第一步，也是大多数人做不到位的地方。
区分资源类型设置缓存时间：静态资源（JS、CSS、图片）可以设置较长的
max-age；接口请求可以配合ETag或Last-Modified进行条件缓存。使用
stale-while-revalidate：在资源过期时，CDN 可以继续提供旧的资源，同时后台去源站拉取新内容。这样就不会造成用户排队等源站的情况。
http Cache-Control: max-age=600, stale-while-revalidate=300
这招简单有效，相当于让 CDN 在“更新内容”的同时还能“不停服务”。
2.2 限制回源并发数，防止同时打爆源站
多个边缘节点回源同一个文件时，我们可以使用「回源合并（Origin Shield）」功能：
由一个中心节点（Shield 节点）先去源站拉取内容；
其他 CDN 节点则从这个中心节点获取，避免同时访问源站。
这种机制有点像“食堂只允许一个人打饭，其他人从他那儿分”，既有序又稳。
2.3 自定义参数匹配规则，提升缓存命中率
很多 API 请求虽然参数不同，但返回的内容其实是一样的。举例：
bash /article?id=123&token=abcdef /article?id=123&token=ghijk
这两次请求本质上返回相同文章内容，但 token 参数导致缓存 miss。
解决方案：
CDN 端配置忽略参数
token；或者统一加上
Vary响应头，让缓存系统知道哪些参数影响响应内容。
这样，你的缓存命中率提升了，源站压力自然降低。
三、应对源站打爆的实战策略
除了优化 CDN 层的策略，源站本身也需要进行一些准备工作，预防“CDN 不灵”时被打穿。
3.1 设置防回源阈值
在源站服务器上增加“回源频率限制”，当短时间内来自 CDN 的请求超过某个阈值时，直接返回 503 或默认缓存数据，避免继续加压。
这种方式类似“压力熔断”，关键时刻保命用。
3.2 使用动态限流机制
对源站的接口添加 Nginx 限流、Lua 限流、或是 Redis 限流控制，尤其对于搜索、查询、批量操作类的接口尤为重要。
nginx limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;
这样做的好处是，即使 CDN 失效，用户流量也不会一窝蜂压向源站。
3.3 多活源站容灾部署
CDN 支持配置多个源站，建议将主源与备源部署在不同机房或云平台，并设置健康检查及回源优先级。
一旦主源异常，可自动切换到备源，不影响用户访问。
四、实际案例拆解：一次源站“被打爆”的救火记录
某客户是一个电商网站，日常峰值 3000 QPS，使用某主流 CDN 平台加速静态资源与动态接口。一次活动开启前 10 分钟，源站 CPU 飙到 100%，网页加载全面崩溃。
调查后发现：
所有 CDN 缓存过期时间设为 10 分钟；
活动开始时，所有请求集中爆发；
所有 CDN 节点同时 miss，全部回源；
未启用 Origin Shield，也未配置限流。
最终紧急启用：
静态资源延长缓存时间为 1 小时；
使用 stale-while-revalidate；
启动 Nginx 限流；
启用 CDN 的回源合并。
流量压力立刻下降 85%，源站恢复正常。
写在最后：CDN 是刀，策略是手，用得好才有用
很多人一提网站加速就说“上 CDN”，就像说做饭就得有刀。但如果你用刀不当，切菜时伤的是自己。
CDN 本身不是终点，它是工具，真正起作用的，是你对回源、缓存、限流等策略的理解和执行。
别让你的 CDN 成为负担，更别让它在关键时刻暴露你的源站漏洞。今天开始，把回源策略做好，网站就能顶住更多真实用户的压力，而不是被流量吓退。
