必须同时配置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 Linux Hardware Debug
下载
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 会静默丢连接。
