Alt alan adı için Nginx çakışan sunucu adı

Şu anda foo.domain.com için Nginx üzerinde çalışan bir vhost var ve her şey harika çalışıyor.

Bar.domain.com adlı yeni bir alt alan adı için yeni bir dosya oluşturdum. Her ikisi için de aynı ayarları kullanıyorum.

Nginx'i yeniden başlattığımda

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

Bar.domain.com'a gittiğimde ne görmem gerektiğini görüyorum, ancak foo.domain.com'a gittiğimde bar.domain.com'un bağlandığı sayfayı görüyorum.

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

Nerede yanlış gidiyorum?

Https bloklarınızın sunucu adlarının da belirtilmesi gerekiyormuş gibi görünüyor.

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

Ayrıca içinde /etc/nginx/sites-available/<site-name>bağlı başka dosyalarınız da olabilir /etc/nginx/sites-enabled/<site-name>.

Bu dosyalardaki ayarlar /etc/nginx/sites-available/defaultdosyayla çakışabilir

Yanlışlıkla yinelenen sunucu adı vardı benzer bir sorun vardı:

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

Bunu şu şekilde değiştirerek düzeltildi:

server_name myserver.example.com;

Ayrıca her dosyada /etc/nginx/conf.dyinelenen dosya olup olmadığını kontrol edin .

Benim durumumda, nginx -ttestleri geçti - nginx'i başlatmaya çalışırken bu hata mesajını aldım.

Benim /etc/nginx/sites-enableddosyaları etki (sunucu adı) kopyalardan ücretsiz olduğunu ve sadece vardı 1 referansı server_default(ve hiçbir localhostçiftleri)

Bunun yerine, conf.dher ikisinde belirli bir etki alanına başvuruda bulunan 2 dosya vardı (yani 2 dosyada şöyle bir satır vardı: servername mydomain.comburada etki alanı adlarından biri 2 dosyada listelenmiştir).

Çözümüm: Bu nedenle, tüm dosyaların conf.dyalnızca belirli bir servername(etki alanı adı) değerine en fazla bir kez başvurduğundan emin olun .

( ne yazık ki yukarıdaki sorunu düzelttikten sonra, şimdi:
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use) nginx'i yeniden başlatmaya çalıştığımda hata iletileri alıyorum.)

Güncelleme : Bilginize, re: ... Address already in useyukarıdaki hata iletisi:
Tümü ben edildi yapmak zorunda sudo fuser -k 80/tcpsonra service nginx restartbir cazibe gibi çalıştı!
Cevabı burada buldum: https://easyengine.io/tutorials/nginx/tro Giderme/emerg-bind-failed-98-address-already-in-use/

update2 :
Başka bir işlemin 80 numaralı bağlantı noktasını kullanması önerildi (bu yüzden onu öldürmek işe yaradı ve aynı zamanda b / c nginx'in o anda çalışmadığı anlamına geliyor).
https://community.letsencrypt.org/t/nginx-emerg-bind-to-80-failed-98-address-already-in-use/52914/4

Ayrıca, süreci öldürmeden önce görmenin, soruna neyin sebep olduğu hakkında fikir verebileceğini de belirtiyorlar.
Bu nedenle, muhtemelen aşağıdakilerden birini kullanmak daha iyidir: sudo fuser -k 80/tcp(-k seçeneği olmadan), ardından grepbu işlem numaraları için a gelir.
systemctl list-unit-filesçıktı, çakışan süreç hakkında fikir verebilir

ya:
fuser -kivn tcp 80, burada:
-vişlem kimliği ek olarak işlem adını yazdıran
-iöldürmeden önce onu istemi yapar
https://community.letsencrypt.org/t/nginx-emerg-bind-to-80-failed-98-address-already- kullanım / 52914/5

Benim durumumda, herhangi bir kopya bulamadım. Ancak, default.conf burada açılış sunucu bloğu ve kapanış ayracı dışında tüm yapılandırma yorum yaptı ... ve bu çakışan hataya neden oldu.

Temel olarak, soruna neden olan bir sunucu_adı yönergesi OLMADAN, yinelenen bir sunucu bloğu için hesaplanmamıştı.