最可靠方式是用hey或ab发起多连接压测，观察是否返回429/503，并核对Nginx error.log中“limiting connections by zone”日志及客户端响应，需注意HTTP/2和keepalive对连接计数的影响。
直接用并发压测工具发起多连接请求，观察是否返回限流状态码（如 429 或 503），并核对错误日志和连接计数，是最可靠的方式。
用 hey 或 ab 模拟单 IP 高并发连接
这类工具能真实模拟 TCP 连接建立行为，贴合 limit_conn 的触发机制（它只在 connect 阶段计数）：
-
hey（推荐）：支持 HTTP/1.1 和 HTTP/2，可精确控制并发连接数
命令示例：hey -n 100 -c 20 -m GET http://your-site.com/api/test
其中-c 20表示从本机发起 20 个并发 TCP 连接，若你配置了limit_conn perip 10，约前 10 个连接会成功，后续连接大概率被拒绝 -
ab（Apache Bench）：适合 HTTP/1.1 场景
命令示例：ab -c 15 -n 60 http://your-site.com/
注意：ab 默认复用连接（keep-alive），如需测试“新建连接”拦截效果，加-k保持长连接反而会掩盖问题，建议先关掉：ab -c 15 -n 60 -H "Connection: close" http://your-site.com/
检查 Nginx 错误日志确认拦截生效
limit_conn 触发时会在 error.log 中写入明确标识，这是最直接的证据：
- 执行压测后，实时查看：
tail -f /var/log/nginx/error.log - 看到类似日志即表示命中限制：
limiting connections by zone "perip" —— 说明 zone 名称匹配、逻辑已运行
client: 192.168.1.100, server: your-site.com, request: "GET /api/test HTTP/1.1" —— 显示被限的具体客户端与请求 - 若没看到该日志，说明配置未加载、zone 名不一致、或 limit_conn 没放在生效的 server/location 块中
验证响应状态码与客户端行为
光看日志不够，要确认客户端真实收到的响应是否符合预期：
- 默认返回 503，但建议显式设为
limit_conn_status 429（语义更清晰，便于前端识别重试） - 用 curl 手动验证单连接是否正常、多连接是否被拒：
curl -I http://your-site.com/api/test→ 应返回 200curl -I --connect-timeout 3 http://your-site.com/api/test（快速连多次）→ 多次中部分应返回 429 - 浏览器开发者工具 Network 标签页里刷新多次，看是否有请求卡在 pending 状态（说明 keepalive 连接占满配额，新连接被阻塞）
注意 HTTP/2 和 keepalive 对测试的影响
这两点最容易导致测试结果与预期不符：
-
HTTP/2 下一个连接承载多个 stream：limit_conn 把整个 TCP 连接算作 1 个，不管里面开了多少个请求。所以用 Chrome 访问时，即使打开 10 个标签页，可能只建 1–2 个连接——不会触发限制。测试时建议用
hey -h2或临时禁用 HTTP/2 -
keepalive_timeout 过长会“锁住”连接：比如设了
keepalive_timeout 300;，一个空闲连接会持续占用配额 5 分钟。测试前建议调低：keepalive_timeout 15;，让连接更快释放，便于复现拦截效果
