Nginx, конфликтующий имя сервера для субдомена
У меня в настоящее время есть vhost, работающий на Nginx для foo.domain.com, и все работает отлично.
Я создал новый файл для нового субдомена, который я хочу добавить названный bar.domain.com. Я использую те же настройки для обоих.
Когда я перезапускаю Nginx, я добираюсь
Restarting nginx: nginx: [warn] conflicting server name "" on 0.0.0.0:443, ignored nginx.
Когда я перехожу к bar.domain.com, я вижу то, что я, как предполагается, вижу, но когда я перехожу к foo.domain.com, я вижу страницу, с которой связывается bar.domain.com.
Нечто
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;
...
}
Панель
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;
}
Где я иду не так, как надо?
Мне кажется, что для ваших https-блоков тоже нужно указывать имена серверов например
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;
}
Возможно, у вас также есть дополнительные файлы в /etc/nginx/sites-available/, которые связаны с /etc/nginx/sites-enabled/.
Настройки в этих файлах могут конфликтовать с файлом /etc/nginx/sites-available/default
У меня был аналогичная проблема, когда у меня случайно дублировалось имя сервера:
server_name myserver.example.com myserver.example.com;
Исправлено изменением его на:
server_name myserver.example.com;
Также проверьте каждый файл в /etc/nginx/conf.d на наличие дубликатов.
В моем случае nginx -t прошел тесты - Я получил это сообщение об ошибке при попытке запустить nginx.
Мои / etc / nginx / sites-enabled файлы не содержали дубликатов домена (имени сервера) и имели только 1 ] ссылка на server_default (и нет дубликатов localhost )
Вместо этого в conf.d было 2 файла, которые оба ссылались на конкретный домен (т. е. 2 файлы имели такую строку: имя_сервера mydomain.com , где одно из доменных имен было перечислено в 2 файлах).
Мое решение:
Поэтому убедитесь, что все файлы в conf.d ссылаются на любое конкретное значение servername (имя домена) не более одного раза.
( к сожалению после исправления вышеуказанной проблемы я теперь получаю:
nginx: [emerg] bind () to 0.0.0.0:80 не удалось (98: адрес уже используется)
сообщения об ошибках при попытке перезапустить nginx.)
обновление :
FYI, re: ... Адрес уже используется сообщение об ошибке выше:
Все, что мне нужно было сделать, это sudo fuser -k 80 / tcp , затем перезапуск службы nginx работал как шарм!
Я нашел ответ здесь: https://easyengine.io/tutorials/nginx/troubleshooting/emerg-bind-failed-98-address-already-in-use/
update2 :
Было высказано предположение, что другой процесс использовал порт 80 (поэтому его отключение сработало, а также имеет смысл, что b / c nginx не работал в то время).
https: // community. letsencrypt.org/t/nginx-emerg-bind-to-80-failed-98-address-already-in-use/52914/4
Они также указывают, что просмотр процесса перед тем, как его просто убить, может обеспечить понимание причины проблемы.
Следовательно, вероятно, лучше использовать:
sudo fuser -k 80 / tcp (без опции -k), за которым следует grep для этих номеров процессов.
systemctl list-unit-files вывод, может дать представление о конфликтующем процессе
или:
fuser -kivn tcp 80 , где:
-v печатает имя процесса в дополнение к идентификатору процесса
-i выводит запрос перед убийством
https://community.letsencrypt.org/t/nginx-emerg-bind-to-80-failed-98-address-already-in-use/52914/5
В моем случае, я не смог найти дубликат. Однако, у меня был файл default.conf, где я прокомментировал весь конфиг, кроме блока открывающего сервера и закрывающей скобки... и это вызвало конфликтную ошибку.
В основном, проблема была в неучтенном блоке сервера БЕЗ директивы server_name, а не в дубликате.
.У меня была такая же проблема при использовании Nginx с AWS Elastic Beanstalk и puma. Проблема заключалась в том, что существует собственный файл ngnix, который расширяет конфигурацию nginx по умолчанию, и оба определяют «локальный хост сервера». Использование правильного имени сервера устранило проблему.
В моем случае у меня было несколько поддоменов и конфиг для каждого из них. У них было правильное server_name на каждом сервере. На одном сервере указан 80 порт, на втором нет (должен был быть 443). Во время работы certbot я увидел это предупреждение nginx.
server {
root /var/www/41/html;
index index.html;
server_name 41.mezinamiridici.cz;
location / {
try_files $uri $uri/ /index.html;
}
listen 443 ssl; #this was missing
ssl_certificate /etc/letsencrypt/live/41.mezinamiridici.cz/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/41.mezinamiridici.cz/privkey.pem; # managed by Certbot
}
server {
if ($host = 41.mezinamiridici.cz) {
return 301 https://$host$request_uri;
} # managed by Certbot
server_name 41.mezinamiridici.cz;
listen 80;
listen [::]:80;
}
Еще одна возможная причина появления этого сообщения: дополнительные серверные блоки, созданные с помощью certbot для получения сертификатов от Let's Encrypt.
Оказалось, что каждый запуск certbot добавлял некоторые серверные блоки в мои файлы конфигурации nginx, эти записи можно было идентифицировать по комментарию «managed by certbot». Эти дополнительные блоки обрабатывают, например. переадресация с http на https. Какое-то время они не беспокоили nginx, но когда я добавил еще один серверный блок для поддомена через /sites-available, эти предупреждения о «конфликтующих именах серверов» действительно появились.
В какой-то момент я сделал резервную копию «по умолчанию» файла конфигурации NGINX. Это было причиной проблемы, поскольку файл резервной копии также рассматривался как файл конфигурации, что делало его дубликатом. Удаление этого резервного-файла решило проблему.