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