This won’t work. At the level you are looking to route the packets, there is no concept of which domain the request was intended for. You need a service that knows how to look at that packet, and forward it appropriately.

What you need to look into is a Reverse Proxy such as haproxy, caddy, or nginx (no specific order). I use haproxy to do something similar, but only on my internal network (with wireguard to access those when I am elsewhere).

Which ever reverse proxy you pick will be responsible for looking at those packets coming into it, and can determine the intended domain to route them appropriately, either through SNI, or more likely by unrwrapping the TLS on the packet.

I’d be careful with doing this, as you are letting whatever outside traffic into your network, so it’s up to you to assess the risk for your use case and make the appropriate mitigations.

I think you can achieve it with a reverse-proxy. Let’s say that domain.com points at server 0, you’ll have to put a reverse proxy that answers all calls. In the config of the reverse proxy you’ll have to redirect the services based on the domain. I’m using Caddy and this example should work:

0.domain.com {
                        reverse_proxy http://X.X.X.X:8080
                      }
1.domain.com {
                        reverse_proxy http://Y.Y.Y.Y:8123
                        } 

And so on.

EDIT: Looks like I was late to the party! +1 to @greco reply as it’s more complete and clear (especially on the risks of this approach)

You can do this with HAProxy already in opnsense. And yes you can route more than just HTTP. (when you are making the Backend rules, switch from Layer 7, to Layer 4. Only thing is that it will do TCP, but not UDP.

As you have posted, port forward cannot tell what the domain even is. (and the url alias is not used the way you are thinking).