Nginx как файловый сервер

Обновлено: 03.07.2024

В этом руководстве представлены основные сведения о nginx и описаны некоторые простые задачи, которые можно с его помощью выполнить. Предполагается, что nginx уже установлен на машине читателя. Если это не так, см. страницу Установка nginx. В этом руководстве описывается, как запускать и останавливать nginx, а также перезагружать его конфигурацию, объясняется структура файла конфигурации и описывается, как настроить nginx для обслуживания статического контента, как настроить nginx в качестве прокси-сервера и как подключить его к приложение FastCGI.

nginx имеет один главный процесс и несколько рабочих процессов. Основная цель главного процесса — чтение и оценка конфигурации, а также поддержка рабочих процессов. Рабочие процессы выполняют фактическую обработку запросов. nginx использует событийную модель и механизмы, зависящие от ОС, для эффективного распределения запросов между рабочими процессами. Количество рабочих процессов определяется в файле конфигурации и может быть фиксированным для данной конфигурации или автоматически подстраиваться под количество доступных ядер ЦП (см. worker_processes).

Способ работы nginx и его модулей определяется в файле конфигурации. По умолчанию файл конфигурации называется nginx.conf и помещается в каталог /usr/local/nginx/conf , /etc/nginx или /usr/local/etc/nginx .

Запуск, остановка и перезагрузка конфигурации

Чтобы запустить nginx, запустите исполняемый файл. После запуска nginx им можно управлять, вызывая исполняемый файл с параметром -s. Используйте следующий синтаксис:

Где сигнал может быть одним из следующих:

стоп — быстрое завершение работы
quit — корректное завершение работы
reload — перезагрузка файла конфигурации
reopen — повторное открытие файлов журнала.

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

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

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

Сигнал также может быть отправлен процессам nginx с помощью инструментов Unix, таких как утилита kill. В этом случае сигнал отправляется непосредственно процессу с заданным идентификатором процесса. Идентификатор процесса главного процесса nginx по умолчанию записывается в nginx.pid в каталоге /usr/local/nginx/logs или /var/run . Например, если идентификатор главного процесса равен 1628, чтобы отправить сигнал QUIT, приводящий к корректному завершению работы nginx, выполните:

Для получения списка всех запущенных процессов nginx можно использовать утилиту ps, например, следующим образом:

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

Структура файла конфигурации

Обслуживание статического контента

Сначала создайте каталог /data/www и поместите в него файл index.html с любым текстовым содержимым, создайте каталог /data/images и поместите в него несколько изображений.

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

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

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

В этом блоке местоположения указан префикс «/» по сравнению с URI из запроса. Для совпадающих запросов к пути, указанному в корневой директиве, то есть к /data/www, будет добавлен URI для формирования пути к запрашиваемому файлу в локальной файловой системе. Если есть несколько совпадающих блоков местоположения, nginx выбирает блок с самым длинным префиксом. Вышеприведенный блок местоположений предоставляет самый короткий префикс длины один, поэтому этот блок будет использоваться только в том случае, если все остальные блоки местоположений не обеспечивают совпадения.

Далее добавьте второй блок местоположения:

Это будет соответствовать запросам, начинающимся с /images/ ( location / также соответствует таким запросам, но имеет более короткий префикс).

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

Чтобы применить новую конфигурацию, запустите nginx, если он еще не запущен, или отправьте сигнал перезагрузки главному процессу nginx, выполнив:

В случае, если что-то не работает должным образом, вы можете попытаться выяснить причину в файлах access.log и error.log в каталоге /usr/local/nginx/logs или /var/log/nginx .

Настройка простого прокси-сервера

Одним из частых применений nginx является настройка его в качестве прокси-сервера, что означает сервер, который получает запросы, передает их на проксируемые серверы, получает от них ответы и отправляет их клиентам.

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

Сначала определите проксируемый сервер, добавив еще один блок server в файл конфигурации nginx со следующим содержимым:

Это будет простой сервер, который прослушивает порт 8080 (ранее директива listen не указывалась, поскольку использовался стандартный порт 80) и сопоставляет все запросы с каталогом /data/up1 в локальной файловой системе. Создайте этот каталог и поместите в него файл index.html. Обратите внимание, что корневая директива находится в контексте сервера. Такая корневая директива используется, когда блок местоположения, выбранный для обслуживания запроса, не включает собственную корневую директиву.

Мы изменим второй блок местоположения, который в настоящее время сопоставляет запросы с префиксом /images/ с файлами в каталоге /data/images, чтобы он соответствовал запросам изображений с типичными расширениями файлов. Измененный блок местоположения выглядит следующим образом:

Параметр представляет собой регулярное выражение, соответствующее всем URI, оканчивающимся на .jpg , .jpg или .jpg . Перед регулярным выражением должен стоять ~. Соответствующие запросы будут сопоставлены с каталогом /data/images.

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

Результирующая конфигурация прокси-сервера будет выглядеть следующим образом:

Этот сервер будет фильтровать запросы, оканчивающиеся на .jpg , .jpg или .jpg, и сопоставлять их с каталогом /data/images (путем добавления URI к параметру корневой директивы) и передавать все остальные запросы на прокси-сервер, настроенный выше. .

Чтобы применить новую конфигурацию, отправьте сигнал перезагрузки в nginx, как описано в предыдущих разделах.

Существует множество других директив, которые можно использовать для дальнейшей настройки прокси-соединения.

Настройка проксирования FastCGI

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

Самая базовая конфигурация nginx для работы с сервером FastCGI включает использование директивы fastcgi_pass вместо директивы proxy_pass и директив fastcgi_param для установки параметров, передаваемых на сервер FastCGI. Предположим, что сервер FastCGI доступен на localhost:9000. Взяв за основу конфигурацию прокси из предыдущего раздела, замените директиву proxy_pass на директиву fastcgi_pass и измените параметр на localhost:9000. В PHP параметр SCRIPT_FILENAME используется для определения имени скрипта, а параметр QUERY_STRING используется для передачи параметров запроса. В результате конфигурация будет следующей:

Это настроит сервер, который будет направлять все запросы, кроме запросов статических изображений, на прокси-сервер, работающий на локальном хосте:9000, по протоколу FastCGI.

NGINX хорошо обслуживает статические файлы, такие как изображения и HTML-файлы. Это означает, что это уже отличный сервер для скачивания. В этой статье я расширяю его, добавляя функции аутентификации, загрузки и удаления файлов с помощью lua. В конце этой статьи я также расскажу о любимом сообществом модуле nginx-upload-module.

Скачать

upload — это папка с префиксом NGINX, в моем случае это /opt/nginx:

Если вы используете современный браузер, вы можете напрямую просматривать многие типы файлов, такие как видео, PDF-файлы и т. д. Как и встроенный модуль автоиндексации, aperezdc/ngx-fancyindex представляет собой более красивую альтернативу автоиндексации, добавляя настраиваемую тему.< /p>

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

Аутентификация

Модуль ngx_http_auth_basic_module позволяет ограничить доступ к ресурсам, проверив имя пользователя и пароль с помощью протокола "HTTP Basic Authentication".

авторизация_базовая

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

auth_basic_user_file

— это файл, в котором хранятся имена пользователей и хешированные пароли. Большинство директив, которым нужен путь, например, access_log, могут принимать относительный путь (относительно префикса nginx) в качестве аргумента. Но auth_basic_user_file должен быть абсолютным путем, иначе вы увидите страницу ошибки «403 Forbidden».

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

добавить еще одну пользовательскую панель:

-apr1 означает, что пароль хэшируется с помощью варианта Apache на основе алгоритма пароля на основе MD5, который является более безопасным, чем алгоритм шифрования по умолчанию.

Обратите внимание, что зашифрованный пароль каждый раз будет другим, даже если вы используете одинаковый пароль. Это волшебно, не так ли? Потому что каждый раз выбирается уникальная соль. Первые 2 символа вывода crypt — это соль, а во втором случае формат вывода — $apr1$salt$hash. Если вы укажете соль с помощью параметра -salt, вы всегда получите один и тот же результат.

Теперь обновите страницу, пользователю будет предложено ввести имя пользователя и пароль. Если вы введете правильные учетные данные, вам будет разрешен доступ к этим местоположениям. В противном случае вы увидите страницу ошибки "401 Требуется авторизация".

загрузить

lua-resty-upload

Здесь я использую openresty/lua-resty-upload, который представляет собой модуль lua, основанный на косокете ngx_lua. Требуется, чтобы модуль lua-nginx был скомпилирован в NGINX.

lua-resty-upload содержит только один файл upload.lua. Поместите этот файл в /usr/local/lib/lua/5.1/resty/upload.lua, а затем добавьте его в путь поиска LUA_PATH ngx_lua с помощью директивы lua_package_path .

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

nginx_upload.conf

Ниже приведена полная конфигурация:

my_upload.lua

Каждый раз, когда создается поле формы multipart/form-data, файл создается с использованием исходного имени файла, если заголовок этого поля содержит атрибут имени файла.

my_delete.lua

Я также добавляю место, которое позволяет пользователю удалить файл или пустую папку.

использование

Удалить файл очень просто:

Теперь мы настроили простой файловый сервер с помощью NINGX.

модуль загрузки nginx

Сначала я обращаюсь за помощью к nginx-upload-module. Это был классный модуль. Однако владелец больше не поддерживает этот модуль.

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

Вы должны скачать ветку 2.2, так как она содержит самые новые коммиты.

Произошла ошибка компиляции: md5.h: Нет такого файла или каталога, потому что NIGNX использует внутренние реализации MD5 и SHA, а внутренний ngx_md5.h отличается от md5.h в openssl. Вот простой патч, который устраняет эту проблему: fix-md5.h-No-such-file-or-directory

Если вы видите ошибку, аналогичную неопределенной ссылке на 'MD5_Upddate' при компиляции NGINX, вам может потребоваться добавить --with-ld-opt='-lssl -lcrypto' :

обычное использование

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

example.php должен быть помещен в папку html:

Файлы хранятся в каталоге, указанном директивой upload_store, с использованием простого алгоритма хеширования. Например, upload_store upload 1 2 может привести к сохранению файла как /opt/nginx/upload/1/05/0000000018 . Подкаталоги 1 и 05 выбираются случайным образом и должны существовать перед загрузкой. Хэшированный подкаталог является необязательным. Файл переименовывается в 10 цифр, чтобы избежать конфликтов в случае существования файла с таким же именем.

К счастью, upload_store также может принимать переменные.

Взломать его как обычный файловый сервер

Что делать, если я хочу сохранить файл под его исходным именем? Давайте взломаем его.

В этом модуле реализован механизм возобновляемой загрузки файла, также известной как частичная загрузка. Это означает, что большой файл можно разделить на несколько сегментов, а затем загрузить один за другим в отдельных запросах Post. Клиент несет ответственность за выбор уникального Session-ID, который является идентификатором загружаемого файла, а также именем файла, сохраненного на сервере.

Да, я могу достичь своей цели, используя имя файла в качестве идентификатора сеанса. Примените этот патч, чтобы Session-ID содержал точку. hack-allow-session-id-to-contain-dot

Настройте NGINX и NGINX Plus в качестве веб-сервера с поддержкой мультиарендности виртуального сервера, перезаписью URI и ответов, переменными и обработкой ошибок.

В этой статье объясняется, как настроить NGINX Open Source и NGINX Plus в качестве веб-сервера, и она включает следующие разделы:

Для получения дополнительной информации о настройке NGINX Plus и NGINX с открытым исходным кодом посмотрите наш бесплатный веб-семинар по запросу Установка и настройка NGINX.

Примечание. Информация в этой статье относится как к NGINX Open Source, так и к NGINX Plus. Для удобства чтения оставшаяся часть статьи относится только к NGINX Plus.

Настройка виртуальных серверов

Файл конфигурации NGINX Plus должен содержать хотя бы одну директиву server для определения виртуального сервера. Когда NGINX Plus обрабатывает запрос, он сначала выбирает виртуальный сервер, который будет обслуживать запрос.

Блок конфигурации сервера обычно включает директиву listen для указания IP-адреса и порта (или сокета и пути домена Unix), на которых сервер прослушивает запросы. Принимаются адреса как IPv4, так и IPv6; заключайте адреса IPv6 в квадратные скобки.

В приведенном ниже примере показана конфигурация сервера, который прослушивает IP-адрес 127.0.0.1 и порт 8080:

Если порт не указан, используется стандартный порт. Аналогично, если адрес опущен, сервер прослушивает все адреса. Если директива listen вообще не включена, «стандартный» порт — 80/tcp, а порт «по умолчанию» — 8000/tcp, в зависимости от привилегий суперпользователя.

Если есть несколько серверов, соответствующих IP-адресу и порту запроса, NGINX Plus проверяет поле заголовка Host запроса на соответствие директивам server_name в блоках сервера. Параметр server_name может быть полным (точным) именем, подстановочным знаком или регулярным выражением. Подстановочный знак — это строка символов, которая включает звездочку ( * ) в начале, в конце или в обоих случаях; звездочка соответствует любой последовательности символов. NGINX Plus использует синтаксис Perl для регулярных выражений; перед ними тильда ( ~ ). В этом примере показано точное имя.

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

Если поле заголовка Host не соответствует имени сервера, NGINX Plus направляет запрос на сервер по умолчанию для того порта, на который пришел запрос. Сервер по умолчанию указан первым в файле nginx.conf, если вы не включили параметр default_server в директиву listen, чтобы явно указать сервер по умолчанию.

Настройка местоположений

NGINX Plus может отправлять трафик на разные прокси или обслуживать разные файлы в зависимости от URI запроса. Эти блоки определяются с помощью директивы местоположения, помещенной в директиву сервера.

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

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

Примечание. В этом руководстве слово местоположение относится к контексту одного местоположения.

Директива location имеет два типа параметров: префиксные строки (пути) и регулярные выражения. Чтобы URI запроса соответствовал строке префикса, он должен начинаться со строки префикса.

Следующий образец расположения с параметром pathname соответствует URI запроса, который начинается с /some/path/ , например /some/path/document.html . (Он не соответствует /my-site/some/path, потому что /some/path не встречается в начале этого URI.)

Регулярному выражению предшествует тильда ( ~ ) для сопоставления с учетом регистра или тильда-звездочка ( ~* ) для сопоставления без учета регистра. В следующем примере сопоставляются URI, содержащие строку .html или .htm в любой позиции.

Приоритет местоположения NGINX

Чтобы найти местоположение, которое лучше всего соответствует URI, NGINX Plus сначала сравнивает URI с местоположениями со строкой префикса. Затем он ищет местоположения с помощью регулярного выражения.

Более высокий приоритет отдается регулярным выражениям, если только не используется модификатор ^~. Среди строк префикса NGINX Plus выбирает наиболее конкретную (то есть самую длинную и полную строку). Точная логика выбора места для обработки запроса приведена ниже:

Проверить URI на соответствие всем строкам префиксов.
Модификатор = (знак равенства) определяет точное совпадение URI и строки префикса. Если найдено точное совпадение, поиск останавливается.
Если модификатор ^~ (тильда вставки) добавляет самую длинную совпадающую строку префикса, регулярные выражения не проверяются.
Сохранить самую длинную совпадающую строку префикса.
Проверьте URI на соответствие регулярным выражениям.
Остановить обработку, когда будет найдено первое совпадающее регулярное выражение, и использовать соответствующее расположение.
Если регулярное выражение не совпадает, используйте местоположение, соответствующее сохраненной строке префикса.

Типичный пример использования модификатора = — это запросы на / (косая черта). Если запросы на / часты, указание = / в качестве параметра директивы location ускоряет обработку, поскольку поиск совпадений останавливается после первого сравнения.

Директива root указывает путь к файловой системе, в котором следует искать статические файлы для обслуживания. URI запроса, связанный с местоположением, добавляется к пути, чтобы получить полное имя статического файла для обслуживания. В приведенном выше примере в ответ на запрос /images/example.jpg NGINX Plus доставляет файл /data/images/example.jpg .

Директива proxy_pass передает запрос на прокси-сервер, доступ к которому осуществляется с помощью настроенного URL-адреса. Затем ответ от прокси-сервера возвращается клиенту. В приведенном выше примере все запросы с URI, которые не начинаются с /images/, передаются на прокси-сервер.

Использование переменных

Вы можете использовать переменные в файле конфигурации, чтобы NGINX Plus обрабатывал запросы по-разному в зависимости от определенных обстоятельств. Переменные — это именованные значения, которые вычисляются во время выполнения и используются в качестве параметров директив. Переменная обозначается знаком $ (доллара) в начале ее имени. Переменные определяют информацию, основанную на состоянии NGINX, например свойства обрабатываемого в данный момент запроса.

Возврат определенных кодов состояния

Некоторые URI веб-сайта требуют немедленного возврата ответа с определенной ошибкой или кодом перенаправления, например, когда страница была временно или постоянно перемещена. Самый простой способ сделать это — использовать директиву return. Например:

Первый параметр return — это код ответа. Необязательным вторым параметром может быть URL-адрес перенаправления (для кодов 301, 302, 303 и 307) или текст, возвращаемый в теле ответа. Например:

Директива return может быть включена как в контекст местоположения, так и в контекст сервера.

Перезапись URI в запросах

URI запроса можно изменить несколько раз во время обработки запроса с помощью директивы перезаписи, которая имеет один необязательный и два обязательных параметра. Первый (обязательный) параметр — это регулярное выражение, которому должен соответствовать URI запроса. Второй параметр — это URI для замены соответствующего URI. Необязательный третий параметр — это флаг, который может остановить обработку дальнейших директив перезаписи или отправить перенаправление (код 301 или 302). Например:

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

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

После того как NGINX обработает набор инструкций по перезаписи, он выбирает контекст местоположения в соответствии с новым URI. Если выбранное место содержит директивы перезаписи, они выполняются по очереди. Если URI совпадает с любым из них, поиск нового местоположения начинается после обработки всех определенных директив перезаписи.

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

В этом примере конфигурации различаются два набора URI. Такие URI, как /download/some/media/file, заменяются на /download/some/mp3/file.mp3. Из-за последнего флага последующие директивы (вторая директива rewrite и директива return) пропускаются, но NGINX Plus продолжает обрабатывать запрос, который теперь имеет другой URI. Точно так же такие URI, как /download/some/audio/file, заменяются на /download/some/mp3/file.ra. Если URI не соответствует ни одной из директив перезаписи, NGINX Plus возвращает клиенту код ошибки 403.

Есть два параметра, которые прерывают обработку директив перезаписи:

last — останавливает выполнение директив перезаписи в текущем контексте сервера или местоположения, но NGINX Plus ищет местоположения, соответствующие перезаписанному URI, и применяются любые директивы перезаписи в новом расположении (это означает, что URI можно снова изменить) .
break — как и директива break, останавливает обработку директив перезаписи в текущем контексте и отменяет поиск местоположений, соответствующих новому URI. Директивы перезаписи в новом месте не выполняются.

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

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

Обработка ошибок

С помощью директивы error_page вы можете настроить NGINX Plus на возврат пользовательской страницы вместе с кодом ошибки, подстановку другого кода ошибки в ответ или перенаправление браузера на другой URI. В следующем примере директива error_page указывает страницу (/404.html), которая должна возвращаться с кодом ошибки 404.

Обратите внимание, что эта директива не означает, что ошибка возвращается немедленно (это делает директива return), а просто указывает, как обрабатывать ошибки, когда они происходят. Код ошибки может исходить от прокси-сервера или возникать во время обработки NGINX Plus (например, результат 404, когда NGINX Plus не может найти файл, запрошенный клиентом).

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

Директива error_page указывает NGINX Plus выполнять внутреннюю переадресацию, если файл не найден. Переменная $uri в последнем параметре директивы error_page содержит URI текущего запроса, который передается при перенаправлении.

Директива open_file_cache_errors предотвращает запись сообщения об ошибке, если файл не найден. В этом нет необходимости, так как отсутствующие файлы обрабатываются корректно.

NGINX – это веб-сервер, предназначенный для случаев использования с большими объемами трафика. Это популярное, легкое и высокопроизводительное решение.

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

Этот веб-сервер передает динамический контент на FastCGI, CGI или альтернативные серверы (включая Apache), прежде чем он будет отправлен обратно в NGINX для доставки клиентам.

В этом руководстве по настройке NGINX мы рассмотрим основы NGINX, чтобы помочь вам понять, как он работает и какие преимущества он предлагает.

Конфигурация NGINX: понимание директив

Каждый файл конфигурации NGINX находится в каталоге /etc/nginx/, а основной файл конфигурации находится в /etc/nginx/nginx.conf.

Параметры конфигурации NGINX известны как «директивы»: они организованы в группы, которые взаимозаменяемо называются блоками или контекстами .

Ниже мы включили сокращенную копию файла /etc/nginx/nginx.conf, входящего в состав установок из репозиториев NGINX. Этот файл начинается с четырех директив:

пользователь

рабочие_процессы

журнал_ошибок

идентификатор

Они существуют вне какого-либо конкретного контекста или блока, и говорят, что они находятся в основном контексте.

error_log /var/log/nginx/error.log предупреждение;

log_format main '$remote_addr - $remote_user [$time_local] "$request" '

'$status $body_bytes_sent "$http_referer" '

журнал доступа /var/log/nginx/access.log основной;

Что такое серверные блоки?

При установке NGINX из репозиториев Ubuntu или Debian строка будет выглядеть так: include /etc/nginx/sites-enabled/*;. Папка ../sites-enabled/ будет содержать символические ссылки на файлы конфигурации сайта, расположенные в /etc/nginx/sites-available/. Вы можете отключить сайты в пределах site-available, если уберете символическую ссылку на site-enabled.

В зависимости от источника установки иллюстративный файл конфигурации можно найти в /etc/nginx/conf.d/default.conf или etc/nginx/sites-enabled/default.

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

прослушать 80 default_server;

прослушать [::]:80 default_server;

try_files $uri /index.html;

Что такое прослушивающие порты?

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

Что такое виртуальный хостинг на основе имени?

Директива server_name позволяет обслуживать несколько доменов с одного IP-адреса, и сервер определяет, какой домен он будет обслуживать, в соответствии с полученным заголовком запроса.

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

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

Недоменные имена хостов могут оказаться полезными, если ваш сервер находится в локальной сети или вы знаете всех клиентов, которые могут отправлять запросы на сервер. Сюда входят внешние прокси-серверы с записями /etc/hosts, настроенными для IP-адреса, который прослушивает NGINX.

Что такое блоки местоположения?

Давайте рассмотрим несколько примеров:

В NGINX запросы всегда выполняются с наиболее точным совпадением:

Возвращает: это будет выполнено директивой location /planet/blog, поскольку она более конкретна, несмотря на то, что location /planet также является совпадением.

Если за директивами местоположения следует символ ~ (тильда), NGINX будет выполнять сопоставление с регулярным выражением, которое всегда чувствительно к регистру.

Например, IndexPage.php будет соответствовать первому из приведенных выше примеров, а indexpage.php — нет.

Во втором примере регулярное выражение ^/BlogPlanet(/|/index\.php)$ < >соответствует запросам для /BlogPlanet/ и /BlogPlanet/index.php, но не /BlogPlanet, /blogplanet/ или /blogplanet/index.php. NGINX использует Perl-совместимые регулярные выражения (PCRE).

Что делать, если вы предпочитаете, чтобы совпадения не учитывали регистр? Ну, вы должны использовать тильду, за которой следует звездочка: ~*. Вы можете видеть, что приведенные выше примеры определяют, что NGINX должен обрабатывать запросы, оканчивающиеся на определенное расширение файла: первый пример определяет, что файлы, оканчивающиеся на .pl, PL, .cgi, .perl, .Perl, .prl и .PrL (а также как и другие) будут соответствовать запросу.

Добавляя знак вставки и тильду (^~) к директивам местоположения, вы сообщаете NGINX, что в случае совпадения с определенной строкой он должен прекратить поиск более конкретных совпадений и вместо этого использовать эти директивы здесь.

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

Теперь давайте рассмотрим дополнительные сведения об обработке директив местоположения.

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

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

Сначала будут обрабатываться точные совпадения строк: NGINX прекращает поиск, если найдено совпадение, и выполняет запрос.
Все остальные литеральные строковые директивы будут обработаны далее. NGINX остановится и выполнит запрос, если найдет совпадение с использованием аргумента ^~. В противном случае NGINX продолжит обработку директив местоположения.
Каждая директива местоположения с регулярным выражением (~ и ~*) будет обработана следующей. Если регулярное выражение соответствует запросу, NGINX завершит поиск и выполнит запрос.
Наконец, если совпадающих регулярных выражений нет, будет использоваться наиболее точное совпадение буквальной строки.

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

Вложенные блоки местоположения не рекомендуются и не поддерживаются.

Как использовать корневой каталог и индекс местоположения

Настройка местоположения — это еще одна переменная с собственным блоком аргументов.

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

индекс index.html index.htm;

В этом примере мы видим, что корень документа находится в каталоге html/. Под префиксом установки NGINX по умолчанию полный путь к местоположению — /etc/nginx/html/.

Возвращает: NGINX попытается обслужить файл, найденный в /etc/nginx/html/blog/includes/style.css

Обратите внимание:

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

Так, например:

Возврат: NGINX попытается обслужить файл, найденный в /etc/nginx/html/index.html.

Если для директивы index указано количество файлов, список будет обработан по порядку, и NGINX выполнит запрос с первым обнаруженным существующим файлом. Если index.html не может быть расположен в соответствующем каталоге, вместо него будет использоваться index.htm. Сообщение 404 будет доставлено в том случае, если их вообще не существует.

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

индекс index.html index.htm;

Здесь мы видим, что второй блок location обрабатывает все запросы ресурсов, оканчивающихся на расширение .pl, и указывает для них обработчик fastcgi. В противном случае NGINX будет использовать первую директиву location.

Давайте рассмотрим, что происходит во время нескольких примеров запросов:

На этом наше руководство по настройке NGINX заканчивается.Мы надеемся, что это поможет вам быстро приступить к работе и настроить его!

Читайте также: