acme-companion | Automated ACME SSL certificate generation for nginx-proxy | TLS library

What you want is not possible, but you probably don't actually want it. It becomes clear once you think through what you want to configure, and what would happen if a user would go to either URL:

• you have configured example-a.com to point to your IP
• you have configured example-b.com to point to your IP
• you have configured your nginx-proxy container to listen on ports 80 and 443
• you want to configure your WordPress containers to both listen on port 2999
• you, or rather the acme-companion, have configured your nginx container to forward HTTP requests that ask for host example-a.com to go to the container for example A with port 2999, and requests that ask for example-b.com to go to container B with port 2999

Now, you can see right away that you have two things attempting to listen on the same network interface with port 2999 - that doesn't work, and it can't, because who would handle picking up incoming requests before the request is parsed to find out which host it wanted ? Container A can't accept the request and, if it's meant for B, hand the request over - A doesn't know about B.

So if you think about a user sending a request to example-a.com:2999, what really happens is that a request goes to :2999, just like if a user goes to example-b.com:2999, it will end up going to :2999.

How can that problem be solved ? By having a third container C that accepts user requests, looks into the request, and based on whether they wanted container A or B, hands the request over to A or B.

Here is the great thing: you already have that! Container C is really your nginx container, which is listening on port 80/443. So if your users go to example-a.com without providing a port, it will go to 80 or 443 (depending on whether they used http or https). Then, nginx will analyze the request, and send it to the correct container. For this, it doesn't really matter what port A and B listen on, because to the outside world, it looks like they are listening on 80/443.

So the real answer is that while you can't combine custom ports with virtual hosts and use the same port for multiple containers (other than 80/443), you don't actually NEED custom ports in the first place! If you just configure your containers with the default ports, users can use both https://example-a.com and https://example-b.com and it will 'just work'™