Windows环境下Selenium Docker容器运行崩溃，提示DevToolsActivePort文件不存在

核心根因 #

这套部署方案在Mac、Linux原生Docker环境下可正常运行，本质是两个平台对/dev/shm的映射、容器文件权限逻辑为全量透传。而Windows下通过WSL2运行Docker Desktop时，存在三层无明确报错的隐性兼容问题，会直接导致Chrome进程启动即崩溃，通用启动参数完全无法覆盖：

• WSL2宿主机默认分配的共享内存仅64M，原有compose配置里的/dev/shmbind mount会把这个极小的配额透传给容器，远低于Chrome运行所需的内存阈值
• Windows下的bind mount路径存在权限映射偏差，Chrome进程无法正常写入DevTools端口文件
• Docker Desktop默认开启的WSL GPU直通会干扰Chrome的启动初始化流程

逐步骤修复操作 #

1. 调整docker-compose配置 #

替换原有的dev/shm挂载逻辑，改用容器级共享内存配额，绕开Windows路径映射兼容问题，同时把之前测试过但未生效的Chrome启动参数直接通过环境变量注入容器启动流程，不再依赖业务代码传参：

version: '3.4'
services:
  # 承载Chrome浏览器、ChromeDriver运行环境
  chrome:
    image: selenium/standalone-chrome-debug
    shm_size: '2gb'
    user: "1200:1201" # 匹配selenium镜像内置的Chrome运行用户权限
    environment:
      CHROME_OPTS: "--headless=new --no-sandbox --disable-dev-shm-usage --disable-gpu --window-size=1920,1080"
    ports:
      - "4444:4444"
      - "5900:5900"
  # 承载PHP webdriver库运行环境
  php7:
    build:
      context: .
      dockerfile: ./Dockerfile
    volumes:
      - .:/wdir/
    depends_on:
      - chrome
    command: tail -F anything

关键修改说明：

• 移除原来的/dev/shm:/dev/shmbind mount，替换为容器专属的2G共享内存配额，彻底绕开WSL2的shm透传限制
• 通过user参数固定Chrome运行的用户UID/GID，解决Windows下bind mount导致的临时目录写权限不足问题
• 把之前排查阶段加过的--headless、--no-sandbox参数直接通过CHROME_OPTS环境变量注入到Selenium镜像的启动逻辑中，避免业务代码传参在WSL网络链路下被拦截导致参数不生效的问题

2. 调整Docker Desktop的WSL配置 #

• 打开Docker Desktop设置面板，进入Resources > WSL Integration配置页
• 关闭对应WSL发行版的GPU直通开关，重启Docker Desktop使配置生效
• 清理旧的容器缓存后重新启动服务：

  docker-compose down --rmi local
  docker-compose up -d
  

3. 启动状态验证 #

执行PHP测试脚本前，先单独进入Chrome容器验证进程可正常启动，减少无效排查：

# 查看运行中的Chrome容器ID
docker ps
# 进入容器手动执行Chrome连通性测试
docker exec -it <chrome容器ID> google-chrome --headless=new --no-sandbox --disable-dev-shm-usage --dump-dom https://example.com

如果命令可正常返回目标站点的DOM内容，说明配置完全生效，再执行PHP的webdriver脚本就不会触发DevToolsActivePort file doesn't exist的崩溃报错。 #

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