HTTP2的核心优势之一是多路复用，客户端不需要为每个请求单独建立TCP连接，而是可以在一条连接上并发传输多个流。不过连接如果无限期复用下去，会带来内存占用、连接堆积等问题。Nginx从1.11.6版本开始提供了http2_max_requests指令，专门用来控制单个HTTP2连接能够处理的最大请求数量。本文将详细分析这个参数的作用机制、配置方法以及实际调优思路。
一、HTTP2多路复用与连接生命周期的关系
要理解http2_max_requests的意义，首先要明白HTTP2连接的工作方式。在HTTP1.1时代，浏览器通常会同时开多条TCP连接来并行请求资源，连接用完之后通过Keepalive机制保持一段时间，超时或达到keepalive_requests上限后关闭。而HTTP2把请求抽象成了流的概念，多个流共享一条TCP连接，服务端和客户端通过帧的序列化传输来区分不同的请求。
这种模式下，一条连接理论上可以承载海量请求。但对服务端来说，每个连接都会占用一定的内存资源，包括流控窗口状态、HPACK动态表、各种缓冲区等。如果客户端长时间持有连接不放，比如某些长轮询应用、SSE推送场景，这些资源就一直无法释放。极端情况下，大量空闲或半空闲的连接堆积，会挤占Nginx的连接池，影响新连接的接入。
因此Nginx设计了一套连接回收机制：http2_max_requests限制请求数量，http2_idle_timeout限制空闲时间，两者共同决定一条HTTP2连接的寿命。当连接处理的请求数达到上限值时，Nginx会向客户端发送GOAWAY帧，通知对方服务端不再接受新流，已在处理中的流会继续完成，之后连接被优雅关闭。
二、http2_max_requests的配置方法与生效机制
该指令属于http和server级别的配置，可以写在http块、server块或者配置文件包含的单独片段中。基本语法如下：
server {
listen 443 ssl http2;
server_name example.ipipp.com;
# 单个HTTP2连接最多处理1000个请求
http2_max_requests 1000;
# 配合空闲超时一起管理连接寿命
http2_idle_timeout 180s;
ssl_certificate /etc/nginx/ssl/server.crt;
ssl_certificate_key /etc/nginx/ssl/server.key;
}默认值是1000。也就是说，不进行任何配置时，一条HTTP2连接在处理满1000个请求后就会被关闭。客户端收到GOAWAY帧后，如果有新的请求需要发送，会重新建立TCP连接以及TLS握手。需要注意TLS握手是比较昂贵的操作，涉及非对称加密运算，如果这个值设置得太小，客户端会频繁重建连接，反而增加延迟和CPU开销。
生效机制上有一个细节值得注意：达到上限后Nginx并不会立刻中断连接，而是遵循HTTP2协议的优雅关闭流程。GOAWAY帧中会携带最后处理的流ID，客户端看到这个ID就知道之前的请求是否已经完成，未完成的请求会失败，之后的请求则需要走新连接。这个设计保证了关闭过程不会产生半途而废的响应。
验证参数是否生效，可以通过浏览器开发者工具的Network面板观察连接ID变化，或者在Nginx上开启debug日志，搜索http2相关的关闭日志。也可以用curl的HTTP2支持来测试：
# 检查Nginx编译时是否包含http_v2_module nginx -V 2>&1 | grep -o with-http_v2_module # 用curl发起HTTP2请求并查看连接复用情况 curl -I --http2 -v https://example.ipipp.com/ 2>&1 | grep -i "h2\|goaway"
三、高并发场景下的调优建议与常见误区
这个参数没有放之四海而皆准的最优值，需要结合业务形态来判断。对于典型的网页类应用，一个页面加载会触发几十个请求，用户浏览多个页面后请求数累计较快，默认的1000通常够用，一般不需要调整。对于API网关或者内部服务间通信场景，如果客户端是长驻进程（比如gRPC客户端、持续轮询的监控agent），单连接请求数会快速累积，可以适当调大到10000甚至更高，减少连接重建的频率。
调整时需要同时关注几个配套指标。首先是worker_connections，它决定了单个worker进程能打开的最大连接数，如果HTTP2连接因为max_requests设置过大而长期存活，连接池可能被占满。其次是TLS会话复用是否开启，配置了ssl_session_cache和会话票据后，连接重建的成本会显著降低，这时即使max_requests设小一些影响也不大。
一个常见误区是把这个参数当作限流手段。需要明确的是，http2_max_requests控制的是单连接的请求数量，不是全局限流。它不会限制一个客户端总共能发多少请求，客户端完全可以重建连接继续请求。如果目的是限制访问频率，应该使用limit_req模块。另一个误区是忽略了参数在不同版本间的差异，Nginx 1.19.7之后引入了keepalive_time等新指令，部分旧参数的语义发生了调整，升级版本前建议仔细阅读官方变更日志。
对于包含大量SSE或WebSocket升级场景的服务，还要注意HTTP2连接上的流会被长期占用。这类场景下除了调大max_requests，也可以考虑将长连接类业务单独划分server块，配置独立的参数，避免和普通短请求互相干扰。综合来看，合理设置http2_max_requests的核心思路是：在连接重建成本和资源占用之间找到平衡点，并配合空闲超时、连接数上限形成完整的连接生命周期管理策略。
Nginxhttp2_max_requestsHTTP2连接复用修改时间：2026-09-15 06:38:29