先限流止损，再优化回源链路，最后用缓存策略把压力挡在源站之外。
如果你的源站正在被突增的回源流量打满带宽,或者CPU、数据库连接数飙升，那么这篇文章就是给你写的，下面这套处理逻辑，按紧急程度排序，每一步都可直接落地。
判断回源流量异常的三个信号
在处理之前,先确认问题确实出在回源环节上。
- 源站带宽监控出现单点峰值，登录云厂商控制台查看出入带宽曲线，如果出方向带宽持续逼近上限，而正常业务曲线是平滑的，大概率是异常回源。
- CDN命中率骤降，在CDN控制台的监控报表里，如果请求命中率从90%以上掉到70%以下，说明大量请求穿透缓存直接打到了源站。
- 源站访问日志中CDN回源标识集中，多数CDN会在回源请求头中携带Via或X-Cache字段，过滤出这些请求，看是否集中在特定URL或特定时间段。
三个信号同时出现两个,基本可以锁定是回源问题。
第一优先：限流与拦截，先把源站保住
源站一旦被打挂,回源失败率会成倍放大，用户看到的错误比慢更致命。
在CDN侧配置源站限流，大部分商业CDN产品都支持QPS限制或带宽限制，按照源站正常处理能力的80%设置阈值，超出的请求直接返回503，这个操作一分钟就能生效，是止损的第一步。
启用CDN的Range回源，如果源站上多为视频、安装包等大文件，开启Range回源后，CDN会按照分片请求内容而不是整个文件回源，能显著降低源站出口带宽压力，在CDN控制台的“回源配置”里找到Range回源选项，建议将分片大小设为4MB。
紧急情况下可临时开启回源鉴权，在CDN高级配置中增加自定义回源Header，源站Nginx层校验该Header，不匹配的直接拒绝，这能挡住绕过CDN的恶意直连流量，示例配置：
if ($http_x_cdn_auth != "your_token") { return 444; }
注意这条规则要放在server块最前面,且仅作为临时措施。
第二优先：源站侧参数调优，提升单机吞吐
流量已经打到源站了,除了挡，还要让源站本身更扛得住。
调整Nginx的worker进程数与连接超时参数。worker_processes设为CPU核心数，keepalive_timeout适当调低到10-15秒，释放空闲连接占用的内存。worker_connections调到10240以上，避免高并发下连接队列溢出。
开启临时文件与gzip压缩的合理组合，压缩能减小回源传输体积，但高CPU负载下gzip会雪上加霜，多数情况下，建议压缩级别设为3-4，在CPU和带宽之间取平衡点，同时确认open_file_cache已开启，减少重复文件的磁盘I/O。
数据库连接池要调小而不是调大，这是很多运维容易犯的错回源流量上来后第一反应是加大数据库连接数上限，结果数据库直接被连接风暴拖垮，行业共识认为，连接池大小设置为CPU核心数乘以2加1是合理起点，同时设置较短的等待超时时间。
下面这个表给出常见场景下的参数参考值：
| 参数项 | 低配单机（2C4G） | 中配单机（4C8G） | 高配集群（8C16G以上） |
|---|---|---|---|
| worker_processes | 2 | 4 | 8 |
| worker_connections | 4096 | 8192 | 16384 |
| keepalive_timeout | 10s | 15s | 20s |
| gzip_comp_level | 2 | 3 | 4 |
| 数据库连接池上限 | 10 | 15 | 30 |
第三优先：缓存策略重构，减少回源次数
源站响应变慢的根源在于缓存命中率不够,回源请求多，不一定是恶意流量，更多时候是缓存配置不合理。
检查缓存key的粒度，如果你在CDN中配置了包含用户
信息的Cookie或Header作为缓存key的一部分，那么每个用户都会产生独立缓存，相当于缓存完全失效，正确做法是只在需要区分用户时才加入这些维度，静态资源一律使用URL作为唯一缓存标识。
设置短缓存，API接口、页面局部数据这类动态请求，不要一律不缓存，对非敏感数据设置30-60秒的缓存时间，能拦截掉绝大部分重复请求，据统计，多数内容型网站的请求重复率在30%以上，短缓存带来的收益远大于数据延迟带来的影响。
配置回源超时和重试策略，CDN控制台中将回源超时时间设为5-10秒，连接超时5秒，重试次数最多1次，很多源站是因为慢请求堆积导致雪崩，快速失败比死等更有价值，如果你用的是酷番云CDN，可以在“回源配置”中直接设置这些参数，同时在回源HTTP版本中选择HTTP/2.0，多路复用能减少TCP连接数。
第四优先：架构层面的长期缓解方案
措施做完,源站基本能稳定运行，但要根治大流量回源问题，还需要在架构上做调整。
主备双源站切换，在CDN中配置主源和备源，当主源健康检查失败时自动切换，这一步操作在控制台完成，关键是健康检查的路径要选择真实的业务接口，而不是简单的根路径。
源站前置一个轻量级代理层，比如在源站前面加一层OpenResty或Go编写的代理服务，承担请求过滤、 URI黑白名单校验、 简单的响应缓存功能，有了这层保护，即便是大规模恶意回源，真正的业务进程也不会被直接冲击。
观察回源IP分布，识别异常来源，在源站日志中统计回源IP的归属地和运营商，如果发现某个IP段来源异常集中，可以在CDN的访问控制中直接拉黑该IP段，需要注意的是，CDN的回源IP段通常是固定的，可以在CDN服务商官方文档中查询并做白名单限制，只允许这些IP访问源站的80/443端口。
实战复盘：一个典型处理过程
以一个实际场景为例,某资讯类站点某天上午10点开始，源站带宽从正常水平被打满，页面打开需要8秒以上。
处理过程如下：
- 登录CDN控制台,查看监控发现命中率从92%跌至65%，确认是回源流量异常。
- 源站Nginx日志中过滤CDN回源请求,发现集中在某篇热点文章的图片资源上。
- 在CDN控制台对该目录设置缓存30天,强制刷新后5分钟内命中率回升至85%。
- 同时在CDN侧设置源站QPS限制为正常值的1.5倍，防止极端情况再次发生。
- 15分钟后源站带宽恢复平稳,页面打开时间回到2秒以内。
整个过程没有改动业务代码,全部通过CDN配置和Nginx参数调整完成。
大流量回源问题排查QA
Q：CDN回源慢怎么排查具体原因？
在源站上执行curl -I -H "X-Forwarded-Host: yourdomain.com" http://127.0.0.1看返回头中的耗时字段，再用tcpdump -i eth0 port 80 -c 1000抓包分析TCP握手时间，如果源站本机响应快但CDN回源慢，检查回源线路是否跨运营商，尝试在CDN中更换回源线路或开启分片回源。
Q：如何处理源站带宽被某个特定URL大量消耗的情况？
优先在CDN控制台的缓存配置中对该URL前缀设置强制缓存并指定较长有效期,再配合访问控制中的单IP限速功能，将单个IP的下载速度限制在2MB/s以内，如果该URL属于非核心资源，可直接在源站Nginx中返回403或302跳转到其他存储地址，缓存命中后源站流量即会明显下降，带宽压力一般在10-30分钟内消退。
Q：配置了CDN之后源站带宽不降反升是怎么回事？
检查缓存命中率是否正常,多数情况下是因为缓存key包含了未知参数或Cookie导致缓存无法复用，这种情况下源站收到的请求量和未接CDN时没有区别甚至因重试而增加，另一个常见原因是CDN的Range回源未开启，大文件回源时整文件传输加重了源站带宽负担，这两项配置在CDN控制台调整后，源站带宽才会真正降下来。