In my NGINX configuration, a WordPress blog is on a private server. My NGINX public server proxies the private server’s content for https://www.example.com/blog/.
location ^~ /blog/ { # A "subdirectory", hiding a proxied server
proxy_pass http://192.168.0.5:80/; # The blog resides in the
# private's web root,
# not in a subdirectory
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_redirect off;
}
The blog is perfectly rendered on calling the domain and subdirectory. Bringing up wp-login does not generate a redirect GET field.
https://www.example.com/blog/wp-login.php
My siteurl and my home variables are both set to the domain with subdirectory.
However, after a successful login, I may see the dashboard, but the URL in my browser gets rewritten to https://www.example.com/wp-admin, causing problems on using the dashboard.
How do I configure WP to rewrite the URL to the subdirectory, although the blog is on a proxied private server?
(Do the subdirectories in the servers have to be symmetrical?)
I have also met with same problem,
I found a workaround, to fix the issue, add below code to wp-config.php
WordPress uses two variables to define where it is hosted:
WP_HOME
andWP_SITEURL
. Both can be set using the dashboard, but I prefer to set them inwp-config.php
:It is usual to set an absolute URL (as above) which includes scheme and host name, but I prefer to use a relative URL when operating behind a reverse-proxy, like this:
You can probably continue to run WordPress in the root of your private server (assuming it isn’t accessed directly). Moving the private server down one level is a little more complicated and involves the web server configuration on both servers to be changed a little.
You have to add the following two rewrites to your wp-config.php:
The first one fixes all admin pages. The second one you need for the password reset flow.
I found an open TRAC issue for the password reset flow from 4 years ago, so it seems we’ll have to continue doing these workarounds for the foreseeable future. It doesn’t seem like running behind a reverse proxy is something WordPress expects most people to do.