回源控制的核心不是把带宽卡死，而是用限速削减无效突发、用突发配额保护正常峰值，回源限速怎么设置才不误伤业务，关键要看突发流量来自正常高峰还是异常请求。
回源限速怎么设置才不误伤正常请求
回源限速最容易犯的错，是把“限速”理解成“限制所有请求的速度”，回源限速应该拆成两层：基础限速和突发配额，基础限速控制单连接或单IP占用的回源带宽上限，突发配额用来吸收短时间内的正常峰值，少了后者，业务高峰就会出现大量超时；少了前者,单个异常客户端就能把源站出口拖垮。
Nginx回源限速配置对比：limit_rate还是limit_conn
源站侧如果直接跑Nginx，最常用的两个指令就是limit_rate和limit_conn，它们控制的对象不同,混用效果更好。
按带宽限速：limit_rate
这个指令限制单个连接的回源响应速度,配置片段如下：
location /download/ {
limit_rate_after 2m;
limit_rate 300k;
}
意思是前2MB不限速，超过2MB后单连接最多跑300KB/s，这种配置适合大文件下载、视频回源等场景，小文件在2MB内直接全速返回，不会影响首包时间；大文件被匀速拉取,避免单个下载请求占满回源带宽。
按并发连接限速：limit_conn
这个指令限制同一IP同时建立的回源连接数,配置如下：
limit_conn_zone $binary_remote_addr zone=origin_conn:10m;
server {
location / {
limit_conn origin_conn 8;
}
}
同一IP最多同时保持8条回源连接，API接口、动态内容、防CC场景下，这个指令比带宽限速更直接，一个客户端哪怕每条连接只跑50KB/s,并发拉到几十条也能把源站连接表占满。
两者对比
| 限速方式 | 控制维度 | 适用场景 | 误伤风险 |
|---|---|---|---|
| limit_rate | 单连接带宽 | 文件下载、视频回源 | 低，但对小文件无感 |
| limit_conn | 单IP并发连接数 | API、动态接口、防CC | 中，大文件传输连接数可能被误限 |
| 组合使用 | 带宽+连接数 | 混合业务源站 | 低，但需要测试阈值 |
多数情况下，源站应同时启用两种限制，先限连接数再限带宽，比如单IP最多6条连接，每条连接超过1MB后限速200KB/s，这样既能挡住异常并发,又不会让正常用户下载大文件时被一刀切。
突发处理靠burst不靠硬挡
回源突发流量怎么处理，很多人只想到“限速”，却忽略“突发配额”，Nginx的limit_req模块就提供了burst参数。
limit_req_zone $binary_remote_addr zone=origin_req:10m rate=20r/s;
location /api/ {
limit_req zone=origin_req burst=50 nodelay;
}
rate=20r/s是基准速率，burst=50是允许短时间额外放行的请求数，nodelay表示突发请求立即处理，不排队延迟，这样配置后，单个IP在1秒内最多可以突发50个请求，但长期平均速率仍被限制在20r/s附近。
这个思路同样适用于回源带宽控制，正常业务高峰往往只持续几十秒到几分钟，源站出口如果按平均带宽配置，高峰期就会拥堵，正确做法是把突发值设为平均值的一定倍数，同时限制持续时长，业内专家指出，回源链路瓶颈多数出现在带宽而非连接数，因此突发配额更适合加在带宽维度,而不是无脑加在连接数维度。
CDN回源突发流量处理的两条路线
回源控制不只是在源站配Nginx，国内业务大量使用CDN，回源突发流量更常见于CDN节点到源站这一段，CDN回源突发流量处理可以从两条路线入手：CDN侧控总量,源站侧控单点。
在CDN侧设置回源带宽上限
多数CDN控制台提供“回源限速”或“回源带宽上限”功能，这里的逻辑不是限制某个用户，而是限制所有节点回源的总带宽,避免源站出口被整体打满。
设置时先观察源站正常回源带宽均值，保留一定余量，比如源站连续7天回源带宽均值在80Mbps附近，峰值在130Mbps左右，可以把回源带宽上限先设为100Mbps到110Mbps，再根据业务波动逐步上调，不要一上来设成和峰值相同,那样突发来临时依然会把源站压垮。
按时段设置更精细，晚8点到11点业务高峰可以给更高上限，凌晨低峰期则降低上限,节省回源带宽成本。
在源站侧做连接级保护
CDN侧控总量之后，源站侧还要做单点防护，高防IP回源限速对比中，常见两种思路：按连接数和按带宽。
- 按连接数：适合防CC攻击，能快速识别异常客户端,但正常大文件传输可能被误伤。
- 按带宽：直接限制总回源带宽，能保住源站出口,但无法区分谁在占用。
- 组合策略：入口按连接数挡异常,出口按带宽保成本。
行业共识认为，回源限速要和业务峰值模型匹配，下载站、视频站适合带宽优先；API站、登录接口适合连接数优先，国内服务器回源优化还涉及地域链路质量差异，华北源站给华南节点回源时，晚高峰拥塞概率更高,限速值应低于同地域回源。
回源带宽成本控制从预算倒推配置
回源带宽成本控制不能等账单出来再优化，回源带宽越高，CDN费用和源站带宽费用都会同步上升，控制回源带宽，本质是提高缓存命中率、减少无效回源请求。
从报表找浪费点
实际操作可以按以下步骤进行：
- 在CDN后台导出回源流量报表，按域名、目录、URL统计回源带宽。
- 找出回源Top 10 URL,判断这些资源是否应该被缓存。
- 对可缓存但命中率低的静态资源，检查Cache-Control头,适当拉长TTL。
- 对不可缓存的动态接口,单独配置连接数限速和请求速率限制。
- 对下载类业务设置单连接限速,避免单用户占满回源出口。
- 观察回源带宽曲线，把突发值设定在正常峰值的适当余量范围,而不是按最高点设置。
回源带宽成本控制的核心指标不是“回源带宽上限”，而是回源带宽占用率，近年来的公开数据表明，相当一部分企业CDN回源带宽占总带宽比例超过三成，往往是因为缓存策略失效或热点资源被频繁穿透，先把缓存命中率提上去，再谈限速,成本下降才可持续。
按地域和时段做差异化限速
国内服务器回源优化绕不开地域差异，同样是回源，华北节点到华东源站的链路质量，和西南节点到华东源站的链路质量可能差不少,CDN控制台里一般可以按节点区域匹配不同限速策略。
具体做法：
- 源站在上海，华南、华东节点可以设置较高的单连接回源限速。
- 西南、西北节点可以适当降低回源限速阈值,避免跨地域长链路拥塞。
- 晚高峰时段整体回源带宽上限下调,白天上调。
- 大促期间提前放宽正常峰值对应的突发配额,但收紧异常来源的连接数限制。
回源限速不是一道防火墙，而是一套流量调度
回源限速和突发处理本质上是资源分配问题，把回源链路想象成一条通往仓库的窄路：大货车（大文件下载）要限速但不拦停，小电瓶车（API请求）要限数量但放行快，真正可疑的车（异常IP）要直接挡在门外。
源站侧用Nginx的limit_rate、limit_conn、limit_req完成单点控制；CDN侧用回源带宽上限完成总控；突发配额负责吸收业务高峰；成本控制则从缓存命中率、地域链路、时段差异三个方向同时压降回源需求，配好这套组合,回源链路就不会在用户还没感知到卡顿之前先把自己压垮。
回源限速常见问题Q&A
回源限速设置过低会导致什么后果？
回源限速过低，源站响应变慢，CDN节点等待时间变长，对命中率低的动态资源，用户会直接感知到页面卡顿；对下载类资源，速度可能从MB/s掉到几十KB/s，多数情况下，应先观察源站出带宽曲线，再小幅调整限速值,不建议一次性砍到很低。
回源突发流量怎么处理最稳妥？
回源突发流量要先区分来源，如果是正常业务高峰，应提高突发配额，而不是收紧基础限速，如果是单IP或少量IP造成的异常突发，直接在源站或CDN侧做连接数限制，算法层面，令牌桶允许一定突发，漏桶严格平滑,业务波动大的场景选令牌桶更合适。
国内服务器回源优化有没有通用方法？
国内服务器回源优化可以先从缓存命中率入手，把静态资源尽量留在CDN节点，减少真实回源，再按地域链路质量做分区域限速，华北、华东、华南节点和西南、西北节点分开配置，源站侧用limit_conn限制单IP并发，CDN侧用带宽上限兜底,回源质量通常能稳定在可接受范围。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/643845.html
