Docker中“最大并发打开文件数”本质是文件描述符（fd）限制，每个TCP连接等至少占1个fd，默认1024远低于高并发需求，必须通过--ulimit nofile=65536:65536等显式设置软硬限，并协同调整宿主机daemon及系统级fs.file-max参数才能生效。

在 Docker 中，“最大并发打开文件数”本质就是文件描述符（file descriptor，fd）数量限制。它不是并发连接数的直接开关，而是底层硬性门槛——每个 TCP 连接、每个日志文件、每个配置读取都占用至少 1 个 fd。默认 1024 的限制，在 Nginx、Redis、Node.js 或 Java 应用高并发场景下，几秒内就会触发 too many open files 错误，导致服务拒绝新请求甚至崩溃。

为什么必须显式设置 nofile？

Docker 容器默认继承宿主机 daemon 的 ulimit（通常是 1024），且不会自动适配应用需求。这个值远低于生产环境常见要求（如 65536）。不设限，等于给高速列车装自行车轮胎——跑不起来，还容易爆胎。

• 软限制（soft limit）：进程实际能用的上限，启动时生效，可运行时调低
• 硬限制（hard limit）：软限制能提升到的最高值，需容器有 sys_resource 能力或 root 权限才能突破
• 只设软限不设硬限，应用后续想动态扩容（比如 Java 的 FileDescriptor 复用）会失败

容器级 nofile 设置（最常用）

这是对单个容器生效的最直接方式，覆盖应用进程及其子进程（前提是启动脚本不重置 ulimit）。

• 命令行启动：
  docker run --ulimit nofile=65536:65536 nginx
• Docker Compose：
  

  services:<br>  app:<br>    image: my-node-app<br>    ulimits:<br>      nofile:<br>        soft: 65536<br>        hard: 65536

• 验证是否生效：
  docker exec -it sh -c 'ulimit -n' → 应返回 65536
  docker exec -it cat /proc/1/limits | grep "Max open files" → 查看完整软硬限

宿主机级 Docker daemon 限制（影响所有容器）

如果多个容器都需高 fd，或你用 docker-compose up 批量启服，建议统一提升 Docker 进程自身的限制，避免每个容器单独配。

Docker Desktop 4.96.1

下载

• 创建 systemd 覆盖配置：
  sudo mkdir -p /etc/systemd/system/docker.service.d
  

  sudo tee /etc/systemd/system/docker.service.d/open-limit.conf [Service]<br>LimitNOFILE=65536<br>EOF

• 重载并重启：
  sudo systemctl daemon-reload && sudo systemctl restart docker
• 验证：
  sudo systemctl show --property=LimitNOFILE docker → 应显示 65536

系统级全局文件句柄上限（兜底保障）

当容器总数多、fd 总用量逼近系统瓶颈时，需检查并提升内核级总容量，否则即使单个容器设得再高也无意义。

• 查看当前系统上限：
  cat /proc/sys/fs/file-max
• 临时提升（重启失效）：
  sudo sysctl -w fs.file-max=100000
• 永久生效（写入配置）：
  echo "fs.file-max = 100000" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p
• 同时检查使用水位：
  cat /proc/sys/fs/file-nr → 若第一列（最大）与第二列（已分配）接近，说明系统级已吃紧

不复杂但容易忽略：三个层级（系统 → daemon → 容器）要协同调整，只改其中一层，常出现“设了等于没设”的情况。实际压测时，配合 ss -s 或 lsof -p 1 | wc -l 观察 fd 实际占用，才能真正闭环验证。