limit_conn仅限客户端与Nginx的并发连接数，不能直接限制后端连接；需配合upstream的max_conns、keepalive及limit_req等实现三层协同防护。
用 limit_conn 限制到后端的并发连接数，核心思路是：它本身不能直接限制“发往后端的连接”，而是通过限制客户端与 Nginx 的连接数，间接控制后端压力。真正限制后端连接需配合 upstream 中的 max_conns 和连接复用机制。
理解 limit_conn 的作用边界
limit_conn 是 Nginx 的连接限流模块，工作在 客户端到 Nginx 的接入层，基于 shared memory zone 统计每个 key（如 $binary_remote_addr）当前建立的连接数。它不感知 upstream、不干预 proxy_pass 后的 TCP 连接行为。
也就是说：
– 它能防止大量客户端把 Nginx 自身打满（如 SYN flood、连接耗尽）；
– 但它不能保证每个请求都只产生一个后端连接，也不能阻止一个客户端复用连接发多个请求压垮后端。
真正限制后端并发连接的组合方案
要防止单点后端过载，需三层协同：
- 接入层限流（limit_conn）：防止海量客户端挤占 Nginx 资源，保障自身稳定。例如限制单 IP 最多 10 个并发连接：
server {
limit_conn addr 10;
location /api/ {
proxy_pass http://backend;
}
}
- 上游服务限连（max_conns）：在 upstream 块中为每个后端 server 设置最大并发连接数，超出则进入队列或返回 503：
server 10.0.1.10:8080 max_conns=50;
server 10.0.1.11:8080 max_conns=50;
queue 100 timeout=5s;
}
- 启用连接复用（keepalive）并合理配置：避免每请求建新连接，减少后端连接开销。注意 keepalive 数量要 ≤ max_conns，否则可能绕过限制：
keepalive 32;
server 10.0.1.10:8080 max_conns=50;
}
location /api/ {
proxy_http_version 1.1;
proxy_set_header Connection '';
proxy_pass http://backend;
}
关键细节与避坑提示
-
max_conns从 Nginx 1.5.9 开始支持，确保版本 ≥ 1.5.9； -
limit_conn的 key 若用 $server_name 或 $uri，需确认是否符合业务隔离粒度（比如按接口限流可用 $uri）； - 开启
keepalive后，Nginx 会复用空闲连接，此时max_conns限制的是“Nginx 到该后端的活跃连接总数”，不是每秒请求数； - 若后端是 HTTP/2 或 gRPC，还需关注 stream 并发限制，
max_conns仍有效，但实际承载能力更高； - 监控建议：用
stub_status或 Prometheus nginx-exporter 观察Active connections和 upstream 的active连接数，验证限流生效。
补充：更精细的后端保护可叠加其他手段
仅靠连接数限制还不够稳健，建议搭配：
-
limit_req：限制单位时间请求数（QPS），防突发流量； -
proxy_next_upstream+ 超时重试策略：自动摘除暂时不可用的后端节点； - 后端自身做熔断（如 Sentinel、Resilience4j），形成双向保护；
- 接入 API 网关层统一限流（如 Kong、APISIX），比 Nginx 更易管理策略。
