Docker容器无直接“最大并发连接数”参数，真实限制来自应用层（如Nginx、MySQL配置）、内核文件描述符（默认1024，需--ulimit nofile=65536:65536提升）、CPU/内存配额（如--cpus=1.5、--memory=1g）及系统级网络参数（如net.core.somaxconn=65535）。
在 Docker 中，容器本身不直接提供“最大并发连接数”这个参数，真正的连接数限制来自三层：应用层（如 Nginx、MySQL、Node.js）、内核资源（文件描述符 fd 和 socket 限制）、以及 Docker 运行时对进程和资源的管控。配置需协同生效，单点设置常无效。
应用层连接数控制（最常用且推荐）
这是最可控、最贴近业务逻辑的一层，不同服务有各自标准方式：
-
Nginx：在配置中用
worker_connections（配合events块）和limit_conn指令限制每 worker 的连接数或按 key 限流 -
MySQL：启动时通过
--max-connections=500或在my.cnf的[mysqld]下设max_connections=500；注意若容器内 ulimit 未调高，该值可能被系统级 fd 限制卡死在 214 -
Node.js：设置
server.maxConnections = 100（仅对 http.Server 生效），同时确保使用 keep-alive 复用连接 -
RabbitMQ：修改
/etc/rabbitmq/rabbitmq.conf，添加rabbit.max_connections = 2000
文件描述符（fd）限制是底层硬门槛
每个 TCP 连接占用至少 1 个文件描述符。Linux 默认单进程最多打开 1024 个 fd，远低于高并发需求。Docker 容器默认继承宿主机 daemon 的 ulimit，必须显式提升：
- 启动容器时加参数：
--ulimit nofile=65536:65536 - Docker Compose 写法：
ulimits: { nofile: { soft: 65536, hard: 65536 } } - 验证是否生效：进入容器执行
ulimit -n，应返回65536
CPU 与内存配额影响实际并发能力
即使连接数设得很高，若容器得不到足够 CPU 时间或内存，新连接会排队、超时甚至触发 OOM Kill。合理配额才能让连接数设定真正落地：
- 限制 CPU 使用率（避免调度饥饿）：
--cpus=1.5或更精细的--cpu-quota=150000 --cpu-period=100000 - 限制内存上限防雪崩：
--memory=1g，并建议加--memory-swap=1g禁用 swap - 限制进程总数防 fork 炸弹：
--pids-limit=200（尤其对 PHP-FPM、Java 应用重要）
网络栈与系统级调优（进阶但关键）
当并发连接数破万，还需调整内核参数，否则连接会卡在 SYN_QUEUE 或 TIME_WAIT：
- 宿主机上运行：
sysctl -w net.core.somaxconn=65535和net.ipv4.tcp_max_syn_backlog=65535 - 若用 host 网络模式（
--network=host），这些参数直接生效；桥接模式下效果有限，建议只在低延迟场景启用 host 模式 - 容器内一般无需改
/proc/sys/net/...，因多数参数不可写入容器命名空间
