Possible nginx reverse proxy solution, or something more involved?

I have several websites that I currently host locally and publicly (all secured via 2FA, etc). Currently I'm using multiple ports and would like to use 443 for all of the sites (don't intend on using 80 as I think it's blocked anyway). I'm hosting my own RSS aggregator using Tiny tiny RSS, OpenVPN, NextCloud, as well as one or two others. All sites with the exception of OpenVPN are currently on port 443. OpenVPN, and TT-RSS are running on OMV (OVPN with the plugin, TT-RSS via docker and using docker to present 443 as another port), and Nextcloud is running on a VM on a separate server using yet another port ( I had numerous issues running Nextcloud via Docker so I gave up).

What I would like to do:
Be able to access all systems via one external public URL via port 443 instead of numerous ports. I'd prefer not to use subdomains so I can use a single SSL cert.

Something like:
https://domain.com/nextcloud
https://domain.com/rss
https://domain.com/ or vpn for openvpn
etc

I run my own DNS server via MS Server 2016 internally so internal resolution is not an issue and use zoneedit for external DNS.

I'd like the primary solution to run on the OMV system because I run a script to shut down OpenVPN (and whatever else in the future that will be occupying 443) so I can renew my SSL certs via Letsencrypt/certbot, automatically install the certs into OpenVPN and Nextcloud, then restart OpenVPN once completed.

I think I have what I'm looking for. It looks like in the extra options I would put something like what I have below. My only issue now is to use SSL the cert needs to be loaded in OMV itself, which I'm not doing. In the Letsencrypt plugin it says port 80 needs to be publicly accessible, which I believe is being blocked by my ISP. Currently I'm using letsencrypt via the certbot systemd timer tied with prehook/posthook actions. I don't see a way in the certificates section of OMV to just point to the pem files created by letsencrypt to create an SSL cert that way.

Is it possible to leave SSL disabled in the settings of the plugin but enable them through the extra options and point the ssl cert info to the files like you normally would in the config files?

location / {
       proxy_set_header X-Real-IP  $remote_addr;
       proxy_set_header X-Forwarded-For $remote_addr;
       proxy_set_header Host $host;
       proxy_pass https://xxx.xxx.xxx.2:443;
      }


location /nextcloud/ {
		proxy_headers_hash_max_size 512;
		proxy_headers_hash_bucket_size 64;
		proxy_set_header Host $host;
		proxy_set_header X-Forwarded-Proto $scheme;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
		add_header Front-End-Https on;
               proxy_pass https://xxx.xxx.xxx.5:443;
      }

And I think I figured out my other question. I tested all of it in a VM and so far so good.

listen 443 ssl;
	server_name use the same name used in the plugin;


	client_max_body_size 0;
	underscores_in_headers on;


	ssl on;
	ssl_certificate /location/to/sslcerts/fullchain.pem;
	ssl_certificate_key /location/to/sslcerts/privkey.pem;


	ssl_stapling on;
	ssl_stapling_verify on;

Bah. Doesn't seem to work. No matter what I do OpenVPN seems to want to take over.

Even though it seems I'm the only one interested in getting this working, I figured I'd provide an update. I currently have OpenVPN and Nextcloud working (two different internal servers/IP's entirely) connectable externally via port 443. Found out that in OpenVPN you have to add the port-share setting. Basically you put your webserver on something other than port 443 and in the port-share config setting on OpenVPN (Works in AS to), you put something like port-share 192.x.x.x 8443 where the 192.x.x.x is the IP of the web server and 8443 is the port it's listening on. This must be a port other than 443. OpenVPN then separates the HTTPS traffic from VPN traffic and basically sets up its own proxy. The only problem is I don't believe you can point this to an nginx reverse proxy, but it's better than nothing.

Now that I at least got something I'll continue trying with an nginx reverse proxy but I have a feeling I'm not going to be successful with adding what would basically be a second proxy.