Not positive, but I think you left in a reference to real info (twilightparadox.com) instead of “example-fying” it (mydomain.com), in the paragraph just before section 4:

For example say I have home-assistant running on a Pi with the local address 192.168.0.11, I could create a subdomain named ha that has the value mysub.twilightparadox.com then create the following nginx config

server{
	listen 80;
	server_name ha.mydomain.com;
	resolver 192.168.0.1;
	location / {
		proxy_pass http://192.168.0.11/;
	}
}

When nginx sees a request for ha.mydomain.com it passes it to the address 192.168.0.11 port 80.

You seem to have descibed your port forwards backwards It is the router forwarding the ports to the gateway pi (and potentially other devices), not gateway pi and other devices forwarding to the router. The forwards to servers are incoming from the internet.

(Theoretically you could have your pi physically between the router and the internet (modem) acting as a sort of pre-router, but this would be unusual. Perhaps you could describe your physical setup more clearly. What is physically/wirelessly connected to what, to the internet.)

@JackDavies nice, thanks for sharing. This looks a lot like the setup I used to have until I decided I was not comfortable (nor experienced enough) having my Pi (and my whole network) exposed to the internet.

A few tips/recommendations I can share from my experience:

Namecheap includes free dynamic DNS hosting with all their domains, which means you can have your own domain and this reduces the chances of your sites being blocked due to others abusing free dynamic DNS services. You can get a cheap $2/year domain instead.

For an even smoother TLS certificate experience, you can use Caddy, which is as easy to configure and run as Nginx, with the added benefit of automatic TLS certificate management.

I know many people are not happy with Cloudflare, but their Zero Trust tunnel service is amazingly easy to use and covers 99% of use cases (I made up that number). Instead of exposing your entire network, you just make an outbound connection by running the cloudflared daemon inside your network and then create the subdomains by creating “apps.” No port exposing or routing.

As for the post itself, I would only recommend replacing your `mydomain.com` examples with one of the official domains used for technical documentation: `example.com`, `example.org`, or `example.net`. These cannot be registered by anyone, which means you are not creating links to potentially dangerous sites.

Good luck with your #selfhosting adventures!

Oh excellent, thanks for sharing.

nice job

.

Very cool, great work!

Worth noting about this approach is that the global list of subdomains is publicly searchable. So, you’ll see vulnerability and AI scans on those endpoints.

If that’s a concern for you, using path-based routing (e.g. Apache VirtualHost) allows you to use difficult to guess paths to your cloud.

Oh I thought it was sub domains for localhost. I actually wonder now if that’s possible.

I personally use caddy as a reverse proxy

I am once again recommending that you not expose any services to the internet except a VPN

Thanks for sharing!

I can recommend nginx-proxy-manager for people who do not want to fiddle with proxy config files.

I did similar with caddy. I own a domain and my server runs pihole and it is configured as DNS server. So what I did was setup caddy to create local subdomains that are only reachable through my network. For example: subdomain.mydomain.com , that works only from home. It works with ssl as well