Using caddy to serve both Lan and Public domain


(Avishay Bar) #1

Hi, so basically I have my home hub setup set to listen on port 8123 while I have a subdomain (let’s say abc.example.com) that points to my router public ip address.
So far I have a setup in my caddyfile that serves only the subdomain (abc.example.com { proxy / localhost:8123 }) and it works well.
But when I’m trying to add a configuration for serving 10.0.0.16 (private ip of my devuce) to other lab devices in my network, I cannot access any interface anymore until I revert the configuration.
Do you have an idea how can that be done?


(Gorian) #2

Can you post the configuration (you can sanitize the hostname / IPs if needed)?. I’m running a single caddy instance serving both internal and external sites with no issues.


(Avishay Bar) #3
localhost {
  proxy / localhost:8123
  websocket
  transparent
  header_upstream Host {host}
  header_upstream X-Real-IP {remote}
  header_upstream X-Forwarded-For {remote}
  header_upstream X-Forwarded-Proto {scheme}
}

domain.tld {
  tls email
  log /var/log/access.log {
    rotate_size 50
    rotate_age 90
    rotate_keep 5
  }
  errors /var/log/error.log {
    rotate_size 50
    rotate_age 90
    rotate_keep 5
  }
  header / {
    Strict-Transport-Security "max-age=31536000; includeSubdomains"
    X-XSS-Protection "1; mode=block"
    X-Frame-Options "DENY"
    Referrer-Policy "same-origin"
  }
  proxy / localhost:8123 {
    websocket
    transparent
    header_upstream Host {host}
    header_upstream X-Real-IP {remote}
    header_upstream X-Forwarded-For {remote}
    header_upstream X-Forwarded-Proto {scheme}
  }
}

If I delete the localhost {} section it works, but only on the public domain.


(Gorian) #4

Post your config inside of code blocks, using backticks, like this: `
Much easier to read :slight_smile:


(Avishay Bar) #5

Sorry about that, corrected.


(Gorian) #6

In your second section, you have your proxy directives in a block ( {} ) but in your localhost section you don’t

  proxy / localhost:8123
  websocket
  transparent
  header_upstream Host {host}
  header_upstream X-Real-IP {remote}
  header_upstream X-Forwarded-For {remote}
  header_upstream X-Forwarded-Proto {scheme}

vs

  proxy / localhost:8123 {
    websocket
    transparent
    header_upstream Host {host}
    header_upstream X-Real-IP {remote}
    header_upstream X-Forwarded-For {remote}
    header_upstream X-Forwarded-Proto {scheme}
  }

If these are the same, you can specify multiple hostname for a single definition, like

localhost, domain.tld {
...
}

(Avishay Bar) #7

They are not using the same certificate though… how can I make sure that localhost will not use my domain.tld certificate?


(Gorian) #8

It shouldn’t matter. Caddy should use whatever certificate matches. Now you will run into issues if it can’t get one issued by LE, or one isn’t available, but if one already exists / one can be requested, there won’t be an issue. I have many such config sections, works just fine. I have a wildcard for domain.com and in.domain.com

# Wiki
https://wiki.domain.com, https://wiki.in.domain.com {
    import defaults
    proxy / srv+https://_https._tcp.wiki.in.domain.com {
        import ../templates/proxy-defaults.cf
    }
}

(Avishay Bar) #9

I tried to add localhost, domain.tld.
Still getting the message: “404 Site 10.0.0.x is not served on this interface” when trying to go to 10.0.0.x.


(Gorian) #10

What do you get in your logs?


(Avishay Bar) #11

Nothing regarding those hits. Not in access neither in error logs.


(Matthew Fay) #12

The site label needs to match the requested host.

The requested host, in a modern browser, is based on what you put in the URL bar.

If you type 10.0.0.x in your browser URL bar, your site label in the Caddyfile needs to be 10.0.0.x or Caddy won’t be able to make the association.