worker_connections 是每个 Nginx worker 进程可维持的 TCP 连接上限，需与 worker_processes、内核 somaxconn、ulimit 及后端承接能力协同调优，盲目调高反致性能恶化。

要让 worker_connections 真正支撑百万级 MQTT/TCP 设备接入，关键不在盲目调高数值，而在于理解它在 Nginx 架构中的定位，并配合操作系统、Netty 接入层与 broker 集群协同优化。Nginx 本身不处理 MQTT 协议，它只做 TCP 层负载均衡（即四层代理），所以 worker_connections 是指每个 Nginx worker 进程能同时维持的TCP 连接数上限，不是设备总数，更不是 MQTT 会话数。

注意：单台 Nginx 节点的 worker_connections × worker_processes 通常建议控制在 50 万以内，超过需谨慎评估内核与内存压力。

明确 Nginx 在物联网架构中的角色

Nginx 不解析 MQTT 报文，仅转发原始 TCP 流。典型链路是：
设备 → Nginx（TCP 负载均衡）→ 后端 Netty 接入网关集群 或 VerneMQ/BifroMQ broker 集群
因此，worker_connections 只影响 Nginx 本机的连接承载能力，而非整个系统的并发上限。

合理配置 worker_connections 的实操要点

• 设置 worker_processes auto; 让 Nginx 自动匹配 CPU 核心数（如 32 核服务器，启动 32 个 worker）
• 每个 worker_connections 建议设为 32768～65536（非越高越好）
• 总连接能力 = worker_processes × worker_connections，例如 32 × 65536 ≈ 209 万，但实际需留出 30% 余量应对连接抖动和 TIME_WAIT
• 必须同步调整 Linux 内核参数：
  • fs.file-max = 10000000（系统级文件描述符上限）
  • net.core.somaxconn = 65535（连接完成队列长度）
  • net.ipv4.ip_local_port_range = 1024 65535（可用端口范围）
  • net.ipv4.tcp_tw_reuse = 1（允许 TIME_WAIT 套接字重用）

更关键的是后端承接能力

Nginx 只是“门卫”，真正消耗资源的是后端：

• Netty 接入网关需启用 PooledByteBufAllocator 和 IdleStateHandler，避免内存碎片与心跳积压
• 每个 Netty worker 线程应绑定固定 CPU 核心，EventLoopGroup 线程数不宜超过 CPU 逻辑核数
• MQTT broker（如 VerneMQ）需配置 max_connections 和 vm_args +P 2000000，否则连接会在 broker 层被拒绝
• 所有节点必须使用 Redis Cluster 或 Kafka 统一管理会话状态，避免 Nginx 轮询导致会话丢失

避免常见误配置

• ❌ 将 worker_connections 设为 1000000 并认为“万事大吉”——这会导致单 worker 内存暴涨、GC 频繁、响应延迟飙升
• ❌ 忽略 ulimit -n 用户级限制，默认常为 1024，必须在 /etc/security/limits.conf 中为 nginx 用户设置 nofile 至 1000000
• ❌ 未开启 tcp_nodelay on; 和 keepalive_timeout 120s;，造成小包堆积或空闲连接过早断开

不复杂但容易忽略