Nginx virtual hosts that only listen on port 443

OS type and version Ubuntu 20.04.4 LTS x64
Webmin version 1.994
Virtualmin version 7.1
Related packages Nginx Website 2.23, Nginx SSL Website 1.17


Is there a way to instruct Virtualmin to create Nginx virtual hosts that only listen on port 443? Right now this does not seem possible, as if you attempt to create a virtual server and enable the “Nginx SSL Website” feature without enabling the “Nginx Website” feature, an error message pops up saying that an SSL Website cannot be enabled unless a regular one is also enabled.

However, I want all traffic received on port 80 to be redirected to port 443 by default so that SSL is forced across the board on our Nginx server, so I’ve set up a single virtual host block in my /etc/nginx/nginx.conf file that is designed to capture any traffic coming to port 80, regardless of the domain for which that traffic is destined, and perform an HTTP 301 permanent redirect to port 443.

Thus, I only want this single virtual host block to listen on port 80, with everything else, all my real virtual servers, listening only on port 443. As it stands now, whenever I create a new virtual server, I have to manually go in and edit its specific configuration file to remove the listener for port 80 so that, at all times, the only thing listening on port 80 is my custom redirect virtual host.

is there a specific reason why Virtualmin forces a virtual host to listen on both ports 80 and 443, rather than only 443? I would suspect that in today’s age of free SSL certificates (offered by Let’s Encrypt) and Web browsers that ding you if your site is not using HTTPS, Virtualmin would no longer want to actively support or encourage use of port 80 anymore.

I realize that Virtualmin does have the ability to create a per-virtual-host redirect from port 80 to 443, while still having the virtual host listen on port 80, but this is not what I want as I do this centrally now via one virtual host block in the Nginx configuration file, as stated previously, so as to prevent duplicate configuration settings.

Thanks for any insight/assistance provided on this :slight_smile:


Because both ports are still required for web hosting. It is never recommended to run only port 443 even when you intend to redirect from 80 to 443.

Take for example, when Let’s Encrypt attempts a renewal, it does so over port 80…

While I appreciate your reply, I must direct your attention back to my original message, in which I stated that my Nginx installation still listens on port 80, but only has one port 80 listener set up to redirect all requests (regardless of virtual host) to their HTTPS counterpart (via an HTTP 301 redirect).

Thus, Nginx is still listening on port 80, but centrally / globally rather than on a per-virtual-host basis. I am simply wondering why Virtualmin cannot be configured to set its virtual servers to only listen on port 443 for those like myself who have a central configuration of a port 80 listener with redirect logic inside. I don’t see why Virtualmin should require use of port 80 for each virtual host when alternate solutions are available, such as what I have presented in this and my previous message.

You are correct in stating that Nginx should not listen only on port 443 (with no port 80 listener configured), as that would indeed interfere with scenarios like that which you described (regarding Let’s Encrypt), but that is not what I am proposing here.

Not 100% sure what mean. If you don’t have port 80, what happen to the http:// requests unless you use a redirect? Is something not working correctly? It seems your try fix something thats not broken.


As mentioned in my response to the other commenter, please re-read the original message of this thread in order to fully understand what I am getting at here. I also reiterated the central gist of said message in my previous reply. The shortened version is that I want to know if it is or could be possible to relax Virtualmin’s requirement of creating a virtual host that listens on port 80 for times when a central port 80 listener has already been created that intercepts any HTTP request, regardless of destination virtual host, and redirects that request (via an HTTP 301 status code) to HTTPS. In this way, only one virtual host in an Nginx setup listens on port 80 (and redirects all incoming requests on that port); the others, representing domains in Virtualmin, only listen on port 443 so as to not duplicate configuration values. This setup ideally creates a cleaner and more performant Nginx installation.


Fair enough.

Well I guess the best way to answer your question then would be to say…

“There’s more than one way to skin a cat”

*** Though I don’t recommend skinning a cat literally ***

The devs have decided to setup nginx and apache the way they have as it’s the most common approach.

You are entitled to make adjustments, however do so at your own risk. But again changing things can technically be done.

There are templates you could adjust for apache and perhaps for nginx under Virtualmin > Server Settings > Server Templates

1 Like

Wow, you want to relax Virtualmin’s requirements when it creates virtual hosts in order to save a few lines which are duplicated in the config files. Right?

See Virtualmin → Services → Configure Nginx Website

There was confusion in the earlier messages posted by members of the community due to the language that you used: though the grammar and syntax was perfect, you got the jargon wrong. For example, your phrase - only listen on port 443 - indicates the opposite of what you really intend to accomplish.

See Virtualmin → Server Configuration → Website Options

Just enable the option button captioned redirect all requests to ssl website

Simple, isn’t it?


If it were that simple, I would have implemented it already. I’ve been using Virtualmin for ten years now and am extensively familiar with it. On the contrary, what is not simple, it seems, is the ability for others to comprehend my earlier messages. I said that I do not want configuration duplicated, but doing what you suggest would duplicate my configuration. I already have a custom virtual host set up (that is not attached to any Virtualmin virtual server) which listens only on port 80, and redirects any HTTP traffic received on that port to port 443 via an HTTP 301 redirect, as I’ve stated in this thread many times. Turning on the option you suggest would needlessly create another redirect line, this time in a specific virtual host, to do the same thing I already do centrally, thus duplicating configuration.

It’s extremely simple: in 2022, Virtualmin should no longer force a virtual host to live on port 80, as well as optionally port 443; rather, Virtualmin should make the use of port 80 optional so that system administrators like myself can set up our own configuration. Virtualmin is all about being an advanced control panel that allows for tweaking and customization of just about everything to an administrator’s liking, and this should be no different. Performant Nginx configuration dictates that configuration is not duplicated; thus, having one single virtual host listening on port 80 and redirecting any HTTP request to HTTPS negates the need to have any other virtual host, or in Virtualmin’s case to require any other virtual host, to listen on port 80 as well.

Actually, the phrasing I used was exactly what I meant. I do not want any Virtualmin virtual servers to listen on port 80 whatsoever; I want them to only listen on port 443, and thus for Virtualmin to no longer require that a virtual server listen on port 80. As it stands now, and as I mentioned in the original message of this thread, you cannot enable the “Nginx SSL Website” feature (that configures a virtual host to listen on port 443) without also enabling the “Nginx Website” feature (that configures a virtual server to listen on port 80) unless you want to receive an error message.

What I am proposing is that Virtualmin’s code be changed to support an optional port 80 listener for those like myself who have a central listener in an Nginx configuration file that is not tied to any virtual server, and that thus redirects all HTTP requests (regardless of origin) to HTTPS (via an HTTP 301 Moved Permanently response). This negates the need for individual virtual servers to listen on port 80 and ultimately cleans up the Web server configuration files.

So yes, having a Virtualmin virtual server “only listen on port 443” is exactly what I wish to accomplish…

Unfortunately, even if I adjust every template setting available, Virtualmin will still force a virtual host to listen on port 80, which goes against Web server best practices at the least (i.e. having a central listener to redirect to HTTPS in an age where HTTPS is not only preferred, but where certificates are widely available), but also creates duplicate configuration.

It does.

Your problem is that you are doing things OUTSIDE of Virtualmin that would conflict with what Viritualmin provides. That’s not Virtualmin’s issue. It’s yours.

What’s more, you would cause a lot of problems doing that. For example, without port 80, none of your SSL would renew itself. You’d have to go back and reenable it every time a certificate expires.

So much of the internet uses port 80 that to disable it entirely in Virtualmin would mess up far more than it would ever be worth in what you’re doing.

Actually, Virtualmin does not make the use of port. 80 optional. As I’ve said multiple times in this thread, if you attempt to create a virtual server in Virtualmin and enable the “Nginx SSL Website” feature while disabling the “Nginx Website” feature, an error message will appear saying that an Nginx SSL Website cannot be enabled unless an Nginx Website is also enabled. This effectively means that Virtualmin cannot create a virtual server that listens only on port 443, and thus Virtualmin does not make the use of port 80 optional for those who have a centralized port 80 setup.


Are there other panels on the market making use of your model? Curious.

As mentioned, you are entitled to adjust Virtualmin however you choose, but simply saying Virtualmin is doing it wrong just doesn’t belong here.

A suggestion is fine, but as I mentioned there is more than one way to accomplish different tasks. The devs have made their choice, it doesn’t mean you have to like it.

The community and devs are always happy to hear new ideas, and explore them if they are deemed to be appropriate in general, or at this time.

Keep in mind however, just because an option works for you, it doesn’t mean it’ll be the best configuration for others. That’s the tricky part about making a product which intends to meet a wide audience of users, you do your best to make choices that work for the majority of the users.

Unlike some software on the market, you could technically go into the source code (or have someone else do so if despired or required) and adjust virtually any or all parts of the software.

Keep in mind however, upgrades will likely revert certain changes so you’d have to make the adjustments again later if an upgrade changed it back.

Anywho, I’ve spent enough time on this thread. Take care!

1 Like

Please quote the exact words I used in which I said Virtualmin is “doing it wrong,” as you claim. I’ll wait.

What I suspect you’ll find, however, is that I didn’t say such a thing. My initial message in this thread was asking if it was possible to configure Virtualmin not to require use of port 80 when creating a virtual server. Indeed, after my greeting, my message opened with, “Is there a way …”

I was hoping that I would have received input from the Virtualmin developers themselves, and hopefully that may still happen, but regardless I never said that Virtualmin is inherently flawed for how it handles this issue. If anything, Virtualmin should be more flexible, as it is everywhere else in its configuration, or perhaps Virtualmin already has a way to relax its requirement for port 80 virtual hosts, and the developers (unlike the community members) would best be the ones to answer this question.

I do posit that the way Virtualmin currently handles things does not follow system administration best practices in this regard, but ten or fifteen years ago when the control panel was first built and HTTPS was less prevalent, I am sure this was quite acceptable. Times have changed, however. My hope is that either Virtualmin already provides a facility to do what I wish and relax its requirement to always create a port 80 virtual host along with a port 443 virtual host, or if not then perhaps this ability can be implemented by the developers.

There may be other control panels on the market that allow this kind of customization, but as this forum is dedicated to Virtualmin, I’m trying to keep discussion on topic.

I realize in hindsight I probably should have made this a private issue addressed solely to the Virtualmin development team as I had a specific question about Virtualmin’s features and functionality rather than a question seeking general input from the community, and may take this issue private moving forward depending on future responses received. While I appreciate the input from everyone in the community that has so far responded to this thread, I realize now that this post is not really one designed for wider community involvement without input from the Virtualmin development team as well.

@jamie As one who has made code changes to Virtualmin’s functionality in the past to fix issues or suggestions I have raised, do you have any thoughts on this overarching topic?

And if you spent half as much time reading rather than posting you’d see where I said:

Port 80 is used to update a great many things, including your SSL. If you were to disable it, you would essentially wind up having to reenable it every single time your SSL expired. That’s just for starters.

That is why you need to create what you want done yourself. Virtualmin isn’t going to break itself and cause a boatload of issues for your setup. And that is exactly what shutting down port 80 would do: break a LOT of things.

What is the main goal of doing that? What do you expect to happen when a user types and hits enter?

Once again you have failed to properly understand my messages. I did not say I wished to shut down port 80 completely, so that the server does not listen on port 80 at all. Quite the opposite; I said I have a central listener on port 80 in my Nginx configuration file that picks up any traffic received on that port and redirects it to port 443. Having a central listener means that none of my Virtualmin virtual servers need to listen on port 80; they only need to listen on port 443.

Please recuse yourself from further responses to this discussion unless you have completely familiarized yourself with what I have outlined multiple times in my messages.

To reiterate one more time, I have not advocated for, am not advocating for, nor have I ever once mentioned “shutting down” port 80 or otherwise preventing Nginx from listening at all on that port.

Good question. When a user types in the HTTP (i.e. insecure) version of one of my domains into their browser, the central virtual host listening on port 80 will pick up the request and automatically invoke an HTTP 301 Move dPermanently redirect to the HTTPS version of the requested URL. The browser will follow that redirect, and then the virtual host for the appropriate Virtualmin virtual server will pick up the request and transfer it to PHP-FPM via FastCGI, etc. Note that right now, no Virtualmin virtual servers in my setup are listening on port 80; instead, they only listen on port 443. Any HTTPS request coming into the server would be sent to one of them automatically, but any HTTP request would be first picked up by the central port 80 listener. That listener looks like this:

# Catch-all server for HTTP-only requests
server {
	listen 80 default_server;
	listen [::]:80 default_server;
	server_name _;
	return 301 https://$host$request_uri;

You realize that if you run a strict SSL policy then all http request directed at port 80 are automatically bounced to 443, don’t you?

Why you’re trying to reinvent the wheel and make everybody dance around for you is beyond me.