Issues with Caddy and Home Assistant [solved]

Hi everyone,

Pardon if this is in the wrong section…

I have a separate linux VM running MQTT broker and Caddy as a reverse proxy for HA (running hassio VM). I’m running into a strange issue the reverse proxy seems to be redirecting to HA. All I get is the top header blue bar and nothing else. I’ve followed the steps in this link Reverse Proxy with Caddy to set up the reverse proxy. Syntax for Caddyfile is a little different as I installed caddy2, but the config per the link is just websocket and transparent mode, which is supposed to be the default for caddy2. I went ahead and added the below config to the Caddyfile to test, but still get this issue.

Here is what I have added to test it, as apparently the transparent keyword adds this to caddy v1, but didn’t work

header_upstream Host {host}
header_upstream X-Real-IP {remote}
header_upstream X-Forwarded-For {remote}
header_upstream X-Forwarded-Port {server_port}
header_upstream X-Forwarded-Proto {scheme}

I’ve tried various things, including removing HTTPS config from the passthrough proxy and HA. Watching the Caddy process (–watch) doesn’t output any errors at all. I’m thinking this may be on some kind of trust issue with HA, but I’ve got the trusted proxy set up, too. At a loss here for a couple of days. HA’s been completely rebooted, proxy has too (for other things)

I’m a network engineer by trade, so tech isn’t foreign, but webservers aren’t exactly my strength :slight_smile:

Before I scrap this and move to nginx, has anyone run into this and can provide a little guidance?
Thanks in advance!

Here is what I get in browser (regular, incognito, etc) no matter what I do (short of removing the reverse proxy config entirely or borking it intentionally)

Here is my current Caddyfile {

root * /usr/share/caddy
} {

reverse_proxy / {
#    transport http {
 #       tls_insecure_skip_verify
  #      tls

   #  }

Current http section of config.yaml as you can see, I removed https for testing purposes

  #ssl_certificate: /ssl/fullchain.pem
  #ssl_key: /ssl/privkey.pem
  use_x_forwarded_for: true

Browsing directly to the IP/port is fine over http (or when enabled, https)

The new version removed the need to even put transparent anymore. This is my working config

(logs_external_https) {
  log {
    output file /var/log/caddy/caddy-https-external.log {
      roll_size 1MiB
      roll_keep 5
      roll_keep_for 168h
    format console
(https_header) {
  header {
    Strict-Transport-Security "max-age=31536000; includeSubdomains"
    X-XSS-Protection "1; mode=block"
    X-Content-Type-Options "nosniff"
    X-Frame-Options "SAMEORIGIN"
    Referrer-Policy "same-origin"
} {
  import https_header
  tls /etc/letsencrypt/live/xxx/fullchain.pem /etc/letsencrypt/live/xxx/privkey.pem {
    alpn http/1.1
  import logs_external_https
  encode gzip

Thanks. yeah I noticed that too. Makes me think it’s some kind of forwarding/permission issue between the HA and Caddy VMs, but they are on the same L2 with no FW in between, which led me down the path of a potential config issue with one or the other. Looking at your config, I modified m ine slightly to match (https in the domain declaration) and added the gzip/header changes you have, but still just the blue bar. The kicker is even just the basic reverse proxy with https disabled still does this same thing.

it’s almost as if HA isn’t trusting the trusted proxies directive in the config file

after tons of trial and error, google searching, etc. My google-fu skills finally found the problem. It has to do with the domain matching differences of v2 and v1. i was matching root (/) adding in a splat to root (/*) solved it, and now it’s working as expected. Hopefully this helps someone else out (my updated caddyv2 file) {
reverse_proxy /* {
  transport http {
1 Like