Arch Linux

eom.dev

Member

Registered: 2022-02-11

Posts: 57

Wordpress behind an Apache HTTP proxy

I am installing wordpress on a network with several webservers.  They are accessed by subdomain over the public internet via an Apache reverse proxy.  Here is the relevant config:

<VirtualHost *:443>
  ServerName wordpress.example.com
  ProxyPass / http://wordpress.local.net/
  ProxyPassReverse / http://wordpress.local.net/
  ProxyPreserveHost On
  SSLCertificateFile /etc/letsencrypt/live/api.eom.dev/fullchain.pem 
  SSLCertificateKeyFile /etc/letsencrypt/live/api.eom.dev/privkey.pem
  Include /etc/letsencrypt/options-ssl-apache.conf
</VirtualHost>

When I access wordpress via http://wordpress.local.net/, I am able to see styles; however, when I access via https://wordpress.example.com, there is no styling. 

Things I've Tried

Editing the values of siteurl and home in the database with the following values:

• https://wordpress.example.com

• http://wordpress.local.net

• The local IP address

• /

Editing the proxy config with the following variations:

• With and without ProxyPreserveHost On

• Using the local IP for ProxyPass and ProxyPassReverse

• Editing the hosts file to map the local IP address to wordpress.eom.dev and using that url for ProxyPass and ProxyPassReverse

Not sure which further details are useful, but I would appreciate some help getting WordPress to display styles when accessed via an Apache reverse proxy.

twelveeighty

Member

Registered: 2011-09-04

Posts: 1,453

Re: Wordpress behind an Apache HTTP proxy

Unless you are the owner of the 'example.com' domain, trying to access https://<anything>.example.com will be a lot of DNS and TLS cert configuration to get to work and you will not 'trick' LetsEncrypt to give you a valid certificate for that, so you'll have to use self-signed certs, which only work properly in a controlled environment, not through the Internet.

If we assume for the moment you are using a domain you own, then post the full errors you get when you try to access the target; for example, use curl -v <URL> in a console. The issue could be DNS, the cert or the proxy, each of which will return different errors. Also observe the Apache access and error logs when you make the request and post those.