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?
                    
                        nginx
                                ssl
                                virtualhost
                                
                    
                    
                        RockJake28
fuente
                
                fuente

server_nameen la configuración SSL (443).listen 443en cada servidor agregarserver_name [foo/bar].domain.com?Respuestas:
Me parece que sus bloques https también necesitan nombres de servidor especificados, por ejemplo
fuente
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/defaultarchivofuente
Tuve un problema similar cuando accidentalmente tuve un nombre de servidor duplicado:
Solucionado cambiándolo a:
fuente
server_name; He tenido esa configuración durante años y nunca me preocupé mucho por ese mensaje de error. Resulta que estaba iniciando erróneamente un vhost que se suponía que era solo una plantilla 😮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 referenciaserver_default(y nolocalhostduplicados)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 particularservername(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/tcpentoncesservice 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 agreppara esos números de proceso.systemctl list-unit-filessalida, podría proporcionar información sobre procesos conflictivoso:,
fuser -kivn tcp 80donde:-vimprime el nombre del proceso, además de la identificación del proceso,-ilo solicita antes de eliminarhttps://community.letsencrypt.org/t/nginx-emerg-bind-to-80-failed-98-address-already- en uso / 52914/5
fuente
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.
fuente