DDoS防护中代理缓存与回源并发限制协同的核心，是解决一个矛盾：如何在遭受大规模流量攻击时，既保证合法用户的访问速度，又不让源站服务器被海量请求压垮。答案是通过代理层的缓存机制，将大量重复请求拦截并直接返回，同时通过精细的回源并发限制，为源站建立一道可控的“安全门”，两者协同形成纵深防御体系。
一、 代理缓存：第一道防线与性能加速器
代理服务器（如CDN边缘节点、反向代理）部署在用户和源站之间。当开启缓存功能后，它不仅是流量转发器，更成为了一个临时内容仓库。其工作逻辑是：对于可缓存的静态资源（如图片、CSS、JS文件）甚至部分动态内容，第一个用户请求会由代理转发至源站获取数据，代理在将数据返回给用户的同时，在本地存储一份副本。在缓存有效期内，后续所有用户对同一资源的请求，都将由代理直接响应，无需再回源。
在DDoS攻击场景下，这带来了两大核心价值：首先是“流量吸收”。许多攻击，特别是针对静态资源的CC攻击，会产生大量重复请求。代理缓存能够将这些请求在边缘节点就地消化，攻击流量根本无法到达源站服务器，从而被有效稀释。其次是“性能保障”。即使源站正在承受针对不可缓存路径的攻击，合法用户对已缓存热门内容的访问依然流畅，体验不受影响，这保证了网站在攻击下的基本可用性。
缓存策略的配置是关键。例如，通过Nginx可以精细控制缓存：
proxy_cache_path /data/nginx/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;
server {
location / {
proxy_cache my_cache;
proxy_cache_key "$scheme$request_method$host$request_uri";
proxy_cache_valid 200 302 10m; # 对200/302状态码缓存10分钟
proxy_cache_valid 404 1m; # 对404状态码缓存1分钟
add_header X-Cache-Status $upstream_cache_status; # 在响应头中显示缓存命中状态
proxy_pass http://backend;
}
}通过监控响应头中的 "X-Cache-Status"（值为 HIT、MISS、BYPASS等），我们可以清晰了解缓存命中情况，并据此优化缓存规则，最大化其防护效果。
二、 回源并发限制：源站的最后“守门人”
然而，代理缓存并非万能。对于无法缓存的动态请求（如登录、搜索、API接口）、缓存未命中的请求以及缓存过期后的刷新请求，代理仍需向源站发起请求，即“回源”。如果攻击者集中火力攻击这些不可缓存的路径，海量回源请求同样会击穿源站。此时，回源并发限制就成为了必不可少的“守门人”。
它的原理是，在代理服务器上对指向同一源站的后端连接数进行限制，建立一个“漏斗”。无论前端收到多少请求，代理在同一时刻只允许有限数量的请求与源站建立连接并传输数据，超出的请求必须在代理端排队等待。这确保了源站接收到的请求压力始终在一个预设的可承受阈值之内，从而保障其核心进程不崩溃、数据库连接不被耗尽。
实现上，现代代理软件都提供了成熟模块。以下是一个Nginx限制回源并发连接和请求速率的示例：
upstream backend {
server 192.168.1.100;
# 限制到该后端服务器的总并发连接数
max_conns=50;
}
server {
location /dynamic_api {
proxy_pass http://backend;
# 限制该location每秒向后端发送的请求数（漏桶算法）
limit_req zone=one burst=20 nodelay;
# 限制该location与后端的并发连接数
limit_conn backend_conn 10;
}
}
# 定义限制区域
limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s;
limit_conn_zone $server_name zone=backend_conn:10m;此配置意味着，对于 "/dynamic_api" 路径，代理每秒最多只处理10个回源请求（突发可至20个），并且同时最多只维持10个到后端服务器的活动连接。这就像给源站安装了一个可调节的“减压阀”。
三、 协同作战：1+1>2的纵深防御逻辑
单独使用代理缓存或回源限制都有局限。缓存对动态攻击无效，而粗暴的全局并发限制在高流量攻击下可能误伤所有用户，导致服务不可用。唯有两者协同，才能构建起弹性、智能的防护体系。
它们的协同流程如下：
1. 用户请求到达代理节点；
2. 代理首先检查请求资源是否命中本地缓存，若命中则直接返回，流程结束，此为最优路径；
3. 若未命中缓存，请求进入回源队列；
4. 代理根据预设的并发/速率限制规则，决定是否立即放行该回源请求，或是让其排队、亦或是直接拒绝（返回5xx错误）；
5. 被放行的请求才会实际占用一个回源连接，向源站获取数据。
这种协同产生了层次化效果：第一层（缓存层）过滤了绝大部分重复、静态的垃圾流量。第二层（并发限制层）则以“节流”方式，保护源站免受穿透缓存层的动态请求洪流冲击。即使源站处理能力较弱，只要代理层资源足够，网站就能在洪水般的攻击下保持“低水位运行”——部分动态功能可能变慢或排队，但核心内容可读，网站不彻底瘫痪。
四、 高级策略与独到见解
要实现更精细的协同，不能仅依靠基础配置，需要引入更智能的策略。首先，是差异化缓存与限速。不应将所有内容一视同仁。可以将URL分为三类：纯静态资源（长期缓存）、准静态动态内容（短时间缓存，如商品详情页）、纯动态接口（不缓存）。针对这三类实施不同的“缓存时长+回源限制”组合拳。例如，对纯动态的登录接口，设置极低的回源并发数，并配合验证码等二次验证，从业务层面降低攻击有效性。
其次，是基于缓存的动态限速。这是一个关键见解：回源限制的阈值不应是固定值，而应与缓存命中率动态关联。我们可以编写脚本监控代理层的全局缓存命中率。当命中率正常（如>80%）时，说明攻击压力不大，回源限制可以适当放宽，保证用户体验。当命中率骤降（如<30%）时，很可能正遭遇针对动态接口的CC攻击，此时应自动触发更严格的回源并发限制策略，收紧“漏斗”，优先保障源站生存。
最后，源站保护与失效转移。协同防护的终极目标是保护源站。因此，源站自身也应具备最低限度的自我保护能力，例如应用层防火墙（WAF）的规则识别。同时，必须设计好降级方案。当代理层的回源请求排队过长或失败率过高时，应能自动切换至降级页面，或返回预先缓存的过时但可用的数据（如商品列表），并明确提示用户，这比返回一个504超时错误体验要好得多。
五、 实践配置与效果评估
一个综合性的配置思路需要涵盖以下要点：在代理服务器（以Nginx为例）上，使用 "map" 指令或 "if" 结合正则表达式，根据请求URI、方法、参数等将流量分类。对静态类，设置长缓存时间和宽松限制；对动态类，设置短缓存或无缓存，并配置严格的 "limit_req" 和 "limit_conn"。同时，开启详细日志，记录 "$upstream_cache_status"、"$upstream_response_time" 和 "$upstream_connect_time" 等关键变量。
效果评估应关注三个核心指标：
1. 源站负载：通过监控源站服务器的CPU、内存、网络连接数，最直观地看到压力是否被有效隔离。成功时，攻击期间这些指标曲线应保持平稳；
2. 缓存命中率：攻击期间命中率可能下降，但通过分析未命中的请求模式，可以优化缓存规则，例如将一些攻击频繁的、结果不变的动态URL临时静态化；
3. 业务可用性：最终以合法用户的体验为准。通过监控关键业务接口的成功率与响应时间，确保防护策略没有对正常业务造成严重影响。
总之，代理缓存与回源并发限制的协同，本质上是“疏堵结合”的兵法在DDoS防护中的应用。缓存是“疏”，将洪水引向蓄水池；并发限制是“堵”，在关键隘口设立闸门。通过精细化的配置与动态策略调整，两者能够共同构筑起一道从边缘到核心的、有弹性的防线，让网站在极端流量压力下，依然能够保持韧性与关键服务的可用性。这不仅是技术配置，更是一种资源分配与优先级保障的架构艺术。
