worker_connections需与容器网络模式协同调优：bridge模式下须同步提升nofile、somaxconn及conntrack表容量；host模式下则需显式配置worker_rlimit_nofile并合理设置worker_processes与cpu亲和性。
worker_connections 本身是 Nginx 的配置项，不直接“感知”容器网络模式；但它在 Docker 中生效时，实际并发能力会因网络模式不同而被系统层限制卡住。补偿的关键不是调大这个数字本身，而是确保它背后依赖的底层资源（文件描述符、内核连接队列、网络栈路径）同步跟上——尤其在 bridge 模式下损耗明显，host 模式下则需绕过隐性瓶颈。
bridge 模式下：补足三道“隐形闸门”
bridge 是默认模式，但数据包要经过 docker0 网桥 → iptables NAT → conntrack 表 → 容器协议栈，每一步都消耗 fd 和 CPU。此时只改 worker_connections 无效，必须同步放开：
-
容器内文件描述符上限：启动时加
--ulimit nofile=65536:65536，确保ulimit -n输出 ≥ worker_connections × 1.2（预留日志、上游连接等） -
内核监听队列长度：用
--sysctl net.core.somaxconn=65535，避免新连接在进入 Nginx 前就被内核丢弃（默认仅 128） -
conntrack 表容量：若用 bridge 模式且连接密集，宿主机需调大
net.netfilter.nf_conntrack_max（如设为 1048576），否则表满后新建连接失败
host 模式下：避开转发，但别漏掉进程级限制
host 模式跳过了 docker0 和 iptables，延迟低、吞吐高，看似“一劳永逸”，但容易忽略两个关键点：
-
Nginx 进程自身 fd 限制：即使宿主机 ulimit 很高，容器内 Nginx 仍可能受限。必须在 nginx.conf 中显式写
worker_rlimit_nofile 65535;，且该值 ≥ worker_connections -
worker_connections 与 CPU 实际匹配：host 模式下 Nginx 直接绑定宿主机 CPU，若
worker_processes auto识别出 32 核，但业务是 I/O 密集型，反而可能因上下文切换拖慢；建议设为 CPU 物理核心数（非超线程数），并配worker_cpu_affinity
无论哪种模式，都要验证是否真正生效
光改配置没用，得进容器里确认：
- 运行
cat /proc/sys/net/core/somaxconn，看是否等于你 --sysctl 设的值 - 执行
ulimit -n，确认输出 ≥ 所设 worker_connections - 查 Nginx 错误日志，出现
accept() failed (24: Too many open files)就说明某处 fd 没放开 - 压测时用
ss -s观察total:和tcp:行，对比理论最大值（worker_processes × worker_connections）与实际 ESTABLISHED 数量差
配置示例：兼顾安全与性能的最小闭环
以 8 核服务器、目标 8 万并发为例：
- Docker 启动命令：
docker run --network host --ulimit nofile=100000:100000 --sysctl net.core.somaxconn=65535 -d my-nginx - nginx.conf events 块：
worker_processes 8; worker_rlimit_nofile 100000; events { worker_connections 10000; use epoll; multi_accept on; } - 效果：单 worker 最多处理 1 万连接，8 个 worker 理论支撑 8 万，且所有依赖项均留出 15%~20% 冗余空间
