Right so there’s two things going on here;
The error you’re seeing talks about “mixed active content”, and this means that your page is trying to load HTTP assets on an HTTPS site. You can see that in the URL in the error, in that it has http://
In your first attempt, things worked almost fine, but since the php_fastcgi handler see the incoming request as HTTP, so it passes through http for the REQUEST_SCHEME CGI variable. This means wordpress thinks the site is served over HTTP and not HTTPS, so it puts http:// in front of the asset paths instead of https://.
One possible solution is to override that variable like this:
php_fastcgi unix//run/php/php7.4-fpm.sock {
env REQUEST_SCHEME https
}
If that doesn’t work, you can try with with env HTTPS on, which is another possible variable wordpress might use (I’m not 100% sure on the internals of wordpress).
Another way is to actually use HTTPS between your front Caddy instance and the wordpress-serving one. You can read about how that might look here:
And finally the reason that removing :80 failed was that Caddy will try to enable automatic HTTPS, including HTTP->HTTPS redirects unless you explicitly tell it to serve HTTP (and in this case using :80 which matches the default HTTP port, turns off automatic HTTPS). So when the proxy request comes in, the wordpress Caddy instance always serves redirects. You would need to proxy to wordpress:443 to skip the redirect, but unless you configured trust (see the article above) it would still not be able to complete the TLS handshake.