WordPress Docker生产环境部署避坑完整指南

为什么选择Docker而不是宝塔或Lnmp

2026年的WordPress托管已经不只是「装个面板」那么简单了。我用过宝塔、Lnmp、手动编译lnmp，最终切到Docker，原因只有一个：环境一致性。

当你有3台服务器、都要迁移WordPress时，宝塔的版本差异会让你崩溃。而docker-compose up -d一个文件，3台机器跑出完全相同的环境。

但Docker部署WordPress有一系列独特的坑，本文说透7个我实际踩过的。

我的docker-compose.yml配置（2026年最新）

这是我在2026年测试过能正常运行的完整配置，包含Nginx+PHP-FPM+MySQL+Redis：

version: '3.8'

services:
  nginx:
    image: nginx:1.25-alpine
    container_name: wp_nginx
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./wordpress:/var/www/html:ro
      - ./nginx/default.conf:/etc/nginx/conf.d/default.conf:ro
    depends_on:
      - php
    restart: unless-stopped

  php:
    image: php:8.3-fpm-alpine
    container_name: wp_php
    volumes:
      - ./wordpress:/var/www/html
    depends_on:
      - db
    environment:
      - WORDPRESS_DB_HOST=db
      - WORDPRESS_DB_NAME=wordpress
      - WORDPRESS_DB_USER=wp_user
      - WORDPRESS_DB_PASSWORD=your_strong_password
    restart: unless-stopped

  db:
    image: mysql:8.0
    container_name: wp_mysql
    volumes:
      - db_data:/var/lib/mysql
    environment:
      - MYSQL_DATABASE=wordpress
      - MYSQL_USER=wp_user
      - MYSQL_PASSWORD=your_strong_password
      - MYSQL_ROOT_PASSWORD=root_strong_password
    restart: unless-stopped

  redis:
    image: redis:7-alpine
    container_name: wp_redis
    command: redis-server --maxmemory 256mb --maxmemory-policy allkeys-lru
    volumes:
      - redis_data:/data
    restart: unless-stopped

volumes:
  db_data:
  redis_data:

关键版本确认（2026年5月）：

• Nginx: 1.25（alpine轻量版）
• PHP: 8.3-fpm（WordPress官方最低要求PHP 7.4，建议8.0+）
• MySQL: 8.0（WordPress 6.5+推荐）
• Redis: 7（用于对象缓存）

坑1：UID 1000权限问题——插件无法更新的根源

症状：WordPress后台提示「无法写入文件」，插件更新失败，媒体上传报错。

原因：Docker容器内运行的用户通常是www-data(UID 33)或自定义用户，而宿主机挂载卷的文件属于你的用户账号(UID 1000)。两边UID不匹配。

解决方案：在docker-compose.yml中统一PHP容器内用户UID：

php:
  image: php:8.3-fpm-alpine
  user: "1000:1000"  # 匹配宿主机用户
  volumes:
    - ./wordpress:/var/www/html

但这又会造成新问题——如果宿主机是root运行的容器，UID 1000可能不存在。更好的方案是用PGID 1000：

php:
  image: php:8.3-fpm-alpine
  user: "1000:82"  # 1000=你的用户，82=www-data组

**验证方法**：在宿主机运行 ls -ln wordpress/ 确认文件所有权，然后进入容器检查：

docker exec -it wp_php sh -c "id"
# 应该显示 uid=1000 gid=82

坑2：Nginx无法读取WordPress文件——卷挂载路径问题

症状：访问网站显示「File not found」，但容器日志显示PHP-FPM正常运行。

**原因**：官方WordPress镜像把文件放在/var/www/html，但你的宿主机目录挂载到了错误路径。

正确的nginx配置（必须写在nginx/default.conf）：

server {
    listen 80;
    server_name yourdomain.com;
    root /var/www/html;
    index index.php;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        fastcgi_pass php:9000;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2)$ {
        expires max;
        log_not_found off;
    }
}

**注意**：fastcgi_pass php:9000; 中的php是docker-compose服务名，不是localhost。

坑3：MySQL数据持久化失效——volume挂载常见错误

症状：重启容器后数据库清空，所有WordPress内容丢失。

原因：没有正确使用Docker volume，导致数据存在容器可写层（容器删除则数据丢失）。

正确配置（已在上面的docker-compose.yml中展示）：

volumes:
  db_data:  # 命名volume，由Docker管理

# 而不是：
# volumes:
#   - /var/lib/mysql  # 宿主机路径，可能权限问题

验证持久化是否生效：

docker volume ls | grep wp
# 应该看到 wp_db_data

docker inspect wp_mysql | grep -A5 Mounts
# 应该看到 Destination: /var/lib/mysql 类型为 volume

坑4：WordPress无法连接Redis——容器间通信DNS问题

症状：安装了Redis Object Cache插件，但连接失败，网站仍然很慢。

**原因**：WordPress容器内连接Redis时，主机名应该是redis（docker-compose服务名），不是localhost或127.0.0.1。

在wp-config.php中配置Redis：

define('WP_REDIS_HOST', 'redis');
define('WP_REDIS_PORT', '6379');
define('WP_REDIS_TIMEOUT', '2.5');
define('WP_REDIS_READ_TIMEOUT', '2.5');
define('WP_REDIS_DATABASE', '0');

验证Redis是否可达：

docker exec -it wp_php sh -c "nc -zv redis 6379"
# 成功输出：redis (172.x.x.x:6379) open

坑5：WordPress升级后502 Bad Gateway——PHP-FPM进程崩溃

症状：WordPress后台升级主题或插件后，网站立即显示502错误。

原因：PHP-FPM默认进程数配置过低，高并发或插件执行超时时进程全部挂掉。

在docker-compose.yml中调整PHP-FPM配置：

php:
  image: php:8.3-fpm-alpine
  volumes:
    - ./wordpress:/var/www/html
    - ./php/local.ini:/usr/local/etc/php/conf.d/local.ini:ro

php/local.ini配置内容：

memory_limit = 256M
max_execution_time = 300
upload_max_filesize = 64M
post_max_size = 64M

[www]
pm.max_children = 50
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.max_requests = 500

坑6：HTTP协议问题——网站打开是空白页或重定向循环

症状：访问网站后跳转到HTTPS，或者页面空白但无报错。

原因：Docker内Nginx不知道外部是否用了代理/CDN，需要在wp-config.php中强制正确协议。

在wp-config.php中添加：

// 强制HTTP_HOST正确
$_SERVER['HTTP_HOST'] = $_SERVER['HTTP_HOST'] ?? 'yourdomain.com';

// 如果用了反向代理/负载均衡
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Nginx的proxy_headers配置（如果有外部代理）：

proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

坑7：docker-compose down后网站打不开——网络cleanup问题

症状：执行docker-compose down后再up，网站无法访问，但容器看起来都正常运行。

原因：Docker网络被清理但没有正确重建，容器间无法解析彼此的主机名。

解决方案：使用docker-compose down --remove-orphans而不是直接down：

# 停止并清理（推荐）
docker-compose down --remove-orphans

# 完全重启（彻底解决网络问题）
docker-compose down -v  # -v会删除volume，慎用！
docker-compose up -d

日常维护命令：

# 查看所有容器状态
docker-compose ps

# 查看日志
docker-compose logs -f nginx

# 重启单个服务
docker-compose restart php

# 完整重载配置
docker-compose down && docker-compose up -d

总结：Docker部署WordPress的核心原则

1. UID匹配：宿主机用户UID和容器内用户UID必须一致，否则所有文件操作都会遇到权限问题

2. 使用命名volume：MySQL和Redis数据必须用Docker管理的命名volume，不用宿主机路径

3. 服务名即主机名：容器间通信用docker-compose服务名（php、db、redis），不是localhost

4. PHP-FPM配置要主动：默认配置太低，WordPress插件执行时容易崩溃

5. 网络重建用--remove-orphans：避免down/up后网络不通

如果你是第一次用Docker部署WordPress，建议先在本地VM测试完整流程，再迁移到生产服务器。

👉 立即体验：https://platform.minimaxi.com/subscribe/token-plan?code=E5yur9NOub&source=link

📌 This article was AI-assisted generated and human-reviewed | TechPassive — An AI-driven content testing site focused on real tool reviews