Adding subdomain pointing to same IP but different port - redirect

Question

I have a domain name registered at ovh.com, let's say it's called domain.com.
This domain is pointing on my router's public IP, then I redirect the https port 443 of my router to my server port 443. So when we go to domain.com it redirects to my server:443.
To be more accurate, domain.com just redirect to my router's public IP. So for example if I use a graphic database manager, I can tell him that the server address is domain.com:[SGBD port] and It will works.
But all my applications are running on this same server. And to add a little more security, I am not using the usual port for all protocols. So let's say my port are the following :
git : 50000
SGBD : 55000
cloud : 60000
website 65000
and some others, for example some TCP ports between 40000 and 50000.
My git and my cloud have a graphical manager I can access by typing domain.com:50000 or domain.com:60000 in my web browser from everywhere. I use the same URL on all my software. domain.com:50000 for my git client, domain.com:55000 for my database client and so on.
This way is working perfectly but there are 2 problems annoying me :
The first one is that I have to tell the port number to everyone who's susceptible to use my applications. But like I said I am not using usual port number for a little more security so I don't want to share these numbers with everyone.
The second problem is more important :
When I am somewhere, for example at work, it's possible that the firewall is blocking the port numbers I am using. So my personal git isn't accessible, same for my cloud etc.
To solve these problem in one move I wanted to add subdomain on my domain and redirect these subdomain to my differents ports. For example :
website : domain.com:65000
git.domain.com ==> domain.com:50000
SGBD.domain.com ==> domain.com:55000
cloud.domain.com ==> domain.com:60000
So in my mind, with this solution I can type git.domain.com in my browser to initiate the communication by https (the https port is almost never blocked), then redirect it to my router's port 50000 from OVH then my router redirect it to the git port of my server.
But obviously this would be to good to be truth.
When creating a subdomain (at least on OVH ?) we can't specify a port. So I can't set git.domain.com is redirecting to myRouterIp:50000 but just to myRouterIp. So with a web browser, typing git.domain.com will redirect to myRouterIp:443, which is already taken by my website.
So i'm a little confused. Do I have to buy one router with a different public IP per application then making all differents subdomain pointing on a different router ? I almost sure it's a bit ridiculous. How do you think I can solve it ?

Answer 1

As you correctly noticed, in your DNS console you can't specify port; the reason is that DNS does not care about ports, its only purpose is to resolve hostnames to IP addresses.
Another thing important for your problem is that most (non http) application clients will, even if they use friendly hostname, resolve that name to IP address before initiating the connection to your router/server, and then use that IP address for communicating to router/server. That means that when request reaches a port on your router/server, there will be no way for router/server to determine which hostname was initially used.
The rare exception to this is HTTP, where the browser is always sending the requested hostname in Host HTTP header. That means that you can run multiple different websites on one IP address on the same port (that is how shared web hosting works, for example). Setting this up should be pretty straightforward, but is probably out of scope on SO, try SF or SU.
For other (non HTTP services), the only solution is to run them on different ports (which you already do), or to have multiple public IP addresses (which might be difficult to get from your ISP). Also, running non-http services on some random non-default ports (and telling that port number to your users) might be (very sightly) more secure than running them on their respective default ports.
Depending on your use case, one other possible solution would be to have your users connect to your local network using secure VPN, and after that they could have access to your services (which would run on different private IP addresses and any port you like).