В настоящее время у меня есть 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.
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;
...
}
Бар
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;
}
Куда я иду не так?
nginx
ssl
virtualhost
RockJake28
источник
источник
server_name
в конфигурации SSL (443).listen 443
на каждом сервере добавитьserver_name [foo/bar].domain.com
?Ответы:
Похоже, ваши блоки https тоже должны указывать имена серверов, например
источник
Вы также можете иметь дополнительные файлы
/etc/nginx/sites-available/<site-name>
, которые связаны с/etc/nginx/sites-enabled/<site-name>
.Настройки в этих файлах могут конфликтовать с
/etc/nginx/sites-available/default
файломисточник
У меня была похожая проблема, когда у меня случайно было дублированное имя сервера:
Исправлено путем изменения на:
источник
server_name
; Я имел такую конфигурацию в течение многих лет и никогда не беспокоился об этом сообщении об ошибке. Оказывается, я ошибочно запустил vhost, который должен был быть просто шаблоном 😮Также проверьте каждый файл на
/etc/nginx/conf.d
наличие дубликатов.В моем случае
nginx -t
прошли тесты - я получил это сообщение об ошибке при попытке запустить nginx.Мои
/etc/nginx/sites-enabled
файлы были свободны от дубликатов домена (имя сервера) и имели только 1 ссылку наserver_default
(и не имелиlocalhost
дубликатов)Вместо этого было 2 файла, в
conf.d
которых оба ссылались на определенный домен (то есть 2 файла имели строку типа:,servername mydomain.com
где одно из доменных имен было указано в 2 файлах).Мое решение: так что убедитесь, что все файлы
conf.d
только ссылаются на какое-то конкретное значениеservername
(имя домена), самое большее.( к сожалению, после исправления вышеуказанной проблемы я получаю:
nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)
сообщения об ошибках при попытке перезапустить nginx.)обновление : FYI, повторно: ...
Address already in use
сообщение об ошибке выше:Все , что я должен был сделать
sudo fuser -k 80/tcp
тоservice nginx restart
работал как шарм!Я нашел ответ здесь: https://easyengine.io/tutorials/nginx/trou устранение неисправностей/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- в использовании / 52914/5
источник
В моем случае я не смог найти дубликат. Однако у меня был файл default.conf, в котором я прокомментировал все настройки, кроме открытия блока сервера и закрывающей скобки ... и это вызвало конфликтную ошибку.
По сути, это был неучтенный блок сервера БЕЗ директивы server_name, который вызвал проблему, а не дубликат.
источник