容器中WordPress站点无法重定向至子目录问题求助

Hey, I’ve been exactly where you are—spinning up a client’s WordPress site in a container on Ubuntu to add custom features, only to hit those annoying redirect loops to their production domain, even after updating siteurl and home in the database. Let’s walk through the fixes that actually work:

1. Check for wp-config.php Overrides #

First, WordPress lets you hardcode site URLs in wp-config.php, which will completely ignore the database values you set. Jump into your container to check this file:

# If using Docker, exec into the container
docker exec -it your-wordpress-container-name bash

# Navigate to your WordPress root (usually /var/www/html)
cd /var/www/html

# Edit wp-config.php with nano or vi
nano wp-config.php

Add or update these two lines at the top (before the /* That's all, stop editing! */ line), replacing the URLs with your local dev address (including the subdirectory if needed):

define('WP_HOME', 'http://localhost:8080/your-subdirectory');
define('WP_SITEURL', 'http://localhost:8080/your-subdirectory');

Save the file and restart your container if needed—this often fixes the immediate redirect issue.

2. Clean Up Residual Old Domain Entries in the Database #

Updating siteurl and home is just the start. Your database is likely full of hardcoded links to the client’s domain (in posts, post meta, widgets, etc.). Run these SQL queries to replace them (make sure to back up your database first!):

-- Replace old domain with your dev URL
UPDATE wp_posts SET post_content = REPLACE(post_content, 'https://client-production-domain.com', 'http://your-local-dev-url');

-- Update post meta (like featured image URLs, custom fields)
UPDATE wp_postmeta SET meta_value = REPLACE(meta_value, 'https://client-production-domain.com', 'http://your-local-dev-url');

-- Update widget content if needed
UPDATE wp_options SET option_value = REPLACE(option_value, 'https://client-production-domain.com', 'http://your-local-dev-url') WHERE option_name LIKE '%widget%';

Note: Replace wp_ with your actual database table prefix if you changed it during setup.

3. Verify Container/Proxy Configuration for Subdirectories #

If you’re trying to access the site via a subdirectory, your container’s web server (Apache/Nginx) or reverse proxy needs to be configured correctly:

For Nginx (common in Docker setups): #

Make sure your server block points to the subdirectory root and handles PHP correctly:

server {
    listen 80;
    server_name localhost;

    # Point root to your subdirectory
    root /var/www/html/your-subdirectory;
    index index.php index.html;

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

    location ~ \.php$ {
        fastcgi_pass wordpress:9000; # Use your WordPress container name/IP
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;
    }
}

For Docker Compose: #

Double-check your volumes mount to the correct subdirectory in the container:

services:
  wordpress:
    image: wordpress:latest
    volumes:
      - ./your-local-subdirectory:/var/www/html/your-subdirectory
    ports:
      - "8080:80"

4. Clear Browser Cache & Cookies #

Old redirects and cookies from the client’s domain can stick around. Open a private/incognito window to test, or clear your browser’s cache and cookies specifically for the client’s domain.

5. Hunt for Hardcoded Domains in Theme/Plugin Files #

Some themes or plugins hardcode the production domain in their files (like functions.php, custom templates, or plugin configs). Use grep to search the entire WordPress directory:

grep -r "client-production-domain.com" /var/www/html/

Replace any matches you find with your local dev URL.

Content of this question originates from Stack Exchange, question author: cyprian