Nom de serveur Nginx en conflit pour le sous-domaine

J'ai actuellement un vhost fonctionnant sur Nginx pour foo.domain.com et tout fonctionne très bien.

J'ai créé un nouveau fichier pour un nouveau sous-domaine que je veux ajouter appelé bar.domain.com. J'utilise les mêmes paramètres pour les deux.

Lorsque je redémarre Nginx, je reçois

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

Quand je vais sur bar.domain.com, je vois ce que je suis censé voir, mais quand je vais sur foo.domain.com, je vois la page vers laquelle bar.domain.com renvoie.

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

Où vais-je mal?

Il me semble que vos blocs https nécessitent également des noms de serveur, par exemple

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

Vous pouvez également avoir des fichiers supplémentaires /etc/nginx/sites-available/<site-name>liés à /etc/nginx/sites-enabled/<site-name>.

Les paramètres de ces fichiers peuvent entrer en conflit avec le /etc/nginx/sites-available/defaultfichier

J'ai eu un problème similaire lorsque j'ai eu accidentellement un nom de serveur en double:

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

Corrigé en le changeant en:

server_name myserver.example.com;

Vérifiez également chaque fichier /etc/nginx/conf.dpour les doublons.

Dans mon cas, nginx -tj'ai réussi les tests - j'ai reçu ce message d'erreur lors de la tentative de démarrage de nginx.

Mes /etc/nginx/sites-enabledfichiers étaient libres doublons de domaine (nom du serveur), et avait seulement 1 référence à server_default(et pas de localhostdoublons)

Au lieu de cela, il y avait 2 fichiers dans conf.dlesquels tous deux faisaient référence à un domaine particulier (c'est-à-dire que 2 fichiers avaient une ligne comme:, servername mydomain.comoù l'un des noms de domaine était répertorié dans 2 fichiers).

Ma solution: assurez-vous donc que tous les fichiers conf.dne référencent qu'une seule servernamefois une valeur particulière (nom de domaine).

( malheureusement, après avoir résolu le problème ci-dessus, je reçois maintenant:
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) des messages d'erreur lorsque j'essaie de redémarrer nginx.)

mise à jour : Pour votre information, re: ... Address already in usemessage d'erreur ci - dessus:
Tout ce que je devais faire était sudo fuser -k 80/tcpalors service nginx restarttravaillé comme un charme!
J'ai trouvé la réponse ici: https://easyengine.io/tutorials/nginx/troubleshooting/emerg-bind-failed-98-address-already-in-use/

update2 :
Il a été suggéré qu'un autre processus utilisait le port 80, (c'est pourquoi le tuer a fonctionné, et il est également logique que b / c nginx ne soit pas en cours d'exécution à l'époque).
https://community.letsencrypt.org/t/nginx-emerg-bind-to-80-failed-98-address-already-in-use/52914/4

Ils soulignent également que voir le processus, avant de le tuer, pourrait donner un aperçu de la cause du problème.
Par conséquent, il est probablement préférable d'utiliser soit: sudo fuser -k 80/tcp(sans l'option -k), suivi d'un greppour ces numéros de processus.
systemctl list-unit-filessortie, peut fournir un aperçu des processus conflictuels

ou:,
fuser -kivn tcp 80où:
-vimprime le nom du processus en plus de l'ID du processus le
-irend rapide avant de tuer
https://community.letsencrypt.org/t/nginx-emerg-bind-to-80-failed-98-address-already- en service / 52914/5

Dans mon cas, je n'ai trouvé aucun doublon. Cependant, j'avais le fichier default.conf où j'ai commenté toute la configuration, sauf le bloc serveur d'ouverture et le crochet de fermeture ... et cela a provoqué l'erreur conflictuelle.

Fondamentalement, c'était un bloc de serveur non comptabilisé SANS directive server_name qui a causé le problème, pas un doublon.