gbowe

To any poor soul who finds themselves in the same situation:
There were a couple of keys for me to getting this working as expected.

One: while copying the request headers, my proxy code was changing the Host header to the internal host, and setting X-Forwarded-Host to the original external Host value.
This doesn’t work, as it appears that WordPress uses the Host header value to form links on the admin dashboard and its various redirects, instead of constructing them from the WP_HOME value, for some reason that continues to escape my understanding.
So I removed those two lines from my proxy code, meaning the host header of the internal request had the same value as the external request.
(I believe this is what ProxyPreserveHost does if you’re using apache mod_proxy as your reverse proxy, or if you’re using nginx proxy_pass I think you say proxy_set_header Host $http_host. I imagine this is also why things suggested to set $_SERVER['HTTP_HOST'] to $_SERVER['HTTP_X_FORWARDED_HOST'] in the wp config, but that didn’t correct WordPress’s behavior when I did that, it seemed to be happening after WordPress had already grabbed that value, so ymmv. Probably easier to do it on the proxy’s side than on WP’s.)

Two: it complicated matters that the original external and resulting proxied internal urls differed by more than just the host but had a path, /app/privateblog/{whatever} being just /{whatever} to WordPress. There isn’t really any use of or support for a X-Forwarded-Path header in the proxying world, so having a different path inside than outside is ice skating uphill if you can avoid it…
The easiest way to resolve this while still using the default WordPress image for the container was to just add an Alias in apache to serve the root’s content from the path as well.
So I added a file binding to the volumes of the privatewordpress in my compose yaml:

- /pathonhost/000-default.conf:/etc/apache2/sites-available/000-default.conf

And the contents of /pathonhost/000-default.conf was just copied from what the contents of that file is in the default WP image, with one line added before the closing </VirtualHost> tag:

        Alias '/app/privateblog' '/var/www/html'
</VirtualHost>

And then obviously I added the /app/privateblog path to the end of my configuration setting for what url to send all proxied requests to.

With those changes, at least so far it seems to finally be working as expected.

I’d close this support topic, except that I’d still like to know: why does WordPress use the contents of the Host header to form these redirects and navigation links in the dashboard, instead of the WP_HOME value which it does use to form navigation links in the content?