limit_conn必须在proxy_pass前生效，以实现事前拦截；需在http块定义limit_conn_zone，location中用limit_conn按IP限制并发数，超出返回503。
连接数限制必须在 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，则两者建议组合使用。
