18

I currently have a vhost running on Nginx for foo.domain.com and everything works great.

I created a new file for a new sub-domain I want to add called bar.domain.com. I use the same settings for both.

When I restart Nginx I get

Restarting nginx: nginx: [warn] conflicting server name "" on 0.0.0.0:443, ignored nginx.

When I go to bar.domain.com I see what I am supposed to see, but when I go to foo.domain.com I see the page that bar.domain.com links to.

Foo

upstream php-handler {
    server unix:/var/run/php5-fpm.sock;
}

server {
        listen 80;
        server_name foo.domain.com;
        return 301 https://$server_name$request_uri;
}

server {
        listen 443;

        ssl on;
        ssl_certificate      [path_foo]/cacert.pem;
        ssl_certificate_key  [path_foo]/privkey.pem;

        root [path]/foo;

        ...
}

Bar

server {
        listen 80;
        server_name bar.domain.com;
        return 301 https://$server_name$request_uri;
}

server {
        listen 443;

        ssl on;
        ssl_certificate      [path_bar]/cacert.pem;
        ssl_certificate_key  [path_bar]/privkey.pem;

        root [path]/bar;
}

Where am I going wrong?

2
  • You need to specify server_name in SSL (443) config as well.
    – zakjan
    Jul 26, 2015 at 15:14
  • As in after listen 443 on each server add server_name [foo/bar].domain.com?
    – JakeCowton
    Jul 26, 2015 at 15:21

9 Answers 9

12

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;
}
0
4

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

4

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;
1
  • In my case, I had accidentally two separate vhosts with the same server_name; I have had that configuration for years and never worried much about that error message. It turns out that I was erroneously starting a vhost that was supposed just to be a template 😮 Apr 2, 2020 at 22:29
3

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

0

In my case, I couldn't find any duplicate. However, I did have the default.conf where I commented all the config except the opening server block and closing bracket...and this caused the conflicting error.

Basically, it was an unaccounted for server block WITHOUT a server_name directive that caused the issue, not a duplicate one.

0

I had the same issue when using Nginx with AWS Elastic Beanstalk and puma. The issue was because there is a custom ngnix file which extends the default nginx conf and both define "server localhost". Using the correct server name fixed the issue.

0

My case was that I had several subdomains and config for each of them. They had correct server_name in each server. One server specified 80 port, the second did not (was supposed to be 443). While running certbot I saw this nginx warning.

server {
    root /var/www/41/html;
    index index.html;  
    server_name 41.mezinamiridici.cz;   
    location / {
        try_files $uri $uri/ /index.html;
    }

    listen 443 ssl; #this was missing
    ssl_certificate /etc/letsencrypt/live/41.mezinamiridici.cz/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/41.mezinamiridici.cz/privkey.pem; # managed by Certbot
}

server {
    if ($host = 41.mezinamiridici.cz) {
        return 301 https://$host$request_uri;
    } # managed by Certbot
    server_name 41.mezinamiridici.cz;
    listen 80;
    listen [::]:80;
}
0

Another possible reason for this to pop up: Additional server blocks generated by using certbot for getting certificates from Let's Encrypt.

It turned out that every run of certbot added some server blocks to my nginx configuration files, it's entries identifyable by the comment 'managed by certbot'. These additional blocks are handling e.g. http to https redirects. They didn't worry nginx for a while but when I added another server block for a subdomain via /sites-available, these 'conflicting server names' warnings did pop up.

0

At some point on my side, I made a backup of "default" NGINX configuration file. This was the cause of the problem since the backup file was also treated as a configuration file, making it a duplicate. Removing this backed-up file fixed the issue.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.