Local domain name reverse proxy

Help
1

Hi,

just a quick question. How does Caddy decide which domain names are local? I’m using .private on my lan, but when I try to use it for a reverse proxy Caddy is trying to get a certificate from letsencrypt.

Thanks

2

Good question (we don’t go into a lot of detail in the docs, it just says IP addresses and local/internal hostnames which is at least slightly ambiguous) – but right now it’s just localhost, or domains that end in .localhost or .local. This set may grow over time.

You can always configure the internal issuer for any hostname, however. (Caddyfile equivalent: tls internal or global option of local_certs)

1 Like
3

Ah well that’s easy enough then. Should have checked the directives as you told me on Reddit :wink:

What if I want to just serve the site over http? I found tls off in the v1 documentation. Same in v2?

4

No, just specify port 80 or http:// in the site address.

See Automatic HTTPS — Caddy Documentation

5

Ok got it. All working well so far.Thanks for the help!
Would be great if you could still clarify a few things. My Caddy file looks like this:

jellyfin.domain.duckdns.org {
	reverse_proxy 192.168.2.2:8096
}

sonarr.private:80 {
	reverse_proxy 192.168.2.2:8989
}

jellyfin.private:80 {
	reverse_proxy 192.168.2.2:8096
}
  1. Is it redundant to include the local domain reverse proxy for Jellyfin? I’m not sure how the data routing works when I’m accessing Jellyfin through DuckDNS being on the local network.
  2. Anything I can add to increase security on the public accessible reverse proxy or is this ?
    3.Is there any advantage using base url in Jellyfin/Sonarr etc. The way I’m doing it now is adding more lines, but as a side effect I’m also getting the correct favicon per site in my browser (main reason why I’m doing it on the local network).
  3. Is there any performance impact using the local reverse proxies compared to ip+port?

Again thanks for your patience!

6

You could probably combine them? Caddy will then answer to either hostname with the same site config. It’s a minor change, save a few lines.

jellyfin.domain.duckdns.org, jellyfin.private:80 {
	reverse_proxy 192.168.2.2:8096
}

Nothing generic and useful I can think of, unless you’ve got some kind of specific threat you want to guard against.

You’d have to do a number of lines anyway (reverse proxies for each upstream, based on each base path). Doing it on different hostnames does keep things conceptually quite neat, and being in the habit of it means you aren’t hamstrung when some app isn’t specifically programmed to accommodate base URLs.

You are doubling the network overhead, but this is likely to be so minuscule as to be insignificant compared to the benefit of being able to access your apps on a user friendly URL.

7

Thanks for the details!

Looks more neat. I’ll take it :wink:

But also meaning I should use jellyfin.private and not the duckdns one when I’m connecting on the remote network, correct?

That’s what I thought. Just had me wondering, because it seems like most people are using subdirectories and not subdomains, hence the support for base URL. Doesn’t seem like it’s that much less work to do, so I thought there might be some benefit I’m not seeing.

8

Ok, I actually just ran into a limitation. Seems like there is a maximum number of hostnames I can assign to the same ip address using dnsmasq. Couldn’t find anything about that though.

9

Wow, really?

I’ve never read about such a limitation of dnsmasq. That sounds crazy to me.

How would it even know or care to check how many domains are pointed at the same IP?

Very strange.

10

Yeah maybe was just a hiccup by the router. Had to actually restart it, because changing host names didn’t work anymore. Will try again.

edit: never mind. Flushing DNS cache solved the problem.

11

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