"Blocked loading mixed active content" when using 2 caddy reverse proxies behind each other

Help
1

1. The problem I’m having:

So I am trying to configure my network traffic to go trough a vps. Right now my setup is a follows.:

:house:(local Servers ↔ local SBC(RPI4 with dietpi) running Caddy as a first reverse proxy (no https) to make all my server’s applications accessible on that SBC wich is also a wireguard peer/server):house: <-:lock:-> Wireguard tunnel <-:lock:-> :cloud:(VPS wich is the other wireguard peer/server and is also running caddy as second reverse proxy with https to have access to the public web via port 80 and 443.):cloud:

Now for this example I am running FileRun one a server and I want to serve this via my vps. Without https from my home to the vps and beyond works fine but when I try to serve it via my vps caddy reverse proxy(https enabled), Firefox and edge give me the following errors:

Blocked loading mixed active content...
Blocked loading mixed active content...
Blocked loading mixed active content...

and what follows is that Edge and Firefox doesn’t accept the https connection and only serves its via http while I got a valid certificate.

The weird thing is that when I remove one caddy reverse proxy(the one @myhome) in this line and I reverse proxy from my vps directly to the server’s application via his wireguard ip, everything works like a charm.

I have 1 kind of solution tho and that is to directly connect each server with my vps via wireguard but I want to centralise everything so that all the traffic goes via one gateaway and also so that I don’t have to open multiple ports just for vpn tunnel.

I hope anyone has maybe encountered this before or push me in the right direction?

Thanks in advance.

2. Error messages and/or full log output:

Blocked loading mixed active content...
Blocked loading mixed active content...
Blocked loading mixed active content...

3. Caddy version:

v2.6.4

4. How I installed and ran Caddy:

sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy

a. System environment:

SBC DietPi v8.15.2 RPi 4 Model B (aarch64)
VPS Debian GNU/Linux 11 (bullseye) x86_64

b. Command:

NA

c. Service/unit/compose file:

NA

d. My complete Caddy config:

SBC:

:81 {
        reverse_proxy 192.168.0.75:8080 {
}

VPS:

test.example.xyz {
        reverse_proxy 10.76.8.1:81
}
2

That typically means you have assets on the page trying to load using http:// instead of https://.

That’s not something Caddy can solve, you need to make sure your upstream app is configured to understand that it’s actually being served over HTTPS.

Since you’re proxying one app to another, you should configure the trusted_proxies global option so that proxy headers are correctly preserved from one server to the next. You need to configure this on your “SBC” instance:

3

Francis, I want to thank you a lot for this simple, elegant solution. It did the trick for me and possibly saved me hours of trying to understand what was going on.

Also, for anyone who may encounter this same issue in the future. I used the ip of my WireGuard peer on the VPS.

Thanks again Francis!

1 Like
4

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.