直接在server块中配置limit_conn并搭配http块定义的全局共享内存区域，可限制该Server最大总并发连接数；需用固定key（如""）定义zone，再在server中用limit_conn绑定并设上限。

直接在 server 块中配置 limit_conn，并搭配全局共享内存区域，就能限制该 Server 的最大总并发连接数。它不依赖请求路径或内容，只统计已建立、未关闭的活跃 TCP 连接，开销低、见效快。

定义全局连接计数区域（必须在 http 块）

这是前提，相当于为整个 Server 准备一张“连接总数登记表”：

• 用 $binary_remote_addr 不适合总连接限制——它按 IP 分组，无法统计全局总量
• 应选用一个固定不变的 key，比如空字符串 "" 或常量变量 $server_name（若单 server）
• 推荐写法：limit_conn_zone "" zone=server_total:10m; —— 空字符串作为 key，所有连接都计入同一桶，10MB 内存可支撑约 16 万连接状态
• 该指令只能放在 http{} 块顶层，不能嵌套在 server 或 location 中

在 server 块中启用总连接限制

绑定前面定义的 zone，并设定硬性上限：

• limit_conn server_total 2000; 表示整个 server 最多维持 2000 个并发 TCP 连接
• 该限制对所有进入该 server 的流量生效：静态资源、API 代理、Vue 前端路由回退、甚至健康检查探针都算在内
• HTTP/2 下一个连接含多个 stream，仍只计为 1；keepalive 空闲连接也持续占配额，建议同步设置 keepalive_timeout 15;

配合关键参数提升可观测性与语义准确性

单独限连接数能防资源耗尽，加几行能让行为更可控：

• limit_conn_log_level error;：把触发拦截的日志提至 error 级，避免 warn 日志刷屏，便于快速定位异常流量
• limit_conn_status 503; 或 429;：明确返回状态码，429 更符合 RFC 标准，前端和监控系统更容易识别是“被限流”而非“服务不可用”
• 如需叠加防护，可在同一 zone 上复用（例如 limit_req zone=server_total burst=10 nodelay;），但注意 limit_req 依赖完整请求头解析，延迟略高于 limit_conn

不复杂但容易忽略：总连接限制必须用固定 key 定义 zone，且要放在 http 块；真正起作用的 limit_conn 指令则放在 server 块内。两者缺一不可。