WSL中docker-compose忽略DOCKER_HOST配置，启动容器遇阻

我之前在WSL环境里用Docker连接Windows引擎时也碰到过类似的docker-compose执行问题，结合你的场景，给你几个具体的排查和解决方向：

1. 核心问题：sudo重置了DOCKER_HOST环境变量 #

你在.bashrc里配置的export DOCKER_HOST=tcp://127.0.0.1:2375是针对普通用户会话的，但用sudo执行命令时，系统会重置大部分环境变量，导致docker-compose找不到正确的Docker引擎地址，默认尝试连接WSL本地的Unix socket（而你根本没在WSL里装Docker daemon），自然会失败。

解决办法：

• 临时方案：执行命令时手动传递环境变量：

  sudo DOCKER_HOST=tcp://127.0.0.1:2375 docker-compose up --build
  

• 永久方案：修改sudoers配置，让sudo保留DOCKER_HOST变量（谨慎操作）：
  1. 执行sudo visudo打开sudoers文件
  2. 在Defaults env_reset行下面添加：

     Defaults env_keep += "DOCKER_HOST"
     

  3. 保存退出后，下次用sudo执行docker-compose就会自动带上这个变量了。

2. 检查docker-compose的兼容性与安装状态 #

有时候WSL里的docker-compose版本和Windows上的Docker引擎版本不匹配，或者你是直接调用Windows的docker-compose程序（比如通过/mnt/c挂载的路径），可能会出现兼容性问题。

排查步骤：

• 先分别查看版本：

  docker version  # 查看Docker引擎版本（来自Windows）
  docker-compose --version  # 查看WSL里的docker-compose版本
  

如果版本差异过大，建议在WSL里重新安装对应版本的docker-compose，或者直接使用Windows的docker-compose（在WSL里设置别名，比如alias docker-compose='/mnt/c/Program\ Files/Docker/Docker/resources/bin/docker-compose.exe'）。

3. 项目目录的挂载权限问题 #

如果你的项目放在Windows的磁盘挂载目录（比如/mnt/c/xxx），WSL对这类目录的权限处理可能有问题，导致docker-compose读取配置文件、挂载卷时出错。

解决办法：

• 把项目迁移到WSL的原生目录（比如~/my-project），再执行docker-compose命令；
• 或者修改WSL的挂载配置：编辑/etc/wsl.conf（如果没有就新建），添加以下内容：

  [automount]
  options = "metadata,umask=0022"
  

  保存后重启WSL（Windows终端执行wsl --shutdown再重新打开），挂载目录的权限会更接近Linux原生权限。

4. 端口冲突或资源占用检查 #

虽然基础docker命令正常，但docker-compose里定义的服务（比如MySQL的3306、Redis的6379）可能被Windows上的其他程序占用了，导致容器启动失败。

排查步骤：

• 在Windows命令提示符里执行：

  netstat -ano | findstr :3306  # 检查MySQL端口
  netstat -ano | findstr :6379  # 检查Redis端口
  

如果发现有进程占用，要么停止对应进程，要么修改docker-compose.yml里的端口映射（比如把3306:3306改成3307:3306）。

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