关于Nginx limit_conn在HTTP2下的配置疑问及异常排查

1. HTTP2并发请求在Nginx limit_conn中的计数逻辑 #

Nginx官方文档的描述是准确的：在HTTP/2和HTTP/3协议下，每个并发请求流会被limit_conn模块当作独立的"连接"来统计，这和HTTP2本身的TCP连接复用机制不冲突。

简单说，HTTP2是通过一个TCP连接承载多个请求流，但Nginx的limit_conn针对的是这些请求流的并发数，而非底层TCP连接数。所以如果一个页面发起300个并发HTTP2请求，在limit_conn的统计维度里，就会被算作300个"连接"，而非1个TCP连接。

2. 为什么3图页面Chrome显示4个TCP连接却能正常访问？ #

你看到的Chrome显示的"4个连接"是底层TCP连接数，而Nginx的limit_conn perip 3限制的是同一IP的并发请求流数。

Chrome为提升加载效率，会对同一域名建立多个TCP连接（默认上限为6个），每个TCP连接中可同时处理多个HTTP2请求流。当测试3图页面时，Chrome可能把3个图片请求分配到1个TCP连接的3个并发流中，刚好触达limit_conn的3个上限，因此能正常访问；但当页面包含大量图片时，并发请求流数超过3，就会触发Nginx限流，返回503。

3. 如何设置limit_conn的合理值？ #

• 明确limit_conn与limit_req的分工：limit_conn限制的是并发请求数（同一时刻正在处理的请求数量），limit_req限制的是请求速率（单位时间内的请求总数），抵御DDoS需要两者配合使用，不能单靠其一。
• 基于正常用户访问场景调整：正常用户加载页面时，并发请求流数通常在10-20之间（取决于页面资源数量，比如图片、CSS、JS等）。建议先把limit_conn perip设为20-30，再观察Nginx访问日志与错误日志：
  • 若正常用户频繁触发503，适当调高数值；
  • 若仍有DDoS攻击漏过，适当调低，同时配合limit_req收紧速率限制。
• 结合HTTP2特性优化：开启limit_conn_log_level warn记录限流日志，方便排查被限流的请求；也可设置limit_conn_status 429返回更友好的限流状态码，让前端可做重试逻辑。
• 示例参考配置：

  # 定义连接限制的共享内存区域
  limit_conn_zone $binary_remote_addr zone=perip:10m;
  # 定义请求速率限制的共享内存区域，限制每秒10个请求，突发20个请求不延迟
  limit_req_zone $binary_remote_addr zone=perip_req:10m rate=10r/s;
  
  server {
      # ... 其他配置 ...
  
      # 限制每个IP的并发请求流数为20
      limit_conn perip 20;
      # 限制请求速率，突发请求最多缓冲20个，超过直接返回429
      limit_req zone=perip_req burst=20 nodelay;
      limit_conn_log_level warn;
      limit_conn_status 429;
  }
  

内容的提问来源于stack exchange，提问作者qiang shui