Selfhosted

Yup. The reverse proxy takes http/https requests from the WAN, and forwards them to the appropriate services on your LAN. It will also do things like automatically maintain TLS certificates, so https requests can be validated. Lastly, it can usually do some basic authentication or group access stuff. This is useful to ensure that only valid users or devices are able to reach services that otherwise don’t support authentication.

So for example, let’s say you have a service called ExampServ running on 192.168.1.50:12345. This port is not forwarded, and the service is not externally available on the WAN without the reverse proxy.

Now you also have your reverse proxy service, listening on 192.168.1.50:80 and 192.168.1.50:443… Port 80 (standard for http requests) and 443 (standard for https requests) are forwarded to it from the WAN. Your reverse proxy is designed to take requests from your various subdomains, ensure they are valid, upgrade them from http to https (if they originated as http), and then forward them to your various services.

So maybe you create a subdomain of exampserv.example.com, with an A-NAME rule to forward to your WAN IPv4 address. So any requests for that subdomain will hit ports 80 (for http) or 443 (for https) on your WAN. These http and https requests will be forwarded to your reverse proxy, because those ports are forwarded. Your reverse proxy takes these requests. It validates them (by upgrading to https if it was originally an http request, verifying that the https request isn’t malformed, that it came from a valid subdomain, prompting the user to enter a username and password if that is configured, etc.)… After validating the request, it forwards the traffic to 192.168.1.50:12345 where your ExampServ service is running.

Now your ExampServ service is available internally via the IP address, and externally via the subdomain. And as far as the ExampServ service is concerned, all of the traffic is LAN, because it’s simply communicating with the reverse proxy that is on the same network. The service’s port is not forwarded directly (which is a security risk in and of itself), it is properly gated behind an authentication wall, and the reverse proxy is ensuring that all requests are valid https requests, with a proper TLS handshake. And (most importantly for your use case), you can have multiple services running on the same device, and each one simply uses a different subdomain in your DNS and reverse proxy rules.