Nginx conflicting server name for subdomain

Solution 1:

Looks to me like your https blocks need server names specified too e.g

server {
    listen 443;
    server_name bar.domain.com;
    ssl on;
    ssl_certificate      [path_bar]/cacert.pem;
    ssl_certificate_key  [path_bar]/privkey.pem;

    root [path]/bar;
}

Solution 2:

You may also have additional files in /etc/nginx/sites-available/<site-name> that are linked to /etc/nginx/sites-enabled/<site-name>.

The settings in those files may conflict with the /etc/nginx/sites-available/default file


Solution 3:

I had a similar issue when I accidentally had duplicate server name:

server_name myserver.example.com myserver.example.com;

Fixed by changing it to :

server_name myserver.example.com;

Solution 4:

Also check each file in /etc/nginx/conf.d for duplicates.

In my case, nginx -t passed tests - I got that error message when attempting to start nginx.

My /etc/nginx/sites-enabled files were free from domain (server name) duplicates, and had only 1 reference to server_default (and no localhost duplicates)

Instead, there were 2 files in conf.d that both referenced a particular domain (ie 2 files had a line like: servername mydomain.com, where one of the domain names were listed in 2 files).

My solution: So be sure all files in conf.d only reference any particular servername (domain name) value once, at most.


(unfortunately after fixing the above issue, I now get:
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) error messages when I try to restart nginx.)

update: FYI, re: ...Address already in use error message above:
All I had to do was sudo fuser -k 80/tcp then service nginx restart worked like a charm!
I found the answer here: https://easyengine.io/tutorials/nginx/troubleshooting/emerg-bind-failed-98-address-already-in-use/

update2:
It's been suggested that another process was using port 80, (which is why killing it worked, and also makes sense b/c nginx was not running at the time).
https://community.letsencrypt.org/t/nginx-emerg-bind-to-80-failed-98-address-already-in-use/52914/4

They also point out that seeing the process, before just killing it, might provide insight on what caused the issue.
Hence, it's probably better to use either: sudo fuser -k 80/tcp (without the -k option), followed by a grep for those process numbers.
systemctl list-unit-files output, might provide insight on conflicting process

or:
fuser -kivn tcp 80, where:
-v prints the process name in addition to the process id
-i makes it prompt before killing
https://community.letsencrypt.org/t/nginx-emerg-bind-to-80-failed-98-address-already-in-use/52914/5