必须同时配置limit_conn_zone和limit_conn才生效;前者在http块定义共享内存区并计数,后者在server或location中引用该区实施限制,单独使用limit_conn因无状态存储而无效。

直接限制单个 IP 并发连接数,必须同时配置 limit_conn_zone 和 limit_conn,缺一不可;只写 limit_conn 不会报错,但完全不生效。
为什么 limit_conn 单独写在 location 里没用
limit_conn 是执行指令,本身不存状态、不识别 IP、不计数——它只查某个共享内存区(zone)里当前这个 IP 连了多少个。真正做这些事的是 limit_conn_zone,而这个 zone 必须定义在 http{} 块顶层。否则 Nginx 启动时直接报错:unknown limit_conn_zone "xxx"。
-
limit_conn_zone $binary_remote_addr zone=perip:10m;必须放在http{}最外层,不能套在server或location里 -
$binary_remote_addr比$remote_addr更省内存(IPv4 固定 4 字节),推荐始终用前者 - 10m 内存 ≈ 支持 16 万独立 IP 的连接计数;如果业务有几十万真实活跃用户,建议设为
20m或更高
limit_conn perip 5 到底限制什么
它限制的是「已建立、尚未关闭」的 TCP 连接数,不是请求数,也不是每秒请求数。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq(Cortex‑A9/A53 + FPGA)Linux 环境,调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查,支持 PetaLinux 开发。
- HTTP/1.1 keepalive:一个浏览器标签页维持一个长连接,算 1 个
- WebSocket / SSE / 长轮询:只要底层 TCP 连接没断,就算 1 个
- HTTP/2 下容易失效:单个 TCP 连接可复用上百个 stream,
limit_conn perip 5只卡住 5 个连接,但实际并发请求可能翻几十倍 - 超限时默认返回
503 Service Temporarily Unavailable,但日志不记录——需显式加limit_conn_log_level error;和limit_conn_status 429;才能观测和区分
用了 CDN 或反向代理时怎么拿到真实 IP
默认 $binary_remote_addr 拿到的是 CDN 节点或 SLB 的 IP,不是用户真实 IP。
- 必须启用
http_realip_module(Nginx 编译时需带该模块) - 配置
set_real_ip_from指定可信上游网段(如 Cloudflare 的 IP 段) - 设置
real_ip_header X-Forwarded-For; - 然后改用
$realip_remote_addr作为limit_conn_zone的 key,例如:limit_conn_zone $realip_remote_addr zone=perip:10m; - 若未启用 realip 模块,硬用
$http_x_forwarded_for风险很高——头可伪造,且需手动截取第一个非空 IP 并 trim 空格
HTTP/2 和真实用户 NAT 场景下,单纯靠 limit_conn 容易漏防或误伤;最稳妥的做法是配合 limit_req(控速率)+ limit_rate(控单连接带宽)一起用,且所有限流策略都要在 http{} 层级统一规划 zone 大小和 key 选择,不然内存耗尽时 Nginx 会静默丢连接。










