Docker+DDEV搭建Drupal 9本地开发环境实战指南

发布时间:2026/7/2 19:25:49

Docker+DDEV搭建Drupal 9本地开发环境实战指南 1. 为什么本地用 Docker DDEV 搭建 Drupal 9 站点是当前最稳的开发起点你是不是也经历过装完 PHP 7.4、MySQL 8.0、Apache配好 mod_rewrite再手动下载 Drupal 9 核心、解压、改权限、建数据库、跑 install.php……结果浏览器一刷报错“PHP extension gd is missing”回头装 GD又发现php-gd包名在 Ubuntu 是php-gdCentOS 是php-gdmacOS Homebrew 是php8.1-gd——光扩展依赖就能卡你两小时。更别说团队协作时同事的环境是 PHP 8.0 MariaDB 10.5你的却是 PHP 8.2 MySQL 8.0一个json_encode()的返回类型差异就让模块报错排查三天才发现是 PHP 版本小版本不一致。这就是纯手工搭环境的硬伤环境不可复现、依赖难收敛、协作成本高、升级风险大。而 Docker DDEV 的组合本质上不是“多装了个工具”而是把整个开发环境从“物理机配置”升级为“可版本化、可 Git 提交、可一键重建”的声明式基础设施。DDEV 不是 Docker 的简单封装它是专为 PHP Web 开发尤其是 Drupal、WordPress、TYPO3 这类 CMS打磨了近十年的“环境编排层”——它自动处理 Nginx 配置、PHP-FPM 调优、MySQL 字符集、Drush/Drupal Console 命令注入、HTTPS 本地证书生成、甚至 Xdebug 的端口映射和 IDE 断点联动。我去年带一个 6 人 Drupal 团队重构政府门户新成员入职后从 clone 代码库到打开/user/login页面全程只用了 11 分钟git clone→ddev config→ddev start→ddev drush si standard -y。没有文档里写的“请确保已安装 Composer”没有“请检查 MySQL 是否运行”没有“请确认 Apache 虚拟主机已启用”。因为 DDEV 启动那一刻它拉起的是一整套经过 Drupal 社区验证的容器栈nginx:1.23 php:8.1-apache mariadb:10.6 phpmyadmin:5 mailhog:1.0 —— 所有服务版本、配置参数、网络互通、卷挂载路径全部预设完毕。你真正要关心的只有 Drupal 本身的模块逻辑、主题模板和内容结构。这才是现代 PHP 开发该有的样子开发者专注业务环境交给工具。2. 整体架构设计与核心组件选型逻辑2.1 为什么不是纯 Docker ComposeDDEV 的不可替代性在哪看到标题里有 Docker很多人第一反应是“我自己写个 docker-compose.yml 不就行了”确实可以但实际踩坑后你会发现纯 Compose 方案在 Drupal 场景下会迅速陷入“配置黑洞”。举几个真实场景PHP 扩展动态加载问题Drupal 9.5 强制要求mbstring、xml、zip、gd、opcache等 12 个扩展。纯 Compose 里你得自己维护一个Dockerfile每次 PHP 升级都要重写apt-get install和docker-php-ext-*命令。而 DDEV 内置的php_version配置项如php_version: 8.1背后是它预编译好的、经 Drupal.org CI 测试通过的 PHP 镜像仓库。你改一行配置它自动切换整个 PHP 运行时连php.ini里opcache.enable1、memory_limit512M这些 Drupal 推荐值都已调优。文件权限地狱Drupal 的sites/default/files目录必须由 web 服务器用户www-data可写但宿主机上你的用户是ubuntu或macuser。纯 Compose 里你要么chown -R www-data:www-data sites/default/files导致宿主机无法编辑要么用user: ${UID}:${GID}在 Windows 上根本无效。DDEV 的解决方案是在容器内创建与宿主机 UID/GID 完全一致的用户并映射到 www-data 组。它启动时自动执行usermod -u ${UID} -g ${GID} www-data再chown -R www-data:www-data /var/www/html。这意味着你在 VS Code 里右键新建一个.txt文件容器内ls -l看到的 owner 就是www-dataDrupal 表单上传图片时move_uploaded_file()一次成功。命令行工具链集成drush、ddev drush、ddev composer、ddev mysql这些命令表面看只是加了个ddev前缀实则背后是 DDEV 的“命令代理”机制。当你执行ddev drush crDDEV 并非简单地docker exec -it web drush cr而是检查当前目录是否为 DDEV 项目读取.ddev/config.yaml确认web容器已运行且健康将宿主机的$HOME/.composer/auth.json、$HOME/.drush配置卷挂载进容器在容器内以www-data用户身份执行drush cr并实时将 stdout/stderr 流回宿主机终端如果命令失败自动捕获 exit code 并输出上下文日志如ddev logs -s web。这种深度集成是纯 Compose 无法提供的开箱即用体验。DDEV 的定位很清晰它不是 Docker 的竞争对手而是 Drupal 开发者的“环境操作系统”。2.2 Docker 引擎与 DDEV 的协同关系谁在管什么很多新手混淆 Docker Engine 和 DDEV 的职责边界。这里用一个生活化类比说明Docker Engine 是“建筑工地的起重机和混凝土搅拌机”DDEV 是“持有全套施工图纸、调度所有工种、验收每道工序的项目经理”。Docker Engine含 dockerd、containerd、runc负责最底层的容器生命周期管理。它监听/var/run/docker.sock接收docker run、docker build等 API 请求调用 Linux kernel 的 cgroups/ns 创建隔离进程管理镜像层存储overlay2、网络bridge/host/macvlan和卷bind mount/volume。你不需要直接操作它DDEV 全部封装好了。DDEV CLIddev binary这是你每天打交道的命令行工具。它本质是一个 Go 编写的“Docker 操作胶水层”。当你输入ddev start它做的第一件事是调用docker info确认引擎可用第二步是读取.ddev/config.yaml解析项目类型type: drupal9第三步是根据php_version、webserver_typenginx/apache等参数拼接出最终的docker-compose.yaml存于.ddev/.ddev-docker-compose-full.yaml第四步才是执行docker-compose -f .ddev/.ddev-docker-compose-full.yaml up -d。这个过程完全透明你只需关注ddev start的结果。DDEV 的容器栈Web/DB/DBA/MAILHOG这是真正运行 Drupal 的“工人”。其中web容器基于ddev/web-apache-php:20230915_v1.22.4预装了 Drupal 9 全套依赖PHP 8.1、Apache 2.4、GD/ImageMagick、Xdebug 3.2、Drush 11、Drupal Console、Composer 2.5。db容器ddev/db-mariadb-10.6:20230915_v1.22.4默认启用innodb_file_per_table1和character_set_serverutf8mb4完美匹配 Drupal 9 的数据库要求。这些镜像不是随便 pull 的而是 DDEV 团队每日构建、通过 Drupal.org 的simpletest套件验证的“黄金镜像”。所以你的工作流应该是信任 DDEV 的默认配置 → 仅在必要时微调.ddev/config.yaml→ 用ddev命令而非docker命令操作环境。试图绕过 DDEV 直接docker exec进容器改配置就像绕过项目经理直接指挥塔吊司机——短期内可能快长期必然混乱。2.3 Drupal 9 专属适配点为什么 DDEV 对 Drupal 的支持远超其他 CMSDDEV 的 GitHub 仓库里有个鲜为人知但极其关键的文件pkg/ddevapp/drupal.go。这个 Go 文件定义了 DDEV 如何“理解”Drupal 项目。它不是简单地检测index.php存在而是进行三级智能识别文件系统指纹识别扫描根目录是否存在core/modules/Drupal 8/9 核心模块目录、sites/default/settings.phpDrupal 配置文件、vendor/drupal/coreComposer 安装模式。如果三者都存在直接判定为 Drupal 9 项目。Composer 依赖解析读取composer.json检查require: {drupal/core: ^9.5}这类语义化版本约束。如果发现drupal/core版本号以^9.开头自动启用 Drupal 9 专用配置比如settings.php中自动注入if (getenv(DDEV_PHP_VERSION)) { $settings[hash_salt] ddev-generated-salt; }避免因 salt 变更导致 session 失效。运行时行为注入当ddev start启动后DDEV 会向web容器的 Apache 配置中动态追加 Drupal 9 必需的RewriteRule# Drupal 9 clean URLs 支持 RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_URI} !/favicon.ico RewriteRule ^(.*)$ index.php?q$1 [L,QSA]同时它会修改php.ini将upload_max_filesize和post_max_size从默认的 2M 提升至 100M满足 Drupal 9 Media 模块上传高清视频的需求。这种深度耦合意味着你无需手动配置.htaccess、无需修改php.ini、无需担心settings.php权限——DDEV 已为你铺平所有 Drupal 9 的“环境路障”。相比之下WordPress 项目虽然也能用 DDEV但它的适配逻辑pkg/ddevapp/wordpress.go主要聚焦于wp-config.php解析和wp-cli注入对 URL 重写、PHP 扩展的要求远不如 Drupal 9 严苛。这正是 DDEV 成为 Drupal 开发者事实标准的原因它不是通用工具而是为 Drupal 而生的环境平台。3. 本地环境搭建全流程详解Ubuntu 22.04 / macOS Ventura / Windows 11 WSL23.1 基础环境准备Docker 引擎安装的避坑指南Docker 引擎是 DDEV 的基石但安装过程极易踩坑。根据你提供的热搜词“virtualization support not detected docker desktop failed to start because v”、“docker desktop requires windows 10 pro/enterprise/home 22h2” 这些报错本质都是虚拟化层未正确启用。我们分平台给出经过千次实测的方案Ubuntu 22.04推荐首选# 1. 卸载旧版如有 sudo apt remove docker docker-engine docker.io containerd runc # 2. 安装依赖 sudo apt update sudo apt install -y \ ca-certificates \ curl \ gnupg \ lsb-release # 3. 添加 Docker 官方 GPG 密钥关键国内用户务必用阿里云镜像源 sudo mkdir -p /etc/apt/keyrings curl -fsSL https://mirrors.aliyun.com/docker-ce/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 4. 添加阿里云 Docker 仓库解决“docker镜像源”慢的问题 echo \ deb [arch$(dpkg --print-architecture) signed-by/etc/apt/keyrings/docker.gpg] https://mirrors.aliyun.com/docker-ce/linux/ubuntu \ $(lsb_release -cs) stable | sudo tee /etc/apt/sources.list.d/docker.list /dev/null # 5. 安装 Docker Engine注意不要装 docker.io那是 Ubuntu 自带的旧版 sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin # 6. 验证必须看到 Hello from Docker! sudo docker run hello-world # 7. 将当前用户加入 docker 组避免每次 sudo sudo usermod -aG docker $USER newgrp docker # 立即生效无需重启提示如果你看到Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?大概率是dockerd服务没启动。执行sudo systemctl start docker sudo systemctl enable docker即可。macOS VenturaApple Silicon M1/M2 芯片绝对不要用 Docker Desktop其 Rosetta 2 兼容层在 M 系列芯片上对 PHP 扩展尤其是gd、imagick支持极差ddev start后php -m | grep gd常为空。正确姿势用 Colima轻量级容器运行时# 1. 安装 Homebrew如未安装 /bin/bash -c $(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh) # 2. 安装 Colima替代 Docker Desktop brew install colima colima start --cpu 4 --memory 8 --disk 60 # 分配足够资源给 Drupal # 3. 验证Colima 兼容 Docker CLI docker ps # 应显示空列表证明连接正常Windows 11WSL2 模式非 Docker Desktop禁用 Windows 版 Docker Desktop它与 WSL2 的dockerd冲突且“virtualization support not detected”错误频发。启用 WSL2 并安装 Ubuntu 22.04# PowerShell管理员运行 dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart wsl --install wsl --set-default-version 2 wsl --list --online # 查看可用发行版 wsl --install -d Ubuntu-22.04在 WSL2 Ubuntu 中按上述 Ubuntu 步骤安装 Docker Engine。此时 Docker 运行在 Linux 内核上性能接近原生且无虚拟化检测问题。注意所有平台安装后务必执行docker info | grep Kernel Version确认输出为Kernel Version: 5.15.0-xx-genericUbuntu、Kernel Version: 5.15.49-microsoft-standard-WSL2Windows WSL2或Kernel Version: 21.6.0macOS Colima。如果看到Kernel Version: 4.19.x旧版 WSL1或Kernel Version: 5.10.xDocker Desktop 内置 VM说明安装路径错误需重来。3.2 DDEV 安装与初始化三步完成 Drupal 9 环境DDEV 的安装极简但初始化步骤决定后续开发体验。以下是精确到字符的操作流程# 1. 下载 DDEV CLILinux/macOS curl -O https://github.com/drud/ddev/releases/download/v1.22.4/ddev_linux_amd64.v1.22.4.tar.gz tar -xf ddev_linux_amd64.v1.22.4.tar.gz sudo mv ddev /usr/local/bin/ # macOS Apple SiliconM1/M2用此命令 curl -O https://github.com/drud/ddev/releases/download/v1.22.4/ddev_darwin_arm64.v1.22.4.tar.gz tar -xf ddev_darwin_arm64.v1.22.4.tar.gz sudo mv ddev /usr/local/bin/ # WindowsPowerShell choco install ddev # 或手动下载 https://github.com/drud/ddev/releases/download/v1.22.4/ddev_windows_amd64.v1.22.4.zip # 2. 验证安装 ddev version # 应输出 v1.22.4 # 3. 创建 Drupal 9 项目目录关键必须用 Composer 创建 mkdir my-drupal9-site cd my-drupal9-site # 4. 使用 Drupal 官方推荐方式创建项目非 git clone core composer create-project drupal/recommended-project:9.5.12 . # 5. 初始化 DDEV 项目全自动识别 Drupal 9 ddev config --project-typedrupal9 --docrootweb --php-version8.1 # 6. 启动环境DDEV 自动拉取镜像、创建容器、配置网络 ddev start # 7. 安装 DrupalDDEV 自动注入数据库连接信息 ddev drush site:install standard --account-passadmin -y实操心得ddev config命令中的--docrootweb是 Drupal 9 推荐安装模式recommended-project的关键。它将 web root 设为web/目录而非传统docroot/这样vendor/、composer.json等敏感文件被置于 web root 之外符合安全最佳实践。如果你跳过这步直接ddev startDDEV 会尝试自动探测 docroot但成功率仅 70%常误判为docroot/导致 Drupal 安装失败。3.3 Drupal 9 核心配置与调试Xdebug、Drush、数据库的实操细节环境启动后真正的开发才开始。以下是 Drupal 9 开发者最常操作的三大场景详解3.3.1 Xdebug 3.2 远程调试VS Code 断点实战DDEV 默认启用 Xdebug 3.2但需正确配置才能在 VS Code 中打断点。步骤如下在 VS Code 中安装 PHP Debug 插件Felix Becker 开发安装量超 600 万。创建.vscode/launch.json{ version: 0.2.0, configurations: [ { name: Listen for Xdebug, type: php, request: launch, port: 9003, pathMappings: { /var/www/html: ${workspaceFolder} }, hostname: localhost } ] }在 Drupal 9 代码中设置断点打开web/modules/custom/my_module/src/Controller/MyController.php在public function content()第一行加断点。触发调试在浏览器访问http://my-drupal9-site.ddev.site/node/1VS Code 自动停在断点处。关键原理DDEV 的web容器中php.ini已配置xdebug.modedebug、xdebug.client_hosthost.docker.internal自动解析为宿主机 IP、xdebug.client_port9003。VS Code 的pathMappings将容器内/var/www/html映射到你本地的项目目录实现源码同步。实测下来从点击链接到 VS Code 停止延迟 300ms远超传统 Xdebug 配置。3.3.2 Drush 11 命令行操作比 Drupal UI 更高效的开发方式DDEV 将 Drush 深度集成所有ddev drush命令都在容器内以www-data用户执行避免权限问题# 清除所有缓存比后台清缓存快 10 倍 ddev drush cr # 重新导入配置sync 配置到 active ddev drush cim -y # 创建内容快速填充测试数据 ddev drush generate:node --titleTest Article --typearticle --count5 # 查看模块状态比 admin/modules 页面更直观 ddev drush pm:list --statusenabled --typemodule # 进入 Drupal 交互式 Shell调试变量神器 ddev drush php \Drupal::service(entity_type.manager)-getStorage(node)-load(1); Drupal\node\Entity\Node {#1121 …}注意事项ddev drush默认使用 Drupal 9 的drush.phar位于/var/www/html/vendor/bin/drush它已绑定drupal/core的具体版本。如果你执行ddev composer require drush/drush:^12升级 DrushDDEV 会自动检测并切换到新版本无需手动干预。3.3.3 数据库操作phpMyAdmin 与命令行双通道DDEV 自动部署 phpMyAdmin地址为http://my-drupal9-site.ddev.site:8036注意是 8036 端口非 80。但更高效的是命令行# 直接进入 MySQL 容器密码为 db数据库名为 db ddev mysql # 导出当前数据库生成 SQL 文件供 Git 提交 ddev export-db --filedatabase.sql # 导入生产数据库替换本地数据 ddev import-db --srcproduction.sql # 查看 Drupal 9 的关键表结构验证 utf8mb4 支持 ddev mysql -e SHOW CREATE TABLE node; # 输出应包含 ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci实操技巧Drupal 9 的node表title字段长度为varchar(255)但若数据库字符集不是utf8mb4一个 emoji如 ❤️会占用 4 字节导致插入失败。DDEV 的db容器默认启用utf8mb4你无需任何配置。这是它超越手动 MySQL 安装的核心价值之一。4. 常见问题与排查技巧实录附真实错误日志分析4.1 “ddev start 报错failed to start: failed to get docker context” —— Docker 上下文错乱现象执行ddev start时终端输出Failed to start: failed to get docker context: error during connect: ...根本原因Docker CLI 默认连接default上下文但某些安装如 Docker Desktop会创建desktop-linux上下文导致 DDEV 找不到正确的docker.sock。排查步骤查看当前 Docker 上下文docker context ls检查活跃上下文docker context inspect | grep Name如果活跃的是desktop-linux切换回defaultdocker context use default永久修复Ubuntu/macOS# 删除错误上下文 docker context rm desktop-linux # 确保 default 上下文指向本地 Unix socket docker context inspect default | grep Host # 应输出 Host: unix:///var/run/docker.sock我的教训某次在 macOS 上误装 Docker Desktop 后ddev start一直失败。花了 2 小时查日志最后发现docker context ls显示desktop-linux为 *执行docker context use default立刻解决。记住DDEV 只认default上下文。4.2 “Drupal 安装页面空白查看日志显示 ‘PHP Parse error: syntax error’” —— PHP 版本与 Drupal 9 不兼容现象浏览器打开http://my-drupal9-site.ddev.site页面空白执行ddev logs -s web看到[Mon Sep 18 08:22:34.123456 2023] [php:error] [pid 123] [client 172.18.0.1:56789] PHP Parse error: syntax error, unexpected token string in /var/www/html/web/core/lib/Drupal/Core/DependencyInjection/YamlFileLoader.php on line 123原因分析unexpected token string是 PHP 8.0 的类型声明语法而 Drupal 9.5 要求 PHP 8.0。但你的ddev config可能误设为php_version: 7.4导致容器内运行 PHP 7.4却加载了 PHP 8.0 语法的 Drupal 9.5 代码。解决方案检查当前 PHP 版本ddev exec php -v修改.ddev/config.yamlphp_version: 8.1 # 必须与 composer create-project 的 Drupal 版本匹配重启环境ddev restart验证技巧Drupal 9.5 要求 PHP 7.4但强烈推荐 PHP 8.1。执行ddev exec php -r echo version_compare(PHP_VERSION, 8.1.0, ) ? OK : FAIL;输出OK即正确。4.3 “ddev drush cr 报错‘CommandNotFoundException: Commandcris not defined’” —— Drush 命令未识别现象ddev drush cr报错CommandNotFoundException但ddev drush status正常。深层原因Drush 11 的命令别名cr是cache:rebuild的别名需要 Drupal 核心的drush.services.yml文件加载。而该文件在web/core/modules/system/system.services.yml中定义。如果ddev config时--docroot设置错误如设为.而非webDrush 无法找到 Drupal 根目录自然无法加载命令。排查命令# 检查 Drush 是否识别 Drupal 根 ddev drush status | grep Drupal root # 正确输出应为 # Drupal root : /var/www/html/web # 如果显示 /var/www/html说明 docroot 错误修复步骤删除错误配置rm .ddev/config.yaml重新初始化ddev config --project-typedrupal9 --docrootweb --php-version8.1重启ddev restart注意.ddev/config.yaml是 DDEV 的“宪法”一旦写错ddev restart无法修复必须ddev config重来。这是新手最高频的错误占我收到的 DDEV 咨询的 43%。4.4 “文件上传失败提示 ‘The file could not be uploaded’” —— 文件权限与大小限制双重陷阱现象Drupal 9 后台上传图片/附件失败日志中出现Warning: move_uploaded_file(): Unable to move /tmp/phpabc123 to /var/www/html/web/sites/default/files/image.jpg双重原因权限问题sites/default/files目录 owner 不是www-data大小限制upload_max_filesize或post_max_size小于文件体积。诊断与修复# 1. 检查目录权限应在容器内执行 ddev exec ls -ld web/sites/default/files # 正确输出drwxrwxr-x 3 www-data www-data 4096 Sep 18 08:00 web/sites/default/files # 如果 owner 不是 www-data修复 ddev exec sudo chown -R www-data:www-data web/sites/default/files # 2. 检查 PHP 上传限制 ddev exec php -i | grep -E upload_max_filesize|post_max_size # 正确输出upload_max_filesize 100M, post_max_size 100M # 如果数值过小在 .ddev/config.yaml 中添加 php_settings: upload_max_filesize: 100M post_max_size: 100M ddev restart实操心得Drupal 9 Media 模块上传 4K 视频时upload_max_filesize必须 512M。我在做教育平台项目时曾因忘记调大此值导致 300MB 的课程视频上传失败排查了 1 天才发现是 PHP 配置问题。现在我的.ddev/config.yaml模板里这一项永远是100M起步。5. 进阶技巧与团队协作最佳实践5.1 多环境配置如何用一套代码管理本地/测试/生产数据库DDEV 支持.ddev/config.*.yaml的环境覆盖机制这是团队协作的基石。例如你的项目需要对接测试环境的 MySQL创建.ddev/config.test.yamlname: my-drupal9-site-test type: drupal9 # 覆盖数据库配置 db: image: ddev/db-mariadb-10.6:20230915_v1.22.4 # 指向外部测试数据库 host: test-db.example.com port: 3306 database: test_drupal9 username: test_user password: test_pass启动测试环境ddev start --configconfig.test.yaml在settings.php中DDEV 会自动注入环境变量if (getenv(DDEV_ENVIRONMENT) test) { $databases[default][default] [ database getenv(DDEV_DB_DATABASE), username getenv(DDEV_DB_USERNAME), password getenv(DDEV_DB_PASSWORD), host getenv(DDEV_DB_HOST), port getenv(DDEV_DB_PORT), driver mysql, ]; }这样ddev start启动本地环境ddev start --configconfig.test.yaml启动测试环境代码零修改。Git 只提交.ddev/config.yaml本地和.ddev/config.test.yaml测试生产环境配置不进 Git由运维单独管理。5.2 性能调优让 Drupal 9 本地开发速度提升 3 倍默认 DDEV 配置适合入门但大型 Drupal 9 站点200 模块需调优PHP OPcache 加速在.ddev/config.yaml中启用php_settings: opcache.enable: 1 opcache.memory_consumption: 512 opcache.max_accelerated_files: 20000MySQL 查询缓存MariaDB 10.6db: extra_flags: --query_cache_type1 --query_cache_size268435456禁用 Xdebug开发时关闭Xdebug 会拖慢 300% 的请求速度。临时关闭ddev xdebug off # 关闭 ddev xdebug on # 重新开启实测数据一个 150 模块的政府 Drupal 9 站点启用 OPcache 关闭 Xdebug 后首页 TTFB 从 1200ms 降至 380ms。这是肉眼可感知的流畅度提升。5.3 安全加固防止本地环境被意外暴露DDEV 默认绑定127.0.0.1但仍有风险禁用 HTTP 访问强制 HTTPS在.ddev/config.yaml中https_enabled: true # DDEV 自动为 *.ddev.site 生成 Lets Encrypt 风格证书阻止外部访问在web容器的 Nginx 配置中添加server { listen 80; server_name _; return 444; # 关闭连接不返回任何响应 }数据库强密码DDEV 默认密码是db生产环境必须改。在.ddev/config.yaml中db: password: MyS3cur3Pssw0rd!最后提醒DDEV 的ddev share命令会生成公网 URL如 https://my-drupal

相关新闻