Using caddy to serve both Lan and Public domain

Help
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?

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.

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.

4

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

1 Like
5

Sorry about that, corrected.

2 Likes
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 {
...
}
7

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

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
    }
}
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.

10

What do you get in your logs?

11

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

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.

1 Like
13

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