что такое location nginx

Nginx location, примеры использования и принципу выбора location

Веб-сервером Nginx location выбирается сравнивая URI поступившего запроса с обозначением location

1) с полным URI сравниваются все выражения, не включающие регулярные выражения

2) сначала сверяются все блоки с =

3) если совпадений нет проверяется ^

и сразу задействуется самый длинный из них

4) не найдя таких Nginx ищет опять же самое длинное совпадение и резервирует результат поиска

5) проверка с учетом регулярных выражений — выбирается первое выражение среди подходящих под самый длинный префикс

6) при отсутствии результата используется блок, зарезервированный на шаге 4

Изменить эту логику и заставить какой-то блок обрабатываться вперед остальных проще всего используя = или ^

\.php$ <
fastcgi_pass localhost:9000;
…

При обращении к /data/www/script.html за отсутствием других совпадений будет выбран location /data/www, если в URL php скрипт он обработается другим блоком и запрос передастся на обработку на порт 9000, на котором работает PHP-FPM.

Для изображений будет выбран блок в котором устанавливается заголовок expires, затем запрос обрабатывается тем выражением, которое задано для /, т.е. картинки будут запрашиваться в /data/www, если их там нет возникнет ошибка 404.

Источник

Nginx location

Как я вижу, тебя интересует настройка nginx, и в этой статье я постараюсь тебе помочь кое в чём разобраться. А именно — с nginx директивой location, её назначением и синтаксисом.

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

Итак, директива location служит для установки конфигурации в зависимости от URI-запроса.

Синтаксис location в общем виде следующий:

Как видите, операторы соответствия расположены в квадратных скобках, что значит, что они опциональны, их может и не быть в некоторых расположениях.

Перед тем, как перейти к более детальному изучению, нужно заметить, что location определяется в контексте server (или в location в случае вложенной директивы), и в одном настраиваемом виртуальном хосте могут использоваться разные конфигурации в зависимости от обрабатываемого сервером URI.

Префикс «@» («собака») определяет именованные расположения. Такие location’ы не используются для обработки обычных запросов. Вместо этого они используются для перенаправления запросов (пример №6). Они не могут быть вложенными и содержать в себе вложенные.

Для задания расположения, к которому будет применяться тот или иной фрагмент конфигурации, можно пользоваться как строками, так и регулярными выражениями. Что из этого выбрать — зависит от поставленной задачи.

Логика работы

Логика работы nginx при определением нужного расположения такова: сначала он ищет соответствия URI со строковыми location’ами. Если он нашёл подходящий строковый литерал с оператором соответствия «=», поиск завершается. Иначе, запомнив удовлетворяющий (если такой нашелся) максимальной длины, сравнивает с местоположениями, заданными через регулярные выражения в порядке их следования в конфигурационном файле. Если одно из регулярных выражений удовлетворило запрашиваемому ресурсу, поиск больше не продолжается. Если же ни одна регулярка не подошла, выбирается сохранённая на первом шаге строка максимальной длины.

Nginx location с регулярными выражениями

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

На заметку: Nginx умеет декодировать URI налету. Например, для URI «/my/nginx/%20%20%20/logo.png» для определения location можно использовать «/my/nginx/ /logo.png».

Nginx location со строковыми литералами

Префикс «=» предназначен для строгого соответствия между запрошенным URI и значением location. Если они полностью совпадают, поиск сразу же прекращается.

Выделение переменной

При соотношении URI с расположением через регулярные выражения можно выделять некоторые фрагменты строки в переменную. Как это сделать можно посмотреть в примере №7).

Источник

Как nginx обрабатывает запросы

Определение виртуального сервера по имени

nginx вначале решает, какой из серверов должен обработать запрос. Рассмотрим простую конфигурацию, где все три виртуальных сервера слушают на порту *:80:

В этой конфигурации, чтобы определить, какому серверу следует направить запрос, nginx проверяет только поле “Host” заголовка запроса. Если его значение не соответствует ни одному из имён серверов или в заголовке запроса нет этого поля вовсе, nginx направит запрос в сервер по умолчанию для этого порта. В вышеприведённой конфигурации сервером по умолчанию будет первый сервер, что соответствует стандартному поведению nginx по умолчанию. Сервер по умолчанию можно задать явно с помощью параметра default_server в директиве listen:

Следует иметь в виду, что сервер по умолчанию является свойством слушающего порта, а не имени сервера. Подробнее это обсуждается ниже.

Как предотвратить обработку запросов без имени сервера

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

Здесь в качестве имени сервера указана пустая строка, которая соответствует запросам без поля “Host” в заголовке, и возвращается специальный для nginx код 444, который закрывает соединение.

Начиная с версии 0.8.48 настройка server_name «» является стандартной и может явно не указываться. В более ранних версиях в качестве стандартного имени сервера выступало имя машины (hostname).

Определение виртуального сервера по имени и IP-адресу

Рассмотрим более сложную конфигурацию, в которой некоторые виртуальные серверы слушают на разных адресах:

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

Конфигурация простого сайта PHP

Теперь посмотрим на то, как nginx выбирает location для обработки запроса на примере обычного простого PHP-сайта:

nginx вначале ищет среди всех префиксных location’ов, заданных строками, максимально совпадающий. В вышеприведённой конфигурации указан только один префиксный location “ / ”, и поскольку он подходит под любой запрос, он и будет использован, если других совпадений не будет найдено. Затем nginx проверяет location’ы, заданные регулярными выражениями, в порядке их следования в конфигурационном файле. При первом же совпадении поиск прекращается и nginx использует совпавший location. Если запросу не соответствует ни одно из регулярных выражений, nginx использует максимально совпавший префиксный location, найденный ранее.

Следует иметь в виду, что location’ы всех типов сопоставляются только с URI-частью строки запроса без аргументов. Так делается потому, что аргументы в строке запроса могут быть заданы различными способами, например:

Кроме того, в строке запроса можно запросить что угодно:

Теперь посмотрим, как бы обрабатывались запросы в вышеприведённой конфигурации:

Источник

Директива location в Nginx

10 Июня, 2014 6 мин чтения

За свою карьеру я собрал большой багаж опыта работы с веб-сервером Nginx и некоторые моменты освещал в данном блоге. Для навигации по теме используйте страницу Nginx 101

Location широко используется в конфигурациях Nginx, поэтому во избежание проблем веб-сайта, нужно понимать, как он работает.

Контекст

В конфигурации Nginx есть такое понятие как контекст. Контекст указывает на то, в каких частях конфига может быть использована та или иная директива. Если директива не прописана внутри какого-либо контекста, т.е. на самом верхнем уровне, это контекст main. Директивы events и http располагаются в контексте main, server — в http, а location — в server.

Синтаксис

Location c фильтрацией по URI:

— необязательные модификаторы, которые меняют поведение обработчика запросов. В uri могут быть использованы символьные строки или регулярные выражения.

Префиксные location

Если в location не указан ни один модификатор, то он считается префиксным. Это значит, что uri запроса будет сравниваться с uri location с начала строки. Например, следующий location совпадает с любым запросом, начинающимся с /.

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

Следующая конфигурация сопоставляется с любым запросом, начинающимся с /app/ и затем, поиск продолжается, если соответствия с регулярными выражениями не будут найдены, запрос будет соответствовать /app/

Регулярные выражения

Для того чтобы использовать регулярные выражения, необходимо всегда использовать модификаторы:

для соответствия с учетом регистра

* для соответствия без учета регистра

Nginx имеет возможность декодировать URI, в реальном времени. Например, для того, чтобы найти соответствия “/app/%20/images” вы можете использовать “/app/ /images”.

Cледующий location cовпадает с любым запросом заканчивающимся на png, ico, gif, jpg или jpeg.

Приоритет перед регулярными выражениями

По умолчанию, если URI совпадает и с префиксным, и с регулярным выражением, будет использован location с регулярным выражением. Но бывают случаи, когда необходимо изменить эту логику. Для этого используется модификатор ^

Например, у нас уже есть location, в который попадают запросы картинок с расширениями png, ico, gif, jpg или jpeg из предыдущего примера. Но мы хотим, чтобы все запросы начинающиеся с /img/avatar/ обрабатывались по другому. Тогда конфиг будет выглядеть так

Запрос /img/banner.png будет обработан первым location, но запрос /img/avatar/user_365.jpg попадет во второй.

Точное соответствие

Модификатор = означает точное соответствие между URI-запросом и параметром location. Когда это происходит, поиск сразу же прекращается. Если вы видите, что ваше приложение часто обращается с запросом “/”, использование

ускорит обработку этого запроса. А если совпадает точно с запросом /app, используйте

Реальные примеры location

Anti-hotlinking – защита файлов вашего сайта от прямого доступа с других сайтов или сервисов. Использование директивы Location для Anti-hotlinking

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

Autoindex — это функция, которая включает листинг директорий по http средствами веб-сервера. Работает в том случае, если в директории нет настоящего index-файла. Благодаря этой функции можно без знаний программирования создать сайт, с которого можно скачивать файлы. Использование Location чтобы включить autoindex в Nginx:

Если вы хотите больше узнать о директиве Location в nginx, можете прочитать официальную документацию.

Источник

Работа сервера Nginx и алгоритмов выбора блока расположения

Published on March 19, 2021

Введение

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

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

Конфигурации блока Nginx

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

В первую очередь мы расскажем о блоках server и location.

Блок server — это часть конфигурации Nginx, которая определяет виртуальный сервер, используемый для обработки запросов заданного типа. Администраторы часто настраивают несколько блоков server и определяют, какой из них будет отвечать за конкретное соединение на основании запрошенного доменного имени, порта и IP-адреса.

Блок location располагается внутри блока server и определяет, как Nginx будет обрабатывать запросы различных ресурсов и URI для родительского сервера. Администратор, использующий эти блоки, может разделить пространство URI любым удобным способом. Это чрезвычайно гибкая модель.

Как Nginx решает, какой серверный блок будет обрабатывать запрос

Поскольку Nginx разрешает администратору определять несколько серверных блоков, работающих как отдельные экземпляры виртуального веб-сервера, ему требуется процедура, определяющая, какие серверные блоки будут использоваться для выполнения запроса.

Синтаксический анализ директивы “listen” для поиска возможных совпадений

Прежде всего, Nginx смотрит IP-адрес и порт запроса. Он сверяет их с директивой listen каждого сервера, создавая список серверных блоков, которые могут обработать данный запрос.

Директиву listen можно задать следующим образом:

Последняя опция обычно влияет только на передачу запросов между разными серверами.

Проверка директивы “server_name” для выбора совпадения

Для оценки запросов с равноценным уровнем соответствия директив listen Nginx проверяет заголовок “Host” запроса. Это значение соответствует домену или IP-адресу, к которым клиент пытается подключиться.

Nginx пытается подобрать наилучшее значение на основе директивы server_name в каждом из серверных блоков, которые являются наилучшим соответствием. Nginx оценивает их по следующей формуле:

Примеры

В этом примере, если для запроса задать заголовку “Host” значение “host1.example.com”, будет выбран второй сервер:

Если точного совпадения найдено не будет, Nginx проверяет наличие параметра server_name с подходящим начальным подстановочным символом. Для выполнения запроса будет выбрано самое длинное совпадение, начинающееся с подстановочного символа.

В этом примере, если заголовок “Host” запроса будет иметь значение “www.example.org”, будет выбран второй серверный блок:

Если не будет найдено совпадения с начальным подстановочным символом, Nginx проверит наличие совпадения с подстановочным символом в конце выражения. На этом шаге для обслуживания запроса выбирается наиболее длинное совпадение, заканчивающееся подстановочным символом.

Например, если заголовок “Host” запроса имеет значение “www.example.com”, будет выбран третий серверный блок:

Например, если заголовок “Host” будет иметь значение “www.example.com”, для выполнения запроса будет выбран второй серверный блок:

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

Совпадающие блоки расположения

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

Синтаксис блока расположения

Прежде чем рассказывать о том, как Nginx определяет, какой блок расположения использовать для обработки запросов, давайте посмотрим синтаксис, который можно увидеть в определениях блоков расположения. Блоки расположения находятся в серверных блоках (или других блоках расположения) и используются, чтобы решить, как обрабатывать URI запроса (часть запроса после доменного имени или IP-адрес/порта).

Блоки расположения обычно принимают следующую форму:

location_match выше определяет, что Nginx следует проверять в отношении URI запроса. Наличие или отсутствие модификатора в примере выше влияет на то, как Nginx пытается подобрать соответствие блока расположения. Далее перечислены модификаторы, используемые для интерпретации блока расположения:

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

Примеры, демонстрирующие синтаксис блока расположения

Наконец, этот блок не даст выполнять сопоставление с регулярными выражениями, если будет признан лучшим совпадением без регулярного выражения. Он сможет обрабатывать запросы /costumes/ninja.html :

Как видите, модификаторы показывают, как следует интерпретировать блок расположения. Однако это не говорит нам, какой алгоритм Nginx использует для определения блока расположения, в который будет отправлен запрос. Этот вопрос мы рассмотрим далее.

Как Nginx выбирает расположение для обработки запросов

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

Учитывая описанные выше типы деклараций расположения, Nginx оценивает возможные контексты расположения, сравнивая URI запроса с каждым расположением. Для этого используется следующий алгоритм:

Важно понимать, что по умолчанию Nginx будет отдавать совпадениям регулярных выражений приоритет перед совпадениями префиксов. Однако он вначале оценивает расположения префиксов, позволяя администратору переопределить этот приоритет, используя модификаторы = и ^

при определении расположения.

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

Наконец, важно понимать, что совпадения регулярных выражений с самым длинным совпадением префикса будут иметь больший приоритет при оценке регулярных выражений Nginx. Они будут оцениваться по порядку до начала оценки любых других совпадений регулярных выражений. Максим Дунин, разработчик Nginx, дающий очень много полезных советов, объясняет в этом сообщении принципы работы данной части алгоритма выбора.

Когда оценка блока расположения переходит к другим расположениям?

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

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

Вот некоторые директивы, которые могут активировать подобную внутреннюю переадресацию:

Давайте вкратце рассмотрим их.

Директива index всегда вызывает внутреннюю переадресацию, если используется для обработки запроса. Точные совпадения расположения часто используются для ускорения процесса выбора с немедленным завершением алгоритма. Однако, если точное совпадение расположения представляет собой каталог, есть вероятность, что запрос будет переадресован для фактической обработки в другое расположение.

Если в примере выше вы захотите ограничить исполнение первым блоком, вам нужно будет подобрать другой метод выполнения запроса каталога. Например, вы можете задать недопустимый index этого блока и включить autoindex :

Рассмотрим следующую конфигурацию:

Например, если мы изменим последний пример и включим в него директиву rewrite, мы увидим, что запрос будет иногда передаваться во второе расположение без использования директивы try_files :

Рассмотрим следующий пример:

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

Заключение

Понимание способов обработки запросов клиентов в Nginx может значительно упростить работу администратора. Вы сможете понимать, какой серверный блок будет выбирать Nginx в ответ на запрос каждого клиента. Также вы поймете, как определить выбираемый блок расположения на основе URI запроса. Понимание того, как Nginx выбирает разные блоки, позволит вам отслеживать применяемые Nginx контексты для обслуживания каждого запроса.

Источник