必须使用 $binary_remote_addr 而非 $remote_addr 或 $http_x_forwarded_for，因其长度固定、安全高效；limit_conn 必须置于 server 块顶层才全站生效，且需配合 real_ip 指令处理代理场景。
直接说结论：用 limit_conn_zone 定义基于 $binary_remote_addr 的共享内存区，再在 server 或 location 块中用 limit_conn 引用它——这是唯一可靠方式，$remote_addr 会因代理失效，$http_x_forwarded_for 可被伪造。
为什么必须用 $binary_remote_addr 而不是 $remote_addr
Nginx 的 limit_conn_zone 要求 key 必须是固定长度的二进制字符串，$remote_addr 是点分十进制（如 192.168.1.100），长度不固定，会导致内存分配异常、统计不准甚至 worker 进程崩溃。而 $binary_remote_addr 是 IPv4 固定 4 字节 / IPv6 固定 16 字节的二进制表示，安全且高效。
常见错误现象：nginx: [emerg] invalid number of arguments in "limit_conn_zone" directive 或连接数限制完全不生效，往往就是用了 $remote_addr。
实操建议：
- 永远写成
limit_conn_zone $binary_remote_addr zone=perip:10m;，其中10m表示共享内存区大小，每 1 万 IP 约占 1MB，按实际并发 IP 数预留 - 不要尝试用
$http_x_forwarded_for—— 它可能为空、含多个地址、可被客户端篡改，无法作为限流依据 - 如果后端有可信反向代理（如 Cloudflare），需配合
set_real_ip_from+real_ip_header提前还原真实 IP，再用$binary_remote_addr
limit_conn 放在哪个作用域才真正“全站生效”
“全站范围”不等于写在 http 块顶层——limit_conn 指令**不能**出现在 http 块中，否则 Nginx 启动失败：nginx: [emerg] "limit_conn" directive is not allowed here。
正确做法是放在 server 块最外层（即所有 location 之上），这样所有请求（包括静态资源、API、根路径）都会经过该限制。若只放在某个 location 里，则仅对该路径生效。
实操建议：
- 在
server块开头紧贴listen和server_name之后添加：limit_conn perip 16; - 数值
16是典型值，对普通 Web 站点足够；AJAX 密集型页面可能需要调到 32–64；纯 API 服务建议结合limit_req控制请求数，而非盲目提高连接数 - 注意：该限制是**每个 IP 的 TCP 连接总数**，包括 Keep-Alive 复用连接，不是请求数
如何验证限流是否生效且不误伤正常用户
限流触发时，Nginx 默认返回 503 Service Temporarily Unavailable，但不会记录到 access log（除非显式配置 log_level），容易误判为后端故障。
实操建议：
- 开启连接拒绝日志：
limit_conn_log_level warn;放在http或server块中，然后查 error log 中类似limiting connections by zone "perip"的 warn 条目 - 用
ab或wrk快速验证：ab -n 100 -c 50 http://yoursite/，观察响应中是否出现大量503，同时检查nginx -T | grep limit_conn确认配置已加载 - 避免误伤：如果站点使用 CDN 或公司出口 NAT，大量用户共享一个公网 IP，此时单 IP 限流会集体失效或误封——应改用
limit_req基于 cookie 或 token 限速，或结合业务逻辑做应用层限流
真正麻烦的是混合架构：既有直连用户，又有经多层代理的流量，还穿插着健康检查探针。这时候 $binary_remote_addr 的语义必须和 real_ip_recursive、geo 指令联动校准，否则限流对象就错了。别指望一次配完就一劳永逸，先看 error log 里的拒绝记录，再比对真实访问 IP 分布，才是调试起点。
