嘿，我之前处理过好几个类似的自定义WordPress Docker部署场景，你的问题大概率是路径映射不准确、配置未持久化，或者服务启动顺序冲突导致的。咱们一步步拆解，彻底解决这个重启后要反复调配置的麻烦：

1. 先把Docker Compose的挂载配置拉到位 #

首先要确保Nginx、PHP-FPM的关键目录都是持久化挂载的，而且容器内的路径完全一致——这是稳定运行的基础。给你一个经过验证的配置模板，你可以对照调整：

version: '3.8'
services:
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      # 把Nginx的站点配置目录挂载到宿主机，修改后不会随容器重启丢失
      - ./nginx/conf.d:/etc/nginx/conf.d
      # WordPress核心目录挂载到容器内的/wp路径
      - ./wp:/var/www/html/wp
      # 独立的wp-content目录单独挂载
      - ./wp-content:/var/www/html/wp-content
    depends_on:
      - php-fpm
    # 确保Docker/电脑重启后容器自动拉起
    restart: always

  php-fpm:
    image: php:8.2-fpm-alpine
    volumes:
      # 和Nginx保持完全一致的路径挂载，避免PHP找不到文件
      - ./wp:/var/www/html/wp
      - ./wp-content:/var/www/html/wp-content
    restart: always

  mysql:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: your_root_password
      MYSQL_DATABASE: wordpress_db
      MYSQL_USER: wp_user
      MYSQL_PASSWORD: wp_user_pass
    volumes:
      # 持久化MySQL数据，避免重启丢失
      - mysql_data:/var/lib/mysql
    restart: always

volumes:
  mysql_data:

这里要划重点：

• 所有服务都加restart: always，杜绝Docker重启后容器不启动的问题
• Nginx的conf.d目录必须挂载到宿主机，不然你每次调整的配置都会随容器销毁丢失
• Nginx和PHP-FPM的wp、wp-content挂载路径必须完全相同，不然PHP-FPM会找不到WordPress的核心文件

2. 修正Nginx配置（最关键的一步！） #

因为你的WordPress在wp子目录，wp-content又独立出来，Nginx的location规则必须同时覆盖这两个目录的静态文件和PHP解析需求。把下面的配置保存到宿主机的./nginx/conf.d/wp.conf里：

server {
    listen 80;
    # 换成你的域名或者localhost
    server_name your-domain.local;

    # 根目录设为wp的上级目录，这样才能同时覆盖wp和wp-content两个子目录
    root /var/www/html;
    index index.php index.html;

    # 处理wp-content的静态文件，直接返回，提升性能
    location /wp-content/ {
        alias /var/www/html/wp-content/;
        expires 30d;
        access_log off;
    }

    # 处理WordPress核心的静态文件和伪静态规则
    location /wp/ {
        alias /var/www/html/wp/;
        try_files $uri $uri/ /wp/index.php?$args;
    }

    # 所有PHP请求转发给PHP-FPM处理
    location ~ \.php$ {
        # 先检查文件是否存在，避免伪静态导致的404错误
        try_files $uri =404;
        # 这里的php-fpm是Docker Compose里的服务名，自动解析容器IP
        fastcgi_pass php-fpm:9000;
        fastcgi_index index.php;
        # 必须准确映射容器内的真实文件路径
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }

    # 可选：把根目录请求直接跳转到wp子目录
    location = / {
        return 301 /wp/;
    }
}

这里的核心注意点：

• 用alias而不是root来处理wp-content目录，因为它和wp目录是平级的，不是子目录关系
• SCRIPT_FILENAME参数必须准确，不然PHP-FPM无法正确解析WordPress的PHP文件
• 伪静态规则try_files要确保wp目录下的所有请求都能正确转发到index.php

3. 解决重启后服务连接失败的问题 #

你之前每次重启都要调配置，可能还有一个原因：Nginx在PHP-FPM完全启动前就加载了配置，导致连接PHP-FPM失败。咱们给Nginx加个启动前的等待脚本，确保PHP-FPM就绪后再启动Nginx：

修改Docker Compose里的Nginx服务，替换command字段：

nginx:
  # ... 其他配置不变
  command: ["/bin/sh", "-c", "while ! nc -z php-fpm 9000; do sleep 1; done; nginx -g 'daemon off;'"]

这个命令会让Nginx启动前先检查PHP-FPM的9000端口是否能连通，直到PHP-FPM完全就绪后再启动Nginx，彻底解决启动顺序导致的连接问题。

4. 验证与测试 #

做完上面的修改后，执行以下命令重启服务：

# 先停止并删除旧容器
docker-compose down
# 后台启动服务
docker-compose up -d

然后做这几个验证：

1. 访问http://localhost/wp，确认WordPress能正常加载
2. 重启Docker或者你的电脑，再次访问站点，确认不需要调整配置就能正常运行
3. 查看容器日志，确认没有报错：

docker-compose logs nginx
docker-compose logs php-fpm

如果日志里没有出现“connection refused”或者“file not found”的错误，说明配置已经稳定了。

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