Nginx 连接数限制怎么结合 proxy_pass 保护后端服务-Nginx-PHP中文网

limit_conn必须在proxy_pass前生效，以实现事前拦截；需在http块定义limit_conn_zone，location中用limit_conn按IP限制并发数，超出返回503。

nginx 连接数限制怎么结合 proxy_pass 保护后端服务

连接数限制必须在 proxy_pass 执行前生效，否则请求已经发到后端，限流就失去意义。核心是把 limit_conn 放在 location 块内、proxy_pass 之前，配合合理的键值定义和共享内存区配置。

用 limit_conn 模块控制并发连接数

limit_conn 是 Nginx 内置的连接级限流模块，它不看请求内容，只统计当前活跃 TCP 连接数。适合防止单个客户端（如恶意 IP 或爬虫）建立大量长连接耗尽后端资源。

先在 http 块中定义共享内存区域，例如：
limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;
这里以客户端二进制 IP 为键，分配 10MB 内存存储连接计数状态。
在具体 location 中启用限制：
limit_conn conn_per_ip 20;
表示每个 IP 最多维持 20 个并发连接；超出的新连接会被直接拒绝（返回 503）。
注意：该指令只对当前 location 生效，且必须写在 proxy_pass 上方——Nginx 按顺序执行指令，只有拦在转发前才真正起保护作用。

结合 proxy_pass 的典型配置结构

一个安全、可落地的配置示例：

http {
    # 定义连接限制区（按 IP）
    limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;
    # 定义请求速率区（可选补充）
    limit_req_zone $binary_remote_addr zone=req_per_ip:10m rate=5r/s;
<pre class="brush:php;toolbar:false;">upstream backend_api {
    server 192.168.1.10:8080;
    server 192.168.1.11:8080;
    keepalive 32;
}

server {
    listen 80;
    location /api/ {
        # 连接数限制（关键：必须在 proxy_pass 前）
        limit_conn conn_per_ip 15;
        # 请求速率限制（补充防护）
        limit_req zone=req_per_ip burst=10 nodelay;

        proxy_pass http://backend_api;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
    }
}

}

WebChat Voice Proxy

⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**

下载

这个结构确保所有进入 /api/ 的连接，在抵达后端集群前，已受双重约束：同时最多 15 个连接 + 每秒最多 5 个新请求（突发允许 10 个不排队）。

为什么不能只靠 proxy_pass 自带重试或超时？

proxy_pass 本身不提供连接准入控制。它的重试机制（proxy_next_upstream）只在连接已建立、但后端响应失败时触发，属于“事后补救”；而 limit_conn 是“事前拦截”，从源头减少并发压力。

没有 limit_conn：100 个恶意 IP 各建 50 连接 → 后端瞬间承受 5000 并发，可能触发 OOM 或连接拒绝。
加上 limit_conn conn_per_ip 20：同样 100 个 IP，最多只放行 2000 连接，压力下降 60%。
再搭配 upstream 的 least_conn 和 keepalive，还能让这 2000 连接更均匀、更复用地分发到后端节点。

实际部署要注意的细节

几个容易被忽略但影响效果的关键点：

共享内存大小要够用：10MB 区域能存约 16 万个 IP 的连接状态，如果业务用户量大，建议按 预期独立 IP 数 × 64 字节 估算，避免 zone 溢出导致限流失效。
不要混用不同键值的 zone：比如用 $binary_remote_addr 限连接，又用 $server_name 限请求，两者互不影响，但逻辑容易混乱；建议统一按 IP 或按业务标识（如加 header）做维度隔离。
与后端真实连接模型匹配：如果后端是 WebSocket 或 HTTP/2 长连接服务，limit_conn 比 limit_req 更有效；如果是短连接 API，则两者建议组合使用。