我碰到过好几次这种情况，这是系统文件句柄资源耗尽导致的Docker连接异常，给你梳理下解决思路和具体方案：

问题根源 #

错误('Connection aborted.', error(24, 'Too many open files'))本质是系统允许进程打开的文件句柄数不够用了。Docker在管理容器时需要打开大量套接字、日志文件、镜像层文件等资源，当可用句柄被耗尽，就会出现连接中断的情况。手动重试能成功是因为重试时部分资源已经被释放了，但自动化流程没法等，所以得从根源解决。

临时应急方案（快速解决当前部署问题） #

如果现在要先把部署跑起来，可以试试这两个临时办法：

• 先清理Docker闲置资源，释放句柄：

  docker system prune -f
  

  这个命令会删除停止的容器、未使用的镜像、悬空的网络和卷，能快速释放一批资源。
• 临时调高当前Shell的文件句柄限制，再执行down：

  ulimit -n 65535
  docker-compose down
  

  注意这个设置只对当前终端会话有效，重启后会恢复默认值。

永久解决办法（避免后续再出现） #

1. 调整系统全局文件句柄限制 #

编辑系统的限制配置文件，让全局的句柄数足够用：

• 打开/etc/security/limits.conf，添加以下内容（如果是普通用户执行Docker，把root换成你的用户名）：

  root soft nofile 65535
  root hard nofile 65535
  

• 打开/etc/sysctl.conf，添加系统级的文件句柄上限：

  fs.file-max = 655350
  

• 执行以下命令让配置生效：

  sysctl -p
  

  之后重启系统或者重新登录，设置就会生效。

2. 给Docker守护进程单独配置句柄限制 #

Docker本身的守护进程也需要足够的句柄数，编辑Docker的配置文件：

• 如果没有/etc/docker/daemon.json，先创建这个文件，然后添加：

  {
    "default-ulimits": {
      "nofile": {
        "Name": "nofile",
        "Hard": 65535,
        "Soft": 65535
      }
    }
  }
  

• 重启Docker服务让配置生效：

  systemctl restart docker
  

3. 优化你的部署脚本 #

在自动化流程里加入防护机制，避免单次失败导致整个部署中断：

• 先停止容器再执行down，给资源释放留时间：

  docker-compose stop
  sleep 5  # 等待容器彻底停止，释放句柄
  docker-compose down
  

• 加入重试逻辑，自动重试失败的down命令：

  MAX_RETRIES=3
  RETRY_COUNT=0
  
  until docker-compose down; do
    RETRY_COUNT=$((RETRY_COUNT + 1))
    if [ $RETRY_COUNT -ge $MAX_RETRIES ]; then
      echo "Docker-Compose Down failed after $MAX_RETRIES attempts"
      exit 1
    fi
    echo "Retrying Docker-Compose Down (Attempt $RETRY_COUNT/$MAX_RETRIES)..."
    sleep 3
  done
  

  这样即使第一次执行失败，脚本会自动重试，大概率能成功。

额外排查点 #

如果调整完限制还是偶尔出现问题，可能是应用本身的资源泄漏：

• 用docker inspect <容器名> | grep Pid找到容器的PID，然后用lsof -p <PID>查看这个容器打开的文件数，如果数值异常高，说明你的应用代码可能存在文件句柄泄漏（比如打开文件/套接字后没关闭），需要排查应用代码。
• 查看系统当前的句柄使用情况：cat /proc/sys/fs/file-nr，第一个数字是已使用的句柄数，第三个是总上限，能帮你判断资源是否真的足够。

内容的提问来源于stack exchange，提问作者fred00