web-dev-qa-db-fra.com

Nom de serveur en conflit Nginx 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ù est-ce que je vais mal?

nginxsslvirtualhost
14
RockJake28

Il me semble que vos blocs https ont également besoin de noms de serveur spécifiés, 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;
}
9
Lloyd Wilson

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;
3
Steve Tauber

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

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

3
hanxue

Vérifiez également chaque fichier dans /etc/nginx/conf.d Pour les doublons.

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

Mes fichiers /etc/nginx/sites-enabled Étaient exempts de doublons de domaine (nom de serveur) et n'avaient que 1 référence à server_default (Et pas de doublons localhost)

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

Ma solution: Assurez-vous donc que tous les fichiers de conf.d Ne font référence à une valeur particulière de servername (nom de domaine) qu'une seule fois, au plus.

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

mise à jour : FYI, re: ... Address already in use message d'erreur ci-dessus:
Tout ce que j'avais à faire était Sudo fuser -k 80/tcp Puis service nginx restart Fonctionnait 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 était 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 grep pour ces numéros de processus.
La sortie de systemctl list-unit-files Peut fournir des informations sur les processus conflictuels

ou:
fuser -kivn tcp 80, Où:
-v Imprime le nom du processus en plus de l'ID du processus
-i Le rend rapide avant de tuer
https://community.letsencrypt.org/t/nginx-emerg-bind-to-80-failed-98-address-already-in-use/52914/5

2
SherylHohman

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 d'ouverture du serveur 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.

0
Dario Zadro