Nome del server in conflitto Nginx per il sottodominio

Al momento ho un vhost in esecuzione su Nginx per foo.domain.com e tutto funziona alla grande.

Ho creato un nuovo file per un nuovo sottodominio che voglio aggiungere chiamato bar.domain.com. Uso le stesse impostazioni per entrambi.

Quando riavvio Nginx ottengo

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

Quando vado a bar.domain.com vedo quello che dovrei vedere, ma quando vado a foo.domain.com vedo la pagina a cui si collega 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;
}

Dove sto sbagliando?

Mi sembra che i tuoi blocchi https richiedano anche nomi di server specifici, ad es

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

Potresti anche avere file aggiuntivi a /etc/nginx/sites-available/<site-name>cui sono collegati /etc/nginx/sites-enabled/<site-name>.

Le impostazioni in tali file potrebbero essere in conflitto con il /etc/nginx/sites-available/defaultfile

Ho avuto un problema simile quando ho accidentalmente duplicato il nome del server:

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

Risolto modificandolo in:

server_name myserver.example.com;

Controlla anche ogni file /etc/nginx/conf.dper duplicati.

Nel mio caso, nginx -tho superato i test: ho ricevuto quel messaggio di errore quando ho tentato di avviare nginx.

I miei /etc/nginx/sites-enabledfile erano liberi da duplicati di dominio (nome server) e avevano solo 1 riferimento a server_default(e nessun localhostduplicato)

Invece, c'erano 2 file in conf.dcui entrambi facevano riferimento a un determinato dominio (cioè 2 file avevano una linea come:, servername mydomain.comdove uno dei nomi di dominio era elencato in 2 file).

La mia soluzione: assicurati quindi che tutti i file conf.dfacciano riferimento al servernamevalore (nome di dominio) solo una volta, al massimo.

( sfortunatamente dopo aver risolto il problema sopra, ora ottengo:
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) messaggi di errore quando provo a riavviare nginx.)

aggiornamento : Cordiali saluti, ri: ... Address already in usemessaggio di errore sopra:
Tutto quello che dovevo fare era sudo fuser -k 80/tcpquindi service nginx restartfunzionare come un incantesimo!
Ho trovato la risposta qui: https://easyengine.io/tutorials/nginx/tro troubleshooting / emerg - bind - failed - 98 - address - already-in - use/

update2 :
è stato suggerito che un altro processo stava usando la porta 80, (motivo per cui uccidere ha funzionato, e ha anche senso che b / c nginx non fosse in esecuzione al momento).
https://community.letsencrypt.org/t/nginx-emerg-bind-to-80-failed-98-address-already-in-use/52914/4

Sottolineano inoltre che vedere il processo, prima di ucciderlo, potrebbe fornire informazioni su ciò che ha causato il problema.
Quindi, probabilmente è meglio usare uno dei due: sudo fuser -k 80/tcp(senza l'opzione -k), seguito da a grepper quei numeri di processo.
systemctl list-unit-filesoutput, potrebbe fornire informazioni dettagliate sul processo in conflitto

oppure:,
fuser -kivn tcp 80dove:
-vstampa il nome del processo oltre all'ID del processo
-iche lo richiede prima di uccidere
https://community.letsencrypt.org/t/nginx-emerg-bind-to-80-failed-98-address-already- in uso / 52914/5

Nel mio caso, non sono riuscito a trovare duplicati. Tuttavia, avevo il default.conf in cui ho commentato tutta la configurazione tranne il blocco del server di apertura e la parentesi di chiusura ... e questo ha causato l'errore in conflitto.

Fondamentalmente, era un blocco non contabilizzato per il blocco server SENZA una direttiva nome_server che ha causato il problema, non duplicato.