Nginx conflicting server name for subdomain

Question

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?

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

score 13 · Accepted Answer · edited Jul 26 '15 at 16:21

13

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

edited Jul 26 '15 at 16:21

sebix

4,313
2
29
47

answered Jul 26 '15 at 15:24

Lloyd Wilson

146
1
2

score 4 · Answer 2 · answered Dec 23 '15 at 10:39

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

answered Dec 23 '15 at 10:39

hanxue

1,377
2
11
12

score 4 · Answer 3 · answered May 08 '16 at 14:11

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;

answered May 08 '16 at 14:11

Steve Tauber

141
3

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 – Gwyneth Llewelyn Apr 02 '20 at 22:29

SherylHohman · Answer 4 · 2018-11-13T22:14:32.260

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

score 1 · Answer 5 · answered Feb 14 '21 at 15:09

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.

score 0 · Answer 6 · answered Nov 28 '20 at 21:37

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.

answered Nov 28 '20 at 21:37

Peter T.

101
1

score 0 · Answer 7 · answered Dec 31 '20 at 09:14

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

score 0 · Answer 8 · answered Sep 26 '21 at 23:17

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.

answered Sep 26 '21 at 23:17

Libby Lebyane

1
1

score 0 · Answer 9 · answered May 05 '19 at 18:44

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.

Nginx conflicting server name for subdomain

9 Answers9

Linked