nginx обслуживает страницы для запросов на голый IP-адрес (который не соответствует имени_сервера) - PullRequest
0 голосов
/ 21 марта 2019

У меня есть конфигурация nginx с двумя виртуальными хостами и без сайта по умолчанию.

server {
  listen 123.45.67.89:80;
  server_name site_a.example.com site_a1.example.com;

  root /srv/site_a_checkout/html/site_a;
  access_log /var/log/site_a/nginx.access.log;
  error_log /var/log/site_a/nginx.error.log;

  index index.html index.htm index.nginx-debian.html;

  location / {
    # First attempt to serve request as file, then
    # as directory, then fall back to displaying a 404.
    try_files $uri $uri/ =404;
  }
}

Каждая из конфигураций виртуального хоста имеет строку server_name с двумя серверами.

Наличие второго имени_сервера, site_a1.example.com, объясняется тем, что существует более одного сервера, и иногда разработчикам необходимо знать, на какой сервер они смотрят.

nginx работает точно так, как ожидается, если запрошены http://site_a.example.com, http://site_a1.example1.com, http://site_b.example.com или http://site_b1.example1.com.

Проблема в том, что если запрашивается http://123.45.67.89, сайт site_a обслуживается.

Нет /etc/nginx/sites_enabled/default, только виртуальные хосты для site_a и site_b.

Почему site_a используется как http://123.45.67.89?

Как я могу отправлять запросы на IP-адрес?


Я также пробовал: https://superuser.com/a/1050864 и https://serverfault.com/a/525011, но они тоже не работали.

1 Ответ

0 голосов
/ 21 марта 2019

Ни одно из этих решений не работало, потому что они неявно прослушивали 0.0.0.0:80, в то время как виртуальные хосты прослушивали 123.45.67.89:80.

.

Серверы по умолчанию должны существовать для любых конкретных IP-адресов, которые прослушиваются виртуальными хостами.

Это работает:

server {
  server_name _;
  listen 123.45.67.89:80 default_server deferred;
  return 444;
}

Если я добавлю:

  listen 123.45.67.89:443 default_server deferred;

уничтожает HTTPS-соединения (до того, как SNI может быть прочитан), разрывая все виртуальные хосты SSL на этом IP-адресе. Это проблема для другого дня. https://serverfault.com/q/959286/20520

...