HTTP/2 Rapid Reset 攻击是怎么回事：原理、影响与 SiteGround 的一小时响应

2023 年 10 月 10 日，Google、Amazon 和 Cloudflare 同时发布公告，披露了一个影响面极广的新型漏洞——HTTP/2 Rapid Reset 攻击（业界编号 CVE-2023-44487）。Nginx 官方也在同期发了说明。因为它打在协议层，几乎所有支持 HTTP/2 的服务器软件都受影响，这在当时是近年最大范围的 Web 基础设施安全事件之一。

SiteGround 是较早完成处置的主机商之一：漏洞披露后一小时内给全部 Web 服务器打了补丁，一天之后所有主机服务器和 CDN 节点都跑在加固过的 Nginx 代码上，客户站点不需要做任何操作。

攻击原理：把多路复用变成武器

先说 HTTP/2 解决的是什么问题。HTTP/1.1 时代，浏览器要加载一个页面得排队发几十个请求，CSS、JS、图片一个个来，并发数受限。HTTP/2 引入多路复用（multiplexing）：一条 TCP 连接上可以同时跑很多个"流"（stream），客户端一次就能请求多个资源，页面加载明显变快。

Rapid Reset 攻击利用的正是这个机制：

1. 客户端在一个连接上打开大量请求流；
2. 每个流刚发出就立刻用 RST_STREAM 帧取消掉；
3. 以极高频率重复这个过程。

服务器这边发生的事：收到请求后开始分配资源、把任务派给后端处理，紧接着收到取消信号，又要回收资源、中断后端任务。请求和取消的循环成本全压在服务器上，而攻击方付出的代价极低——因为它不需要等响应，也不占用完整连接的带宽。

结果就是典型的拒绝服务：服务器变慢，严重的直接崩掉。而且受拖累的不只是 Web 服务器本身，整条请求处理链路上的后端都会中招——PHP 进程、应用服务器、静态文件分发,都在做无用功。

SiteGround 当时的比喻很形象：想象一个呼叫中心，有人不停拨号，接线员一接起来对方就挂断。接线员的时间全浪费在假呼叫上，真正的客户打不进来。整个呼叫中心陷入停摆，而攻击者只需要一部电话。

为什么传统防护不好使

很多站长第一反应是"我有 CDN，有防火墙，应该没事"。这类防护的常规逻辑是限制单位时间的请求数（rate limiting），或者识别异常 IP 拉黑。但 Rapid Reset 有几个特点让传统手段打折扣：

• 请求本身看起来是合法的。HTTP/2 规范允许客户端取消流，这是协议内的正常行为，不是畸形包，特征检测很难判定为攻击。
• 单个 IP 的请求量可以不高。攻击可以由大量分布式节点发起，每个来源都不触发限流阈值，但汇总起来压垮服务器。
• 打的是协议实现层，不是应用层。WAF 规则拦不住，必须靠 Web 服务器软件本身的修复（比如限制并发流数量、优化取消处理逻辑）。

所以这类漏洞的正确处置层级是服务器软件和主机基础设施，不是站长在自己的 WordPress 后台装个安全插件能解决的。这也是托管型主机的价值所在：平台层打一次补丁，覆盖全部客户站点；自建 VPS 的用户则得自己盯 Nginx/Apache 的安全公告并及时升级。

SiteGround 的响应时间线

按官方公布的信息还原：

• 2023 年 10 月 10 日：Google、Amazon、Cloudflare 同步披露漏洞，Nginx 发布说明文章。
• 披露后 1 小时内：SiteGround 安全工程团队完成全部 Web 服务器的补丁部署。
• 披露后 1 天：所有 SiteGround 服务器（主机服务器与 CDN 节点）都已运行加固后的 Nginx 代码，平台上的网站全部处于保护状态。
• 客户侧操作：无。不需要更新、不需要改配置、不需要切换服务。

一小时这个响应速度不是靠临时加班堆出来的，它依赖三个前提：自建的安全团队 24 小时盯漏洞披露、工程师随时可以上线操作、服务器环境完全由平台自己运维（不用协调第三方机房或等客户自己动）。同一套机制在其他事件里也验证过——48 小时内零宕机修补 5 个 Linux 内核漏洞、不到 1 小时把平台上所有受影响站点的 UpdraftPlus 升级完、PHP 官方发布前就完成全网加固。

站长自己该做什么

即使主机层面已经被保护，协议层攻击这件事也提醒了几个通用的自保动作：

知道你的服务器软件版本。 如果是自建 VPS 或用某些"半托管"方案，Nginx/Apache 的版本由你负责。订阅官方安全公告，出现协议层漏洞时第一时间升级。

检查资源上限配置。 Nginx 的 http2_max_concurrent_streams、连接超时、worker 进程数这些参数决定了服务器在异常流量下的承受能力。默认值不一定适合你的流量模型。

留好监控和告警。 CPU、内存、PHP 进程数、5xx 比例的突增往往是攻击的第一个信号。等到网站打不开才发现，损失已经产生了。

备份要独立于主机。 攻击导致的宕机一般不损坏数据，但如果同时叠加了别的问题，恢复速度取决于你最近一次备份在哪。SiteGround 的自动备份和手动备份还原流程，可以看备份与还原指南。

别把安全全押在一个插件上。 WordPress 安全插件解决的是应用层问题（暴力破解、恶意文件、XSS），协议层和服务器层的事它管不了。分层防护才是对的思路，具体的漏洞类型和防护清单可以看网站安全漏洞完全指南。

这件事的长期启示

Rapid Reset 之后，HTTP/2 和 HTTP/3 的实现里普遍加强了对并发流数量、流生命周期和取消频率的限制。协议层的攻防是个持续过程——协议设计时追求的性能特性，往往就是后来攻击者的入口。

对普通站长的实际结论很朴素：选一个会在服务器层主动处置漏洞的主机商，比自己熬夜盯安全公告有效得多。你在 Site Tools 里看到的每一个功能，背后都是一整套你看不见的运维在支撑。

常见问题

HTTP/2 Rapid Reset 会窃取网站数据吗？

不会。它是拒绝服务攻击，目标是让网站不可用，不涉及数据泄露或注入。危害是可用性和业务中断，不是机密性。

我的网站在 SiteGround 上，需要做什么？

不需要任何操作。平台在漏洞披露后一小时内完成了全部服务器的补丁部署，主机与 CDN 节点均已加固。

关掉 HTTP/2 是不是更安全？

不是。退回 HTTP/1.1 会明显拖慢页面加载速度，对 SEO 和用户体验都是负分。正确做法是保持协议开启并让服务器软件处在已修复的版本上。

怎么判断我的站点当时有没有受影响？

如果那段时间没有观察到异常的 5xx 或响应变慢，说明没有受到实质影响。托管在已加固平台上的站点，攻击流量在服务器层就被消化掉了。

类似事件以后还会发生吗？

会。协议和软件的漏洞是持续出现的，无法根绝。区别在于响应速度——是几小时内处置完，还是拖到几周后被大规模利用。评估主机商时，看它过往的漏洞响应记录比看宣传页有用。想了解 SiteGround 整体的安全能力，可以看安全功能详解。