1. Главная страница » Компьютеры » Nginx server name несколько имен

Nginx server name несколько имен

Автор: | 16.12.2019

Имена сервера

Имена сервера задаются с помощью директивы server_name и определяют, в каком блоке server будет обрабатываться тот или иной запрос. См. также “Как nginx обрабатывает запросы”. Имена могут быть заданы точно, с помощью маски или регулярного выражения:

При поиске виртуального сервера по имени, если имени соответствует несколько из указанных вариантов, например, одновременно подходят и имя с маской, и регулярное выражение, будет выбран первый подходящий вариант в следующем порядке приоритета:

  1. точное имя
  2. самое длинное имя с маской в начале, например “ *.example.org ”
  3. самое длинное имя с маской в конце, например “ mail.* ”
  4. первое подходящее регулярное выражение (в порядке следования в конфигурационном файле)

Имена с масками

Имя с маской может содержать звёздочку (“ * ”) только в начале или в конце имени, и только на границе, определяемой точкой. Имена “ www.*.example.org ” и “ w*.example.org ” являются некорректными, но их можно задать с помощью регулярных выражений, например, “

^w.*.example.org$ ”. Звёздочка может соответствовать нескольким частям имени. Имени с маской “ *.example.org ” соответствует не только www.example.org , но и www.sub.example.org .

Специальное имя с маской вида “ .example.org ” соответствует как точному имени “ example.org ”, так и маске “ *.example.org ”.

Имена, заданные регулярными выражениями

Регулярные выражения, используемые в nginx, совместимы с используемыми в языке программирования Perl (PCRE). Имя сервера, заданное регулярным выражением, должно начинаться с символа тильды:

в противном случае оно будет рассматриваться как точное, или же, если выражение содержит звёздочку (“ * ”), то как имя с маской (и, скорее всего, некорректное). Не забывайте ставить специальные символы начала (“ ^ ”) и конца (“ $ ”) строки. По синтаксису они не требуются, но логически они могут быть нужны. Также заметьте, что все точки в доменных именах должны быть экранированы символом обратной косой черты. Регулярное выражение, содержащее символы “ < ” и “ >”, необходимо экранировать:

иначе nginx откажется запускаться и выдаст сообщение об ошибке:

К именованному выделению в регулярном выражении можно впоследствии обратиться через переменную:

Библиотека PCRE поддерживает именованные выделения, используя следующий синтаксис:

? name > Совместимый с Perl 5.10 синтаксис, поддерживается начиная с PCRE-7.0
?’ name Совместимый с Perl 5.10 синтаксис, поддерживается начиная с PCRE-7.0
?P name > Python-совместимый синтаксис, поддерживается начиная с PCRE-4.0

то это значит, что используется старая версия библиотеки PCRE и следует вместо этого попробовать синтаксис “ ?P name > ”. Также можно использовать нумерованные выделения:

Однако такое использование должно ограничиваться простыми случаями как в примере выше, поскольку нумерованные выделения легко могут быть перезаписаны.

Прочие имена

Некоторые имена имеют специальное значение.

Если необходимо обрабатывать запросы без поля “Host” в заголовке в блоке server, который не является сервером по умолчанию, следует указать пустое имя:

Если директива server_name не задана в блоке server, то nginx будет использовать пустое имя в качестве имени сервера.

Версии nginx вплоть до 0.8.48 в этом случае использовали имя хоста (hostname) машины в качестве имени сервера.

Если имя сервера задано как “ $hostname ” (0.9.4), то используется имя хоста (hostname) машины.

Если в запросе вместо имени сервера указан IP-адрес, то поле “Host” заголовка запроса будет содержать IP-адрес, и запрос можно обработать, используя IP-адрес как имя сервера:

В примерах конфигурации серверов, обрабатывающих все запросы, встречается странное имя “ _ ”:

Оно не является каким-то особенным, это просто одно из множества некорректных доменных имён, которые никогда не пересекутся ни с одним из реальных имён. С тем же успехом можно использовать имена типа “ — ” и “ !@# ”.

Версии nginx вплоть до 0.6.25 поддерживали специальное имя “ * ”, которое многими неверно воспринималось как имя сервера для обработки всех запросов. Оно никогда так не работало, и не работало как имя с маской. Это имя действовало так же, как сейчас действует директива server_name_in_redirect. Специальное имя “ * ” объявлено устаревшим, а вместо него следует использовать директиву server_name_in_redirect. Заметьте, что с помощью директивы server_name нельзя задать ни имя сервера для обработки всех запросов, ни сервер по умолчанию. Это является свойством директивы listen, а не server_name. См. также “Как nginx обрабатывает запросы”. Можно настроить серверы, слушающие на портах *:80 и *:8080, и указать, что один из них будет сервером по умолчанию для порта *:8080, а другой — для порта *:80:

Читайте также:  Digital book reader prs 600

Интернационализованные имена

Для указания интернационализированных доменных имён (IDNs) в директиве server_name следует указывать Punycode-представление имени:

Оптимизация

Точные имена, имена с масками, начинающиеся со звёздочки, и имена с масками, заканчивающиеся на звёздочку, хранятся в трёх хэш-таблицах, привязанных к слушающим портам. Размеры хэш-таблиц оптимизируются на фазе конфигурации таким образом, что имя может быть найдено с минимальным числом непопаданий в кэш процессора. Подробнее настройка хэш-таблиц обсуждается в отдельном документе.

В первую очередь имя ищется в хэш-таблице точных имён. Если имя не было найдено, то имя ищется в хэш-таблице имён с масками, начинающихся со звёздочки. Если и там поиск не дал результата, то имя ищется в хэш-таблице имён с масками, оканчивающихся на звёздочку.

Поиск в хэш-таблице имён с масками медленнее, чем поиск в хэш-таблице точных имён, поскольку имена сравниваются по доменным частям. Заметьте, что специальное имя с маской вида “ .example.org ” хранится в хэш-таблице имён с масками, а не в хэш-таблице точных имён.

Регулярные выражения проверяются последовательно, а значит являются самым медленным и плохо масштабируемым методом.

По вышеизложенным причинам предпочтительнее использовать точные имена, где это только возможно. Например, если к серверу наиболее часто обращаются по именам example.org и www.example.org , то эффективнее будет указать их явно:

нежели чем использовать упрощённую форму:

Если задано большое число имён серверов, либо заданы необычно длинные имена, возможно потребуется скорректировать значения директив server_names_hash_max_size и server_names_hash_bucket_size на уровне http. Значение по умолчанию директивы server_names_hash_bucket_size может быть равно 32, 64, либо другой величине, в зависимости от размера строки кэша процессора. Если значение по умолчанию равно 32 и имя сервера задано как “ too.long.server.name.example.org ”, то nginx откажется запускаться и выдаст сообщение об ошибке:

В этом случае следует увеличить значение директивы до следующей степени двойки:

Если задано большое число имён серверов, то будет выдано другое сообщение об ошибке:

В таком случае сначала следует попробовать установить server_names_hash_max_size в величину, близкую к числу имён серверов, и только если это не поможет или время запуска nginx станет неприемлемо большим, следует попытаться увеличить server_names_hash_bucket_size.

Если сервер является единственным сервером для слушающего порта, то nginx не будет проверять имена сервера вообще (а также не будет строить хэш-таблицы для слушающего порта). За одним исключением: если имя сервера задано регулярным выражением с выделениями, то nginx’у придётся выполнить это выражение, чтобы получить значения выделений.

Я изо всех сил пытаюсь настроить два разных доменных имени на моем выделенном сервере.

У меня уже есть одно DN, настроенное так в vhost DOMAIN_1.net.conf:

У меня также есть три других субдомена этого домена, настроенных таким же образом.

И я хочу установить собственный облачный сервер на доменное имя DOMAIN_2.ovh в vhost DOMAIN_2.ovh.conf:

Но когда я перезагружаю Nginx, я получаю эту ошибку:

nginx: [предупредить] конфликтующее имя сервера "DOMAIN_2.ovh" в 0.0.0.0:8080, игнорируется nginx.

Мой файл nginx.conf:

Я нашел много вопросов об этой ошибке, но я не могу ее исправить. Если кто-то может мне помочь, это будет отличный рождественский подарок;) о, о, о

Nginx – компактный и производительный веб-сервер, созданный для систем с высоким трафиком. Одной из его сильных сторон является эффективное представление статического контента, например, HTML или медиафайлов. В Nginx используется асинхронная модель с управлением событиями, что обеспечивает предсказуемую производительность при высокой нагрузке.
Динамический контент Nginx передает CGI, FastCGI или другим веб-серверам, например, Apache. Затем этот контент возвращается Nginx для отправки клиенту. В данном руководстве мы рассмотрим базовые принципы и параметры конфигурации Nginx.

Читайте также:  Gigabyte ga h61n usb3

Директивы, блоки и контексты

Все файлы конфигурации Nginx располагаются в директории /etc/nginx/ . Основной файл конфигурации – /etc/nginx/nginx.conf .
Опции конфигурации Nginx называются директивами. Директивы организованы в группы, называемые блоками или контекстами (эти два понятия являются синонимами).
Строки, начинающиеся с символа «решетки» (#) – это комментарии. Они не интерпретируются Nginx. Строки с директивами должны оканчиваться на точку с запятой, иначе конфигурация не будет загружена, и вы получите сообщение об ошибке.

Ниже приведена сокращенная копия файла /etc/nginx/nginx.conf , который входит в состав установки. Он начинается с 4 директив: user, worker_processes, error_log, и pid. Они не входят в состав блока, поэтому говорят, что они находятся в контексте main. Блоки events и http содержат дополнительные директивы и также расположены в контексте main.

Блок http

Блок http содержит директивы управления веб-трафиком. Они часто называются универсальными, потому что используются для конфигурации всех веб-сайтов, содержащихся на сервере. Полный список всех доступных директив и их параметров для этого блока можно посмотреть в документации Nginx. В /etc/nginx/nginx.conf можно увидить примерно следующий блок http

В рассмотренном примере заданы следующие директивы:

include – указывает расположение дополнительных файлов конфигурации
default_type – задает MIME-тип ответов по умолчанию
log_format – задает поля, которые будут сохраняться в логе сервера
access_log – путь к файлу лога доступа к серверу
sendfile – прямая передача данных без буферизации, используется для ускорения работы сервера
tcp_nopush – настройка формирования TCP-пакетов, ускоряющая работу сервера (в данном случае закомментировано)
keepalive_timeout – максимальное время поддержания соединения, если пользователь ничего не запрашивает
gzip – включение компрессии (в данном случае закомментировано)

  • Как уже было сказано, блок http содержит директиву include, которая указывает расположение файлов конфигурации Nginx.
    Если установка выполнялась из официального репозитория Nginx, эта строка, как и в рассмотренном примере, будет иметь вид include /etc/nginx/conf.d/*.conf; . У каждого веб-сайта на вашем сервере в этой директории должен быть свой файл конфигурации с именем формата example.com.conf. Для отключенных сайтов (не отображаемых Nginx) он может быть переименован в формате example.com.conf.disabled.
  • При установке из репозиториев Debian или Ubuntu данная строка будет иметь вид include /etc/nginx/sites-enabled/*; . Директория /sites-enabled/ содержит символические ссылки на файлы конфигурации, которые хранятся в /etc/nginx/sites-available/ . Отключение сайта осуществляется удалением символической ссылки на sites-enabled.
  • В зависимости от источника установки в /etc/nginx/conf.d/default.conf или /etc/nginx/sites-enabled/default есть пример файла конфигурации.

Серверные блоки

Независимо от источника установки файлы конфигурации будут содержать серверный блок (или блоки) для веб-сайта, обозначенный словом server. Например:

Директива server_name позволяет размещать несколько доменов на одном IP-адресе (виртуальные хосты). Выбор домена осуществляется на основании информации в заголовке полученного запроса.

Директива listen задает Nginx имя или IP-адрес узла и TCP-порт, который он должен прослушивать для HTTP-соединений. Аргумент default_server означает, что этот виртуальный хост будет отвечать на все запросы на порт 80, в которых в явном виде не будет указан другой виртуальный хост. Вторая такая директива устанавливает аналогичное поведение для IPv6-соединений.

Обычно для каждого домена или сайта на сервере требуется создать свой файл. Вот некоторые примеры:

1.Обработка запросов к example.com и www.example.com:

2.В директиве server_name можно использовать маски. Например, *.example.com и .example.com указывают серверу обрабатывать запросы на все поддомены example.com:

3.Обработка запросов ко всем доменным именам, начинающимся с example.:

Nginx разрешает указывать имена сервера, не соответствующие правилам доменных имен. Для ответа на запросы используется имя из заголовка HTTP вне зависимости от того, является ли оно допустимым доменным именем.

Это полезно, если ваш сервер работает в локальной сети или вы точно знаете все клиенты, которые будут осуществлять запросы, например, front-end прокси-серверы, у которых записи в /etc/hosts настроены на IP-адрес Nginx.

Блоки Location

Блоки location позволяют настроить, как Nginx будет отвечать на запросы к ресурсам на сервере. Подобно тому, как директива server_name определяет обработку запросов к доменам, директивы location охватывают запросы к конкретным файлам и папкам, таким как http://example.com/blog/. Вот несколько примеров:

Указанные выше расположения – это точно определенные строки, которые соответствуют части HTTP-запроса после имени узла.

Читайте также:  Android studio переключение между layout

Запрос: http://example.com/
Ответ: Если для example.com есть запись server_name, обработка данного запроса будет определяться директивой location / .

Nginx всегда выполняет запрос, находя наиболее точное соответствие:

Запрос: http://example.com/planet/blog/ или http://example.com/planet/blog/about/
Ответ: Обработку запроса будет определять директива location /planet/blog/ , потому что она соответствует точнее, хотя location /planet/ также удовлетворяет условиям запроса.

Когда после директивы location указана тильда (

), Nginx определяет соответствие по регулярному выражению. Этот поиск всегда чувствителен к регистру. Таким образом, страница IndexPage.php будет соответствовать первому из приведенных выше примеров, а indexpage.php – нет. Во втором примере регулярному выражению будут соответствовать запросы к /BlogPlanet/ и /BlogPlanet/index.php, но не /BlogPlanet, /blogplanet/, или /blogplanet/index.php. В Nginx используются Perl-совместимые регулярные выражения.
Если вы хотите, чтобы поиск не был чувствителен к регистру, после тильды нужно указать звездочку (

Если указать перед тильдой символ «крышки» (^

), при соответствии запроса указанной строке сервер прекратит поиск более точных соответствий (даже если они есть) и будет использовать эти директивы. Во всем остальном они аналогичны рассмотренным выше директивам.

Знак равенства (=) после директивы location означает необходимость точного соответствия указанному пути. В случае его наличия поиск прекращается. Например, запрос http://example.com/ будет соответствовать указанному выше примеру, а http://example.com/index.html — нет. Использование точных соответствий может ускорить время обработки запроса, если какие-то запросы распространены больше других.

Директивы обрабатываются в следующем порядке:

  1. Сначала обрабатываются точные соответствия строк. Если соответствие найдено, Nginx прекращает поиск и отвечает на запрос.
  2. Обрабатываются оставшиеся директивы с точно заданными строками. Если Nginx находит соответствие директиве с аргументом ^

, он прекращает поиск и отвечает на запрос. В противном случае обработка директив location продолжается.
Обрабатываются директивы location с регулярными выражениями (

*). Если запрос соответствует регулярному выражению, Nginx прекращает поиск и отвечает на запрос.

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

    Внутри блока location указываются собственные директивы, например:

    В данном примере корень документов находится в директории html/. При установке Nginx в месторасположение по умолчанию она находится в /etc/nginx/html/ . В директиве root также можно использовать абсолютный путь.

    Запрос: http://example.com/blog/includes/style.css
    Ответ: Nginx попытается передать клиенту файл /etc/nginx/html/blog/includes/style.css

    Переменная index сообщает Nginx, какой файл передавать, если клиент не указал конкретное имя, например:

    Запрос: http://example.com
    Ответ: Nginx попытается передать файл /etc/nginx/html/index.html .

    Если в директиве index указано несколько файлов, Nginx пройдет по списку и передаст первый существующий файл. Если файла index.html в соответствующей директории нет, будет передан index.htm. В случае если ни один из файлов не существует, будет отправлено сообщение об ошибке 404.

    Вот более сложный пример набора директив location для сервера example.com:

    В данном примере все запросы ресурсов, которые заканчиваются на расширение .pl, будут обработаны вторым блоком location, в котором для ответа на эти запросы задан обработчик fastcgi. Ресурсы расположены в файловой системе /srv/www/example.com/public_html/ . Если имя файла в запросе не указано, Nginx найдет и передаст файл index.html или index.htm. Если их нет, он выдаст ошибку 404.

    Разберем ответы на некоторые запросы

    Запрос: http://example.com/
    Ответ: /srv/www/example.com/public_html/index.html если файл существует. Если нет, сервер передаст /srv/www/example.com/public_html/index.htm . Если и этот файл не существует, Nginx выдаст ошибку 404.

    Запрос: http://example.com/blog/
    Ответ: /srv/www/example.com/public_html/blog/index.html если файл существует. Если нет, сервер передаст /srv/www/example.com/public_html/blog/index.htm . Если и этот файл не существует, Nginx выдаст ошибку 404.

    Запрос: http://example.com/tasks.pl
    Ответ: Nginx воспользуется обработчиком FastCGI для выполнения файла /srv/www/example.com/public_html/tasks.pl и выдаст результат.

    Запрос: http://example.com/username/roster.pl
    Ответ: Nginx воспользуется обработчиком FastCGI для выполнения файла /srv/www/example.com/public_html/username/roster.pl и выдаст результат.

    Заключение

    Мы разобрали базовые принципы и параметры конфигурации веб-сервера Nginx. Этого достаточно, чтобы настроить простой сайт. Для более подробной информации о директивах файлов конфигурации стоит изучить официальную документацию Nginx.

    Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

    Добавить комментарий

    Ваш e-mail не будет опубликован. Обязательные поля помечены *