Nombre de servidor en conflicto de Nginx para el subdominio

Actualmente tengo un vhost ejecutándose en Nginx para foo.domain.com y todo funciona muy bien.

Creé un nuevo archivo para un nuevo subdominio que quiero agregar llamado bar.domain.com. Yo uso la misma configuración para ambos.

Cuando reinicio Nginx me sale

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

Cuando voy a bar.domain.com, veo lo que se supone que debo ver, pero cuando voy a foo.domain.com, veo la página a la que enlaza bar.domain.com.

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

¿A dónde me estoy yendo mal?

Me parece que sus bloques https también necesitan nombres de servidor especificados, por ejemplo

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

También puede tener archivos adicionales /etc/nginx/sites-available/<site-name>que están vinculados /etc/nginx/sites-enabled/<site-name>.

La configuración de esos archivos puede entrar en conflicto con el /etc/nginx/sites-available/defaultarchivo

Tuve un problema similar cuando accidentalmente tuve un nombre de servidor duplicado:

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

Solucionado cambiándolo a:

server_name myserver.example.com;

También verifique cada archivo en /etc/nginx/conf.dbusca de duplicados.

En mi caso, nginx -tpasé las pruebas: recibí ese mensaje de error al intentar iniciar nginx.

Mis /etc/nginx/sites-enabledarchivos estaban libres de duplicados de dominio (nombre del servidor) y solo tenían 1 referencia server_default(y no localhostduplicados)

En cambio, había 2 archivos en los conf.dque ambos hacían referencia a un dominio particular (es decir, 2 archivos tenían una línea como:, servername mydomain.comdonde uno de los nombres de dominio se enumeraba en 2 archivos).

Mi solución: asegúrese de que todos los archivos conf.dsolo hagan referencia a un valor particular servername(nombre de dominio) una vez, como máximo.

( desafortunadamente, después de solucionar el problema anterior, ahora recibo:
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) mensajes de error cuando intento reiniciar nginx).

actualización : FYI, RE: ... Address already in usemensaje de error anterior:
Todo lo que tenía que hacer era sudo fuser -k 80/tcpentonces service nginx restarttrabajó como un encanto!
Encontré la respuesta aquí: https://easyengine.io/tutorials/nginx/troubleshooting/emerg-bind-failed-98-address-already-in-use/

update2 :
Se ha sugerido que otro proceso estaba usando el puerto 80, (por lo que matarlo funcionó, y también tiene sentido que b / c nginx no se estuviera ejecutando en ese momento).
https://community.letsencrypt.org/t/nginx-emerg-bind-to-80-failed-98-address-already-in-use/52914/4

También señalan que ver el proceso, antes de simplemente matarlo, podría proporcionar información sobre la causa del problema.
Por lo tanto, probablemente sea mejor usar cualquiera: sudo fuser -k 80/tcp(sin la opción -k), seguido de a greppara esos números de proceso.
systemctl list-unit-filessalida, podría proporcionar información sobre procesos conflictivos

o:,
fuser -kivn tcp 80donde:
-vimprime el nombre del proceso, además de la identificación del proceso,
-ilo solicita antes de eliminar
https://community.letsencrypt.org/t/nginx-emerg-bind-to-80-failed-98-address-already- en uso / 52914/5

En mi caso, no pude encontrar ningún duplicado. Sin embargo, tuve el default.conf donde comenté toda la configuración, excepto el bloqueo del servidor de apertura y el corchete de cierre ... y esto causó un error conflictivo.

Básicamente, fue un bloqueo de servidor no contabilizado SIN una directiva nombre_servidor que causó el problema, no una duplicada.