Long post. Sorry!
Looking for some assistance here; I’m posting in the WordOps forums as I use WO as the front-end for site management on my Ubuntu 24.04 LTS hosting server. I moved from running Windows / IIS as my hosting server some time back, and I’m clearly still lacking something in my understanding of how nginx determines where to direct incoming requests to the appropriate website.
Background: Sites on my server are created using WordOps (wo site create domain.tld). This creates, as we all know, a sites-available file for the domain name under etc/nginx plus, if (as is always the case) it’s going to use https it will create an ssl.conf file under the /var/www/domain.tld/conf/nginx directory.
In the sites-available file there’s a server{} block listing like this:
server {
server_name abbxxx.xxx.au www.abbxxx.xxx.au;
.
.
}
and the ssl.conf looks like this:
listen 443 ssl;
listen [::]:443 ssl;
http2 on;
ssl_certificate /etc/letsencrypt/live/abbxxx.xxx.au/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/abb abbxxx.xxx.au/key.pem;
ssl_trusted_certificate /etc/letsencrypt/live/abbxxx.xxx.au/ca.pem;
ssl_stapling off;
ssl_stapling_verify off;
So far so good. But some of my sites need to accept more than one domain name. So to facilitate this I add a second server{} block that lists the alternate names (plus the www. ) and a rewrite rule to change to the main domain. Here’s an example of this:
server {
server_name dexxx.xxx.au www.dexxx.xxx.au;
.
.
}
server {
server_name moxxx.xxx.au www.moxxx.xxx.au;
rewrite ^/(.*)$ https://www.dexxx.xxx.au/$1 permanent;
}
The ssl.conf is of course the same but pointing to the certificates for dexxx.xxx.au
Now to the issue: I have just been alarmed to find out that traffic for a whole heap of domains is all being directed to the abbxxx.xxx.au site. It was immediately pretty obvious that the traffic was all for the extra domains that have been added to sites on my server; rather than going to the correct site they were going to abbxxx.xxx.au, apparently as it was the first site alphabetically on the server. Google tells me this is apparently a known nginx ‘feature’ where it tries to find a best match for an incoming URL; unlike on IIS where if you don’t match you’d get a 503 service unavailable response. Seems a weird approach to me: nginx doesn’t seem to consider the concept that it will be asked for a site it doesn’t host due to an incorrect DNS entry somewhere?
More digging and I have discovered that the incorrect traffic goes to the right place if you enter the alternate domain name as http:// in the browser; so in my example http://moxxx.xxx.au ends up correctly at https://dexxx.xxx.au . But, and this is why I didn’t spot this earlier, if you specify it as https://moxxx.xxx.au it tries to go to the abbxxx.xxx.au site (and throws a certificate mismatch warning). Not good.
So I thought the obvious answer was to duplicate the server{} block for the alternate names with a listen 443 at the start. However, when I did that for the dexxx.xxx.au site and ran nginx –t it threw warnings:
graham@axxx:/etc/nginx/sites-available$ sudo nginx –t
nginx: [warn] protocol options redefined for 0.0.0.0:443 in /etc/nginx/sites-enabled/dexxx.xxxau:36
nginx: [warn] protocol options redefined for 0.0.0.0:443 in /var/www/dev.randomsite.au/conf/nginx/ssl.conf:1
No idea why the random ssl.conf file was selected; all the sites have an identical ssl.conf other than pointing at the correct certificate location for the site. As it was a warning message I restarted nginx and tried https://moxxx.xxx.au again, but nothing had changed.
So help please; can any of you, from your own experience of setting up sites like this, advise how I get it working correctly for both http & https traffic to redirect to the correct URL? I’ve read all I can find on nginx configuration, but am frankly more confused now than when I started trying to identify what I’m doing wrong. I’ve no issue with modifying .conf files after WO has initially created them, but a concrete example of how to create or edit post creation all the relevant .conf files in this scenario would be much appreciated.
I’m going to cross-post on some nginx forums and will update here if I get an answer in case someone else has the same issue down the track.
Thanks all,
Graham
