用限速管住带宽上限，用突发处理消化流量尖峰，两者配合才能让源站既不被打垮，又不浪费闲置资源。
回源流量失控，源头问题比CDN节点更致命
很多站点在接入CDN之后,把注意力全部放在节点命中率、HTTPS配置、缓存规则这些表层参数上，忽略了回源链路本身的管理，直到某天源站带宽被瞬间打满，数据库连接数飙升，监控告警响成一片，才发现回源侧完全是裸奔状态。
回源流量失控的典型场景并不难想象：热点资源突然爆发，CDN节点上没缓存，所有请求在同一秒涌向源站；或者恶意刷量请求绕过缓存直接命中源站；又或者源站本身带宽只有50Mbps，但CDN回源配置里没有做任何限制，运营商线路的突发流量把带宽跑满，此时源站不只是慢，而是直接拒绝服务，连正常用户的小流量请求也进不来。
行业共识认为,回源控制的价值不亚于缓存策略，缓存解决的是“少回源”的问题，限速解决的是“回源时别挤爆”的问题，突发处理解决的是“挤的时候怎么排优先级”的问题，三个环节缺一不可。
CDN回源带宽突然跑满怎么办：先识别流量构成
遇到回源带宽突然跑满,直接去把限速调低是本能反应，但在动手之前，先花几分钟拆解一下流量构成，能省掉后面大量反复调参的时间。
先看回源日志里是什么资源在占用
登录CDN控制台,打开回源日志或实时监控，按URL维度降序排列回源流量，多数情况下，排在最前面的往往集中在少数几个大文件上视频分段、高清图片、软件安装包，这些资源回源特征很明确：单位请求体积大，单请求耗时久，并发上来之后带宽迅速见顶。
还有一种情况是大量小文件集中回源,通常出现在缓存过期时间设置过短，或者目录刷新操作后，导致CDN节点上大量缓存同时失效，引发回源雪崩，回源日志里会表现为请求数极高但单请求体积很小，连接数暴涨但带宽涨得没那么快。
再确认是不是攻击流量
通过UA特征、Referer来源、请求频率三个维度快速判断，正常的用户访问UA分布相对分散，Referer有一定规律；攻击流量往往是同一个或几个UA集中出现，Referer缺失，请求频率均匀且极高，据不完全统计，近年来的回源带宽打满事件中，相当一部分源自低频慢速攻击，这类攻击单看QPS不高，但配合大体积URL，带宽消耗极为可观。
CDN回源限速设置方法：从CDN侧到源站侧的四层限速
限速不能只做一层,只限制CDN回源带宽，源站自身的防护照样可以穿透；只限制源站的单IP连接数，CDN节点众多，每个节点分摊下来效果有限，四层配合才完整。
第一层：CDN控制台的回源限速配置
主流CDN平台都提供回源限速的开关,以百度智能云CDN为例，在回源配置中可以设置单节点回源带宽上限，也可以设置回源QPS上限，这里的数值需要根据源站实际带宽能力换算，不是拍脑袋填的。
操作路径大致是：CDN控制台 → 域名管理 → 回源配置 → 回源限速 → 开启限速 → 填写带宽/GQP值。
第二层：源站Web服务器的限速模块
Nginx层面可以用limit_rate限制单连接响应速度,再用limit_conn限制单IP并发连接数，常见配置如下：
location /download/ {
limit_rate 2m;
limit_conn addr 4;
}
这一段配置限制该目录下每个连接最大传输速度2MB/s，同一IP最多4个并发连接，如果不加区分，所有回源请求都在限速范围内，那么正常的大文件下载也会被拖慢合理做法是只对高消耗资源目录开启，动态接口和API路径不要走这个限制。
第三层：OS层面的TCP调优与连接限制
内核参数中,可以调整net.ipv4.tcp_max_syn_backlog来应对突发SYN请求，调整net.core.somaxconn来扩大监听队列，配合iptables或firewalld限制单个CDN节点IP的并发连接数上限，防止单点异常拖垮全局。
第四层：源站网关或负载均衡的流控
如果源站前面有SLB或自建网关,可以配置令牌桶算法限流，百度云BCC、BLS等产品自带防护能力，可以直接在实例的防护页面里设置带宽阈值和清洗策略，这个层级直接作用在网络入口，响应速度比Web层更快。
突发处理：别让流量尖峰瞬间击穿源站
限速解决了带宽上限问题,但突发流量到来时，即使峰值低于上限，突变的速率也可能让源站的处理线程池瞬间打满，突发处理的关键在于削峰填谷，而不是硬切流量。
排队机制：把瞬时并发变成均匀压力
源站侧引入队列是常见的做法,Nginx的limit_req模块就是典型的漏桶实现，让请求以固定速率被处理，配合burst参数，允许一小部分突发请求排队等待，而不是直接返回503。
limit_req_zone $binary_remote_addr zone=req_limit:10m rate=10r/s;
server {
location /api/ {
limit_req zone=req_limit burst=20 nodelay;
}
}
这样配置后,超过平均速率的请求不会立刻被拒掉，而是先在队列里等待，对于回源请求这种对实时性要求不那么苛刻的流量，排队能有效避免源站被瞬间压垮。
多级缓存兜底：把突发流量挡在回源之前
源站扛不住的要因之一,是CDN节点没有缓存，把动态请求静态化、把缓存时间拉长，是突发处理的前置手段，大量图片站点会把Cache-Control的max-age设置为7天，配合CDN的目录预热，在活动开始前把热点资源提前推到边缘节点，让突发流量在边缘就被消化掉。
弹性扩容：给突发流量一个出口
如果源站部署在云端,启用弹性伸缩组是成本较低的方案，设定CPU使用率或带宽利用率为触发条件，在回源流量上涨时自动扩容一台或几台实例分担压力，据某云厂商公开文档显示，其弹性伸缩最小扩容粒度为分钟级，能覆盖大部分突发的爬坡阶段，但秒级的暴力突发仍然需要另做准备。
回源限速常见的三个踩坑点
如果配置了限速,源站还是出问题，大概率是踩了下面几个坑。
限速数值按带宽算，但源站瓶颈可能在连接数
源站的负载能力不只看带宽,大量小文件回源场景下，连接数先打满，带宽还很空闲，所以限速必须同时覆盖带宽和连接数两个维度，仅限制带宽，连接数失控一样会让Web服务器崩溃。
全局限速误伤动态接口
把所有路径都加上限速,会影响API接口和正常交互请求的响应速度，限速范围务必按目录、按URI前缀做精细控制，静态资源目录可以放狠手限制，动态请求路径必须放行或设定更高阈值。
只限制下行带宽，忽略了上行拥塞
回源场景下的流量方向,是CDN节点向源站发起请求，源站向下返回内容，但源站的响应还要经过运营商链路，链路本身的拥塞情况不在源站控制范围内，合理做法是源站出口带宽预留20%到30%的冗余，而不是把限速值顶满配置。
源站带宽价格与回源成本控制的关系
回源限速不仅是技术问题,也涉及成本，主流的云厂商带宽计费方式有按固定带宽计费和按流量计费两种，按固定带宽计费时，限速值直接决定了月账单的档位；按流量计费时，突发未限速的流量会直接拉高月度账单。
据部分云服务商公开价格页面显示,国内主流云厂商的源站带宽价格在按固定带宽计费时，每Mbps每月大约几十元左右，按流量计费则在每GB几角到一元多之间浮动，两类计费模式下，回源限速都能直接作用于最终费用：
- 按带宽计费：限速值压下来，带宽档位就可以下调，月成本随之降低。
- 按流量计费：突发流量主要是缓存未命中引起的，限速配合缓存命中率提升，回源流量总量大幅缩减。
把回源限速从“防止故障”提升到“控制成本”的层面，强化了这个配置在运维体系中的优先级。
回源流量一路飙高，源站扛不住了怎么排查
给出一个可直接复制的排查路径,按顺序执行，大多数问题能在十几分钟内定位。
- 第一步：打开CDN控制台的回源监控，按时间轴查看回源带宽和回源QPS曲线，确认异常时间段。
- 第二步：对比同时间段源站的监控数据，看CPU、内存、连接数哪个指标最先达到瓶颈。
- 第三步：导出CDN回源日志，按URL排序，列出流量Top20的资源路径。
- 第四步：检查Top20资源的缓存配置，确认Cache-Control和CDN缓存过期时间是否合理。
- 第五步：执行测试请求，观察响应头中的X-Cache和Age字段，判断命中情况。
- 第六步：确认异常后，对高消耗URL目录启用限速，对异常来源IP在源站防火墙封禁。
常见问题
CDN回源限速和源站限速配置哪个优先级更高？
两者并不冲突,优先级也好比较，CDN侧的限速只对回源流量生效，覆盖不到用户直接访问源站的场景；源站侧的限速作为最后一道防线，无论流量来自CDN还是直连，都能兜底，生产环境的做法是先配置源站Web服务器的限速，再配置CDN回源限速，两道防线独立维护，互不依赖。
突发处理中，漏桶和令牌桶应该选哪种？
回源场景下推荐漏桶,漏桶输出速率恒定，能把回源请求均匀铺开，对于源站这种处理能力有固定上限的系统来说，平稳的流量比曲折的流量更好预测，令牌桶允许一定程度的突发，适合API网关等需要快速响应的场景，但本质上是把压力往后传递，回源侧使用风险更高。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/792772.html
