limit_conn不生效需从客户端行为、nginx配置加载、系统资源限制、上游协同四层面交叉验证：检查作用域是否在location/server内，确认zone在http块正确定义且内存充足，用nginx -t核实配置生效位置，验证请求uri是否命中目标location，排查长连接与压测工具陷阱（如ab默认短连接），并观察是否返回503而非429或502。
连接数限制配置不生效，往往不是某一行写错了，而是整条资源链路中某个环节“没接上”。重点看 limit_conn 是否真正起作用，得从客户端行为、Nginx 配置加载、系统资源限制、上游协同四个层面交叉验证。
确认 limit_conn 指令是否被正确加载
很多情况下配置写了，但根本没进生效上下文：
- 检查指令所在作用域：limit_conn 必须放在
location或server块内，不能只写在http块里（那是定义 zone 的地方） - 确认 zone 已正确定义：比如
limit_conn_zone $binary_remote_addr zone=addr:10m;必须在http块顶层，且内存大小（如10m）足够存下预期的 key 数量 - 用
nginx -T（大写 T）输出全部生效配置，搜索limit_conn，确认它确实出现在你测试的 location 路径下，而不是被 include 错误覆盖或遗漏
验证客户端请求是否命中限流逻辑
限流不触发，常因请求根本没走到目标 location：
- 检查请求 URI 是否匹配你加了
limit_conn的 location。比如配在location /api/，但实际请求是/v1/login，那就完全绕过了 - 确认没有更高优先级的 location（如
location = /health或正则 location）提前截断并返回，导致 limit_conn 根本不执行 - 用
curl -v http://your-domain/test+ 查看 Nginx access_log 中的$request_uri和$status，确认日志里该请求确实进了带限流的块
排除系统级和进程级资源干扰
即使 Nginx 配置无误，底层资源不足也会让限流“形同虚设”：
- 单个 worker 进程能打开的文件描述符数受限于
worker_rlimit_nofile和系统ulimit -n，若设了limit_conn addr 10，但每个 worker 只能开 1024 个 fd，而同时有 200 个 IP 访问，那前 10 个 IP 就可能占满连接池，其余直接被系统拒绝（表现为 connection refused，而非 503） - 用
ss -s看当前 ESTABLISHED 连接总数，再对比worker_processes × limit_conn 值，如果远超理论值，说明限流没生效；如果接近但仍有漏网，可能是 burst 或其他模块（如 limit_req）干扰 - 注意：limit_conn 是按 key 统计并发连接数，不是请求数。HTTP/1.1 长连接下，一个连接可发多个请求，所以看到连接数少但请求量大，不等于限流失效
用 ab 或 wrk 实测时避开常见陷阱
压测工具本身行为会影响结果判断：
- ab 默认使用 HTTP/1.0，不复用连接，
-c 10表示发起 10 个独立 TCP 连接 —— 此时limit_conn addr 10对单个 IP 是允许的，不会触发限制；要验证，得用-c 11或换用支持长连接的工具（如wrk -c 50 -t 2 --keepalive http://host/path） - 确保压测 IP 是单一固定地址（如本地用
127.0.0.1），否则$binary_remote_addrkey 不一致，每个 IP 都算独立限额 - 观察响应状态码：真正触发 limit_conn 会返回 503 Service Temporarily Unavailable，不是 429（那是 limit_req）或 502
