Caddy as a Reverse Proxy to an installation with Wordpress & Caddy does not transfer css content

[pisker (Edgar Piskernik)]

1. The problem I’m having:

I installed Caddy as a Reverse Proxy and use Caddy as server for Wordpress as well (in a proxmox environment).
My Caddy file on the reverse proxy:

shiatsu.example.com {
        reverse_proxy 192.168.178.211 {
        }
}

My Caddy file on the Wordpress installation:

http://shiatsu.example.com {
        root * /var/www/wordpress
        php_fastcgi unix//run/php/php8.2-fpm.sock
        file_server
        encode gzip

        @disallowed {
                path /xmlrpc.php
                path *.sql
                path /wp-content/uploads/*.php
        }
        rewrite @disallowed '/index.php'
}

and I added the requested if ($_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') $_SERVER['HTTPS']='on'; into my Wordpress wp-config.php.
The output is however not following css styles, when I enable https://.

2. Error messages and/or full log output:

Must be an issue of port forwarding not working anymore, as Wordpress sends an 301 response.

3. Caddy version:

v2.6.4

4. How I installed and ran Caddy:

Caddy without https:// is working properly (also presenting the Wordpress content as expected).

a. System environment:

Ubuntu 22.04 LTS on a Proxmox 7.3 Linux Container.

5. Links to relevant resources (i.e. what I investigated)

problems-setting-up-wordpress-with-caddy
no-css-being-loaded-on-backend
reverse-proxy-caddy-wordpress-ssl-docker
v2-reverse-proxy-transparent

[pisker (Edgar Piskernik)]

O.k. after setting $_SERVER['HTTPS']='on'; everything worked, then this post showed me the right direction: caddy-behind-a-reverse-proxy-use-wrong-x-forwarded-proto. So I added after php_fastcgi unix//run/php/php8.2-fpm.sock

        {
                trusted_proxies private_ranges
        }

and my Caddy file looks like this now.

http://shiatsu.example.com {
        root * /var/www/wordpress
        php_fastcgi unix//run/php/php8.2-fpm.sock {
                trusted_proxies private_ranges
        }
        file_server
        encode gzip
        @disallowed {
                path /xmlrpc.php
                path *.sql
                path /wp-content/uploads/*.php
        }
        rewrite @disallowed '/index.php'
}

This solved the issue. It would be nice, if somebody could make a wiki entry out of it (I’m not allowed…)

[francislavoie]

Even better would be to add trusted proxies to your global options instead. Add this at the top of your Caddyfile:

{
    servers {
        trusted_proxies static private_ranges
    }
}

The benefits will be more apparent in v2.7.0, i.e. first-party client IP parsing and logging