回源并发过高导致源站拒绝服务，核心解法是“削峰填谷、分层防护”：优先在CDN层开启回源限流和缓存扩容，同时在源站侧做好并发连接数限制、超时断开和容量冗余，双管齐下才能避免源站被瞬间击穿。
回源并发过高的典型触发场景
源站拒绝服务通常不是突然发生的,而是以下几种情况叠加后的结果。
- 热点资源集中请求：某个文件（如图片、视频、API接口）突然被大量用户访问，CDN节点缓存未命中，所有请求直接打到源站，比如电商大促时的商品详情页,或新闻客户端的突发新闻图片。
- 缓存命中率骤降：源站更新了文件却未刷新CDN缓存，导致旧缓存失效、新缓存未建立，瞬间产生大量回源请求,这种情况在静态资源频繁变更的站点上尤为常见。
- 恶意或低频爬虫：搜索引擎爬虫、数据采集脚本在短时间内发起大量并发连接，且不遵守robots协议,直接绕过CDN访问源站IP。
- 源站容量规划不足：平时业务量小，服务器连接数限制、带宽上限设置较低,一旦流量小幅增长便触及瓶颈。
行业共识认为，回源并发过高的本质是请求到达速率超过了源站的处理能力，而并非单纯的总流量大，解决思路要围绕“降低到达速率”和“提升处理能力”两条线展开。
第一优先级：在CDN层配置回源限流
大多数情况下，源站拒绝服务是因为CDN回源策略过于“激进”,修改CDN的配置是见效最快的操作。
设置回源QPS阈值
登录CDN控制台，找到“回源配置”或“高级回源”选项，主流CDN服务商（如简米云CDN、酷番云CDN、百度智能云CDN）都提供回源QPS限流功能,建议按以下步骤操作：
- 先观察一周内正常业务峰值回源QPS,记录平均值和峰值。
- 将回源QPS阈值设置为峰值的1.5倍,留出缓冲空间。
- 开启“超限后自动排队”或“丢弃请求”策略，丢弃时建议返回503状态码,避免引发客户端重试风暴。
开启源站健康检查与自动熔断
CDN节点应持续探测源站健康状态，当源站响应超时比例超过一定值（如20%），CDN应自动进入降级模式：不再回源，直接返回已缓存的过期内容（需配置“ stale-if-error”），或者返回404/503。
具体操作路径：CDN控制台 → 回源设置 → 源站健康检查 → 开启“自动熔断”，熔断恢复时间建议设置60秒,防止源站刚恢复又被冲垮。
第二优先级：优化源站自身的并发承受能力
即使CDN限流生效，源站仍可能因为瞬时流量冲击而拒绝服务,源站侧的调整同样关键。
调整Web服务器并发连接数
以Nginx为例，默认的worker_connections为1024，很多应用场景下这个数值不够，但盲目调大也会导致内存耗尽,推荐的调整方案：
worker_processes设为CPU核心数。worker_connections设为10240或更高（需根据内存计算，每个连接约占用2.5KB内存）。keepalive_timeout从默认的75秒缩短为15秒,减少空闲连接占用。- 开启
limit_req_zone模块，对同一IP的请求速率做限制,例如每秒不超过20个请求。
设置应用层超时与排队机制
如果源站是Java（Tomcat）或Python（Gunicorn）应用,务必配置连接超时和请求超时：
- Tomcat：
maxThreads="400" acceptorThreadCount="4" connectionTimeout="20000"。 - 同时配置
maxQueueSize,避免无限排队导致线程堆积。 - 应用内增加信号量隔离（如Semaphore），控制同时处理请求的线程数，超过则快速返回“系统繁忙”。
启用源站防护软件
在源站部署防火墙软件（如Fail2ban、Cloudflare WAF），针对单IP的并发连接数、请求速率进行实时封禁,例如Fail2ban配置：
[nginx-limit-req]
enabled = true
filter = nginx-limit-req
action = iptables-multiport[name=nginx, port="80,443"]
logpath = /var/log/nginx/error.log
maxretry = 3
findtime = 10
bantime = 600配置可在10秒内同一IP触发3次限流后自动封禁10分钟。
第三优先级：降低回源请求的总量
限流只是“堵”，更聪明的是“疏”，从源头上减少回源次数,才是治本之策。
提升CDN缓存命中率的实操方法
- 设置合理的缓存过期时间：对于静态资源（图片、CSS、JS），建议缓存时间为7-30天，部分CDN支持按文件后缀或目录设置规则，例如
/static/缓存30天。 - 开启忽略查询参数：如果URL带随机参数（如
?v=123不变，CDN默认会视为不同文件，在CDN控制台中开启“忽略参数”功能,可大幅提升命中率。 - 主动预热：在大型活动开始前，将热门资源URL清单提交给CDN控制台的“刷新预热”功能,让内容提前分布到边缘节点。
使用分级缓存架构
在源站与CDN之间再加一层中间层缓存（如Varnish或Apache Traffic Server），形成“边缘节点→中间层→源站”的三级结构，中间层可吸收部分回源流量，且能实现请求合并（将同一文件的多个并发请求合并为一个）。
如果业务量较大，也可考虑将源站迁移到对象存储（如OSS/S3），配合CDN直接回源到存储桶，存储桶本身具备极高的并发吞吐能力,可从根本上规避Web服务器连接数瓶颈。
第四优先级：源站扩容与架构升级
如果以上方法都已实施，回源并发仍然很高，说明业务规模确实增长较快,需要从容量上解决问题。
横向扩展源站集群
将单台源站扩展为多台，通过负载均衡（SLB或Nginx + Keepalived）分发回源请求，注意回源请求来自CDN的多个节点IP，负载均衡需工作在网络层（四层）,避免会话保持导致流量不均。
扩展后建议手动测试：在CDN控制台将回源地址从单个IP改为域名（该域名解析到负载均衡的VIP）,并开启健康检查。
采用Serverless或弹性容器服务
如果业务允许，可将源站迁移到Serverless架构（如函数计算），利用其自动伸缩能力应对突发回源，但要注意冷启动问题，建议预留并发实例数,或开启预置并发。
日常预防与监控：避免下次再“爆”
拒绝服务事件发生后，复盘必不可少,同时要建立长期监控体系。
关键监控指标与告警阈值
| 指标 | 建议告警阈值 | 说明 |
|---|---|---|
| 回源QPS | 正常峰值的80% | 超过即预警 |
| 源站响应耗时 | 平均响应时间 > 1秒 | 出现缓慢迹象 |
| 源站TCP连接数 | 连接数超过最大连接数的70% | 接近瓶颈 |
| CDN缓存命中率 | 命中率低于90% | 需检查缓存配置 |
配置告警后,在CDN控制台或云监控中设置手机短信通知。
定期进行回源压测
每月选择低峰期，使用压测工具（如wrk、JMeter）模拟回源请求，验证源站和限流配置是否有效，压测时先从低并发逐渐提升，直到源站返回错误，记录当时的QPS值,作为容量基准。
Q&A：关于回源并发过高的常见疑问
问：回源并发过高源站拒绝服务，能完全靠CDN限流解决吗？
不能，CDN限流只能减少到达源站的请求数量，但如果源站本身处理能力太弱（如单核CPU、512MB内存），即使限流后QPS较低，依然可能被压垮，必须配合源站自身优化（调整连接数、增加缓存、升级配置）。
问：源站被大量恶意IP直接攻击，绕过了CDN怎么办？
第一步，检查源站IP是否被泄露（如DNS解析记录直接指向源站IP、子域名未接入CDN），第二步，在源站安全组或防火墙中，仅允许CDN节点的IP段访问80/443端口，其他IP一律拒绝，各云厂商会公布CDN回源IP段,可在其官网文档中查询并配置白名单。
问：临时紧急恢复时，是加大缓存时间还是关闭回源？
如果源站已处于拒绝服务状态，最快速的临时恢复方式是：在CDN控制台将缓存时间临时调整为24小时，并开启“离线模式”（即源站不可用时，继续提供已缓存的内容），待源站恢复后，再逐步缩短缓存时间并刷新预热,避免流量立即回源。