limit_conn 不能限制单个 API 路径并发量，因其仅按客户端 IP 统计 TCP 连接数，与 URL、路径、HTTP 方法无关；现代 HTTP/2 和 keep-alive 使单连接承载多请求，更难反映真实负载。
limit_conn 不能直接限制单个 API 路径的并发吞吐量。它只限制“同一客户端 IP 在同一时刻能维持多少个活跃 TCP 连接”，与请求路径、URL、HTTP 方法或后端响应内容完全无关。
为什么 limit_conn 不适用于 API 路径级限流
limit_conn 的作用粒度是连接（connection），不是请求（request）。只要一个 IP 建立了 10 个 TCP 连接，哪怕这 10 个连接分别发的是 /api/user、/api/order、/static/logo.png，全都会被计入同一个计数器。它无法区分“这是 /api/login 的第 3 个并发”，也无法感知路径语义。
此外，现代 API 多走 HTTP/2 或复用长连接（keep-alive），单个连接可承载多个请求——此时 limit_conn 更难反映真实负载压力。
真正适合 API 路径限流的方案是 limit_req
要实现“仅对 /api/v1/pay 每秒最多处理 20 个请求，允许突发 5 个”，必须用 limit_req 模块：
- 在
http块定义共享区域：limit_req_zone $binary_remote_addr zone=pay_limit:10m rate=20r/s; - 在对应
location中启用：location /api/v1/pay {<br> limit_req zone=pay_limit burst=5 nodelay;<br> proxy_pass http://backend;<br>} -
burst=5表示允许瞬时积压 5 个请求；nodelay让它们不排队、立刻拒绝超限请求（返回 503）
若仍想用连接维度做粗粒度防护，可搭配 location 使用
虽然不能精确到路径，但你可以把高危 API 单独归到一个 location，并在此处施加连接限制，作为兜底手段：
- 定义全局连接区：
limit_conn_zone $binary_remote_addr zone=api_conn:10m; - 在 API 入口 location 中启用：
location ^~ /api/ {<br> limit_conn api_conn 8;<br> limit_conn_status 503;<br> proxy_pass http://backend;<br>} - 注意：
^~ /api/会匹配所有以/api/开头的路径，包括/api/docs和/api/static，需确保后端能正确路由或前置过滤
生产环境建议组合使用
单一模块难以应对复杂攻击场景：
- 用
limit_req控制请求速率（防刷接口、防爆破） - 用
limit_conn控制连接总数（防慢连接耗尽 fd） - 配合
limit_rate限制响应带宽（防大文件下载打满出口） - 前端加 token 或签名验证，后端做业务级熔断（如 Hystrix / Sentinel）
