upvote
Also recommending using a DNS server that points `*.yourdomain` do your reverse proxy's IP. That way requests skip going outside your network and helps for ISPs that don't work with "loopback" DNS (quotes because I don't know the proper term)

You can then set your DNS in Tailscale to that machines tailnet IP and access your servers when away without having to open any ports.

And bonus, if it's pihole for dns you now get network-level Adblock both in and outside the home.

reply
Personally I'm using haproxy for this purpose, with Lego to generate wildcard SSL certs using DNS validation on a public domain, then running coredns configured in the tailnet DNS resolvers to serve A records for internal names on a subdomain of the public one.

I've found this to work quite well, and the SSL whilst somewhat meaningless from a security pov since the traffic was already encrypted by wire guard, makes the web browser happy so still worthwhile.

reply
This worked for me to get subdomains and TLS certificates working on a similar setup: https://blog.mni.li/posts/internal-tls-with-caddy/
reply
IME androids dont respect static routes published by the router. I guess self hosting DNS might be more robust but I usually just settle for bookmarking the ip:port
reply
This (reverse proxy) is essentially what "tailscale serve" does.
reply
Or just use Tailscale serve to put the app on a subdomain
reply
Caddy is increasingly popular these days too. I use both and cannot decide which I prefer.
reply
Caddy's configuration is so simple and straightforward, I love it. For sure a more comfortable experience for simple setups
reply
I like Caddy's integration with Cloudflare for handling SSL and when I originally saw the idea it was promoted as an easy way to have SSL for a homely but I don't use real domains for my internal apps and that is required with Cloudflare.
reply
caddy has tailscale integration i think too, so your foo.bar.ts.net “just works”
reply
The pain I've had with it is distributed configuration, i.e. multiple projects that want to config rules. I've been using the JSON API rather than their DSL.

Do you know how I might approach this better?

reply
I think most homelabbers default to Caddy and/or Traefik these days. Nginx is still around with projects like NPM (the other NPM), but Caddy and Traefik are far more capable.

DevOpsToolbox did a great video on many of the reasons why Caddy is so great (including performance) [0]. I think the only downside with Caddy right now is still how plugins work. Beyond that, however it's either Caddy or Traefik depending on my use case. Traefik is so easy to plug in and forget about and Caddy just has a ton of flexibility and ease of setup for quick solutions.

[0] https://www.youtube.com/watch?v=Inu5VhrO1rE

reply
far more capable is an exaggeration

I use both, they are by and large substitutable. Nginx has a much larger knowledge base and ecosystem, the main reason I stick with it.

reply
Just as one small example: if you're deploying in k8s and want the configuration external to Nginx, you want built in certificate provisioning and you need to run midleware that can easily be routed in-config...

Traefik is far more capable, for example. If all you're doing is serving pages, sure.

reply
I agree with you that they're more or less equal. I don't like the idea of my reverse proxy dealing with letsencrypt for me, personally, but that's just a preference.

One tricky thing about nginx though, from the "If is evil" nginx wiki [0]:

> The if directive is part of the rewrite module which evaluates instructions imperatively. On the other hand, NGINX configuration in general is declarative. At some point due to user demand, an attempt was made to enable some non-rewrite directives inside if, and this led to the situation we have now.

I use nginx for homelab things because my use-cases are simple, but I've run into issues at work with nginx in the past because of the above.

[0] https://nginx-wiki.getpagespeed.com/config/if-is-evil

reply
I'm not sure why Apache is so unpopular, it can also function as a reverse proxy and doesn't have the weird configuration issues nginx has.

Some people take this way too far, for instance I've send places compiling (end of life) modsec support into nginx instead of using the webserver it was built for

reply
The part you are leaving out is that you also need to set up something like a pihole (which you can just run in a container on the homelab rather than on a pi) to do the local DNS resolution.
reply