关于HTTP Rapid，最值得先弄清楚的是配置边界和排错顺序。2023 年 10 月，一个编号为 CVE-2023-44487 的漏洞登上了各大安全头条——HTTP/2 Rapid Reset。Google、AWS、Cloudflare 等巨头纷纷发出警告，称该漏洞已被用于发动史上最大规模的 DDoS 攻击，峰值流量达到每秒 3.98 亿次请求。
如果你是刚入行的站长、运维新人，或者只是管理一个小网站，看到这种新闻可能一头雾水：HTTP/2 是什么？Rapid Reset 是什么？我的服务器会中招吗？怎么防护？
这篇文章不讲晦涩的协议细节，全程用大白话拆解，并告诉你如何通过 WAF（Web 应用防火墙）规则，快速把这个漏洞挡在门外。
HTTP Rapid：一、先搞懂 HTTP/2 的“多路复用”
容易忽略的细节
在解释攻击之前，得先知道 HTTP/2 做了什么。以前的 HTTP/1.1 时代，浏览器和服务器之间建立一次 TCP 连接，只能发送一个请求，等响应回来才能发下一个。为了加速，浏览器会同时开多个连接（比如 6 个）。
HTTP/2 引入了一个叫“多路复用”的机制：一次 TCP 连接里可以同时发送多个请求，而且这些请求之间互不干扰。每个请求被封装成一个“流”（stream），服务器并行处理。
举个例子：以前你点开一个网页，要加载 HTML、CSS、图片，需要排队一个个来；HTTP/2 就像开了多条传送带，所有资源同时传送，速度自然快很多。
补充参考：此处可内链到“HTTP Rapid故障排查实例”。
HTTP Rapid：二、Rapid Reset 攻击的“巧妙”之处
容易忽略的细节
攻击者利用的就是 HTTP/2 的这个“流”机制。正常使用中，如果客户端发了一个请求，但后来发现不需要了（比如用户取消操作），客户端可以发送一个 RST_STREAM 帧，告诉服务器“这个流我不用了，你释放资源吧”。
Rapid Reset 攻击的思路很简单：攻击者瞬间创建大量请求流，紧接着马上发送 RST_STREAM 重置流，然后立刻再创建一批新流。这样反复循环，每秒可以产生上千万个流。关键问题在于：服务器收到请求后，需要分配内存、CPU 来解析和路由，即使收到 RST_STREAM 后释放资源，这个过程本身也消耗性能。当重置的速度极快，服务器就会陷入“不断创建流→重置→再创建”的泥潭，最终耗尽资源，无法处理正常用户请求——这就是 DDoS。
这个漏洞为什么“高危”？
- 利用门槛极低：攻击者不需要大带宽，普通 VPS 就能发起。
- 传统 DDoS 清洗设备很难识别：流量看起来是正常的 HTTP/2 连接，只是重置速度异常快。
- 影响面广：几乎所有支持 HTTP/2 的软件（Nginx、Apache、Tomcat、HAProxy 等）在 2023 年 10 月之前都受影响。
想继续深入：此处可内链到“HTTP Rapid优化清单”文章。
相关阅读：此处可内链到“HTTP Rapid常见问题”专题。
三、WAF 如何拦截这种攻击？
配置前的检查
WAF（Web 应用防火墙）位于用户和服务器之间，可以检查每个 HTTP 请求的特征。针对 Rapid Reset 攻击，WAF 主要通过以下方式防护：
- 限制单个连接内的流创建速率： 如果同一个 TCP 连接在短时间内创建了大量流（例如每秒超过 100 个），直接断开或限速。
- 检测异常的流重置行为： 记录客户端发送 RST_STREAM 的频率，如果重置率过高，判定为攻击。
- 启用 HTTP/2 连接复用限制： 强制要求客户端必须等上一个请求响应后才能发新请求（降级为类似 HTTP/1.1 的行为），但这会牺牲性能。
市面上主流的 WAF 产品（如 Cloudflare、AWS WAF、Goedge WAF、ModSecurity 等）都已发布对应的规则。下面以常见的 Nginx + ModSecurity 和 Goedge WAF 为例，演示手动配置。
四、配置 WAF 规则（实操演示）
4.1 使用 ModSecurity + OWASP CRS
ModSecurity 是开源的 WAF 引擎，搭配 OWASP Core Rule Set（CRS）可以使用现成规则。从 CRS 3.3.5 版本开始，已包含对 CVE-2023-44487 的检测。
- 更新 CRS 到最新版本：
git pull或下载压缩包。 - 启用规则
920600（HTTP/2 Rapid Reset 检测）：SecRule REQUEST_HEADERS:Protocol "@eq http/2" "id:920600,phase:1,block,msg:'HTTP/2 Rapid Reset Detected'" - 重启 Nginx 使配置生效。
注意：该规则默认基于流创建速率和重置速率，阈值可以在 ModSecurity 的配置文件中调整。
4.2 使用 Goedge WAF（国产 WAF）
Goedge 是一款支持 HTTP/2 的全栈 WAF，可通过 Web 界面快速配置：
- 登录 Goedge 控制台，进入“WAF 策略” → “基础防护”。
- 找到“HTTP/2 流限制”选项，勾选“开启”。
- 设置“单连接最大流数”为 100，“流重置率阈值”为 50%。
- 选择“拦截”动作，保存并应用到网站。
Goedge 会自动分析每个 TCP 连接内的流行为，超过阈值后直接断开连接，不对后端服务器产生任何消耗。
4.3 如果使用 CDN 厂商的 WAF
大多数 CDN/WAF 服务商（Cloudflare、阿里云、腾讯云、又拍云等）已在 2023 年 10 月更新了规则，你只需要到“WAF 设置”中开启“HTTP/2 Rapid Reset 防护”开关即可。一般默认是开启的，建议检查确认。
五、验证防护是否生效
容易忽略的细节
配置完成后，建议用几种方式验证：
- 查看日志： 观察 WAF 日志中是否有“HTTP/2 Rapid Reset”拦截记录。
- 压力测试（谨慎）： 可以使用 h2load 工具模拟大量 HTTP/2 请求，但注意要在非生产环境或经过授权的情况下进行。
- 检查服务器负载： 在没有真实攻击时，如果配置无误，服务器 CPU 和内存不会有异常升高。
六、如果 WAF 防护后仍出现误报怎么办？
容易忽略的细节
有些正常应用（如长轮询、WebSocket）也会大量新建流，可能导致误拦。解决方法：
- 调整阈值：适当提高“单连接最大流数”和“重置率阈值”，如从 50% 调到 70%。
- 添加白名单：对可信 IP（如公司出口、CDN 节点 IP）放行。
- 使用更精细的规则：只对异常模式（例如重置率极高且无实际数据传输）触发拦截。
七、总结
验证与回滚
HTTP/2 Rapid Reset 漏洞本质上是利用了协议设计本身的高效特性来做坏事。好消息是，只要正确配置 WAF 规则，绝大多数攻击都可以被挡在门外。对于小网站，直接用 CDN 厂商的 WAF 或者开源 ModSecurity 是最省心的方案；对于自建 WAF，手动限制流速率和重置率是关键。
最后提醒一句：打补丁不能光靠 WAF，服务端软件（Nginx、Apache、HAProxy 等）也要及时升级到修复版本（如 Nginx 1.25.3、Apache HTTP Server 2.4.58 等），双重保险更安全。
如果你看完还是不确定自己的网站是否安全，可以先用安全头检测工具检查 HTTP/2 支持情况，再对照本文配置 WAF 规则。别慌，漏洞虽猛，防御有方。真正做好HTTP Rapid，靠的不是参数堆砌，而是持续验证。
延伸阅读