Posted:
Авг 20, 2020
Comments:
0 Comments

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

Содержание

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

Как предотвратить обработку запросов без имени сервера
Определение виртуального сервера по имени и IP-адресу
Конфигурация простого сайта PHP

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

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

server {
    listen      80;
    server_name example.org www.example.org;
    ...
}
server {
    listen      80;
    server_name example.net www.example.net;
    ...
}
server {
    listen      80;
    server_name example.com www.example.com;
    ...
}

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

server {
    listen      80 default_server;
    server_name example.net www.example.net;
    ...
}

Параметр default_server появился в
версии 0.8.21.
В более ранних версиях вместо него следует использовать параметр
default.

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

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

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

server {
    listen      80;
    server_name "";
    return      444;
}

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

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

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

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

server {
    listen      192.168.1.1:80;
    server_name example.org www.example.org;
    ...
}
server {
    listen      192.168.1.1:80;
    server_name example.net www.example.net;
    ...
}
server {
    listen      192.168.1.2:80;
    server_name example.com www.example.com;
    ...
}

В этой конфигурации nginx вначале сопоставляет IP-адрес и порт
запроса с директивами
listen
в блоках
server.
Затем он сопоставляет значение поля “Host”
заголовка запроса с директивами
server_name
в блоках
server,
которые соответствуют IP-адресу и порту.
Если имя сервера не найдено, запрос будет обработан в
сервере по умолчанию.
Например, запрос www.example.com, пришедший на порт
192.168.1.1:80, будет обработан сервером по умолчанию для порта
192.168.1.1:80, т.е. первым сервером, т.к. для этого порта
www.example.com не указан в списке имён серверов.

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

server {
    listen      192.168.1.1:80;
    server_name example.org www.example.org;
    ...
}
server {
    listen      192.168.1.1:80 default_server;
    server_name example.net www.example.net;
    ...
}
server {
    listen      192.168.1.2:80 default_server;
    server_name example.com www.example.com;
    ...
}

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

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

server {
    listen      80;
    server_name example. org www.example.org;
    root        /data/www;
    location / {
        index   index.html index.php;
    }
    location ~* \.(gif|jpg|png)$ {
        expires 30d;
    }
    location ~ \.php$ {
        fastcgi_pass  localhost:9000;
        fastcgi_param SCRIPT_FILENAME
                      $document_root$fastcgi_script_name;
        include       fastcgi_params;
    }
}

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

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

/index.php?user=john&page=1
/index.php?page=1&user=john

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

/index.php?page=1&something+else&user=john

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

  • Запросу “/logo.gif” во-первых соответствует префиксный
    location “/”, а во-вторых — регулярное выражение
    “\.(gif|jpg|png)$”,
    поэтому он обрабатывается location’ом регулярного выражения.
    Согласно директиве “root /data/www” запрос
    отображается в файл /data/www/logo.gif, который
    и посылается клиенту.
  • Запросу “/index.php” также во-первых соответствует префиксный
    location “/”, а во-вторых — регулярное выражение
    “\. (php)$”.
    Следовательно, он обрабатывается location’ом регулярного выражения
    и запрос передаётся FastCGI-серверу, слушающему на localhost:9000.
    Директива
    fastcgi_param
    устанавливает FastCGI-параметр
    SCRIPT_FILENAME в “/data/www/index.php”,
    и сервер FastCGI выполняет указанный файл.
    Переменная $document_root равна
    значению директивы
    root,
    а переменная $fastcgi_script_name равна
    URI запроса, т.е. “/index.php”.
  • Запросу “/about.html” соответствует только префиксный
    location “/”, поэтому запрос обрабатывается в нём.
    Согласно директиве “root /data/www” запрос
    отображается в файл /data/www/about.html, который
    и посылается клиенту.
  • Обработка запроса “/” более сложная.
    Ему соответствует только префиксный location “/”,
    поэтому запрос обрабатывается в нём.
    Затем директива
    index
    проверяет существование индексных файлов согласно своих параметров
    и директиве “root /data/www”.
    Если файл /data/www/index.html не существует,
    а файл /data/www/index.php существует, то
    директива делает внутреннее перенаправление на “/index.php”
    и nginx снова сопоставляет его с location’ами,
    как если бы такой запрос был послан клиентом.
    Как мы видели ранее, перенаправленный запрос будет в конечном итоге
    обработан сервером FastCGI.
автор: Игорь Сысоев
редактор: Brian Mercer

Управление nginx

Изменение конфигурации
Ротация лог-файлов
Обновление исполняемого файла на лету

Управлять nginx можно с помощью сигналов. Номер главного процесса по умолчанию
записывается в файл /usr/local/nginx/logs/nginx.pid.
Изменить имя этого файла можно при конфигурации сборки или же в
nginx.conf директивой
pid.
Главный процесс поддерживает следующие сигналы:

TERM, INTбыстрое завершение
QUITплавное завершение
HUPизменение конфигурации,
обновление изменившейся временной зоны (только для FreeBSD и Linux),
запуск новых рабочих процессов с новой конфигурацией,
плавное завершение старых рабочих процессов
USR1переоткрытие лог-файлов
USR2обновление исполняемого файла
WINCHплавное завершение рабочих процессов

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

TERM, INTбыстрое завершение
QUITплавное завершение
USR1переоткрытие лог-файлов
WINCHаварийное завершение для отладки
(требует включения debug_points)

Изменение конфигурации

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

Предположим, на FreeBSD команда

ps axw -o pid,ppid,user,%cpu,vsz,wchan,command | egrep '(nginx|PID)'

показывает примерно такую картину:

  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
33126     1 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
33127 33126 nobody   0.0  1380 kqread nginx: worker process (nginx)
33128 33126 nobody   0.0  1364 kqread nginx: worker process (nginx)
33129 33126 nobody   0.0  1364 kqread nginx: worker process (nginx)

Если послать сигнал HUP главному процессу, то картина может быть такой:

  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
33126     1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx
33129 33126 nobody   0.0  1380 kqread nginx: worker process is shutting down (nginx)
33134 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
33135 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
33136 33126 nobody   0. 0  1368 kqread nginx: worker process (nginx)

Один старый рабочий процесс 33129 всё ещё продолжает работать. По истечении
некоторого времени он завершается:

  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
33126     1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx
33134 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
33135 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
33136 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)

Ротация лог-файлов

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

Обновление исполняемого файла на лету

Для обновления исполняемого файла сервера вначале нужно записать
на место старого файла новый.
Затем нужно послать сигнал USR2 главному процессу — он
переименует свой файл с номером процесса в файл
с суффиксом .oldbin, например,
/usr/local/nginx/logs/nginx.pid.oldbin,
после чего запустит новый исполняемый файл, а тот в свою
очередь — свои рабочие процессы:

  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
33126     1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx
33134 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
33135 33126 nobody   0.0  1380 kqread nginx: worker process (nginx)
33136 33126 nobody   0.0  1368 kqread nginx: worker process (nginx)
36264 33126 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
36265 36264 nobody   0. 0  1364 kqread nginx: worker process (nginx)
36266 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36267 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)

Теперь все рабочие процессы наравне принимают запросы.
Если послать сигнал WINCH первому главному процессу, то он пошлёт своим
рабочим процессам сообщение о плавном выходе, и они будут постепенно выходить:

  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
33126     1 root     0.0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx
33135 33126 nobody   0.0  1380 kqread nginx: worker process is shutting down (nginx)
36264 33126 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
36265 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36266 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36267 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)

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

  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
33126     1 root     0. 0  1164 pause  nginx: master process /usr/local/nginx/sbin/nginx
36264 33126 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
36265 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36266 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36267 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)

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

  • Послать старому главному процессу сигнал HUP.
    Старый главный процесс, не перечитывая конфигурации,
    запустит новые рабочие процессы.
    После этого можно плавно завершить все новые процессы,
    послав новому главному процессу сигнал QUIT.

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

Если новый главный процесс выходит, то старый главный процесс убирает
суффикс .oldbin из имени файла с номером процесса.

Если же обновление прошло удачно, то старому процессу нужно послать сигнал
QUIT, и останутся только новые процессы:

  PID  PPID USER    %CPU   VSZ WCHAN  COMMAND
36264     1 root     0.0  1148 pause  nginx: master process /usr/local/nginx/sbin/nginx
36265 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36266 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)
36267 36264 nobody   0.0  1364 kqread nginx: worker process (nginx)

Расширенный балансировщик нагрузки, веб-сервер и обратный прокси-сервер

Перейти к содержимому

class=»inner-wrap»>

Эта бесплатная электронная книга O’Reilly, созданная в честь F5 NGINX, предлагает практические советы по созданию, управлению и защите API.

Узнать больше

Переносите локальные рабочие нагрузки в Azure быстрее и проще с помощью NGINXaaS для Azure — собственной версии NGINX Plus для IaaS для Azure.

Узнать больше

В этой электронной книге от O’Reilly Media, дополняющей NGINX, вы узнаете, как реализовать стратегию DevSecOps, интегрируя безопасность на раннем этапе в процесс разработки с помощью облачной инфраструктуры на AWS.

Узнать больше

Повышение производительности, надежности и безопасности ваших приложений

  • Доставка приложений

  • Кубернетес

  • API-подключение

  • Безопасность приложений и API

Чтобы завершить миграцию в облако и закрыть устаревший центр обработки данных, Modern Hire должна была удовлетворить потребности финансового клиента в расширенной безопасности, включая разгрузку SSL, поддерживаемую аппаратным модулем безопасности (HSM), несмотря на зависимость от серверного программного обеспечения, не поддерживаемого его облаком. поставщик услуг HSM.

Узнайте, как Modern Hire использовала решение NGINX App Delivery для быстрого внедрения, снижения сложности и получения более детальной информации.

Центр компетенции Audi в области Kubernetes разработал Kubika O как независимую от облака платформу Kubernetes, функционирующую как бесшовная среда приложений. Большой проблемой перед запуском было решить, как все обезопасить. Audi требовалось проверенное решение WAF с сертифицированной функциональной совместимостью Red Hat OpenShift, а также надежная круглосуточная техническая поддержка.

Узнайте, как компания Audi использовала решение NGINX Kubernetes для обеспечения будущего своего технического видения Kubernetes и инновационных приложений.

Узнайте, как развернуть NGINX в любом облаке, устранить привязку к поставщику и снизить сложность. Цифровые компании полагаются на внутренние и внешние API, чтобы конкурировать. Доверьте NGINX Plus и NGINX Controller управление критически важными для бизнеса API и их защиту.

Узнайте, как Distil Networks предотвращает нарушения безопасности и ограничивает вредоносный трафик с помощью NGINX Plus и NGINX ModSecurity WAF. Сократите количество нарушений безопасности и ограничьте уязвимость вашей компании для злоумышленников с помощью NGINX Plus и NGINX App Protect.

Масштабируйте современные приложения с помощью F5 NGINX

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

NGINX с открытым исходным кодом

Веб-сервер с открытым исходным кодом, на котором работает более 400 миллионов веб-сайтов.

 

NGINX Plus

Универсальный балансировщик нагрузки, обратный прокси-сервер, веб-сервер, кэш контента и шлюз API.

 

NGINX Management Suite

Видимость и контроль над экземплярами NGINX, службами доставки приложений, рабочими процессами управления API и решениями безопасности.

 

NGINX App Protect

Современный WAF и отказ в обслуживании для защиты приложений и API.

 

NGINX Ingress Controller

Управление трафиком Kubernetes с функциями шлюза API, идентификации и наблюдения.

 

NGINX Service Mesh

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

 

Модуль NGINX

Веб-сервер и сервер приложений с открытым исходным кодом.

 

NGINX Amplify

Мониторинг SaaS и статический анализ для NGINX Open Source и NGINX Plus.

 

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

Читайте истории успеха

Новое из блога F5 NGINX

Блог

Рекомендации по настройке приложений микрослужб

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

 

Блог

Получить доступ к кластеру… с помощью BGP?

Наше решение для внешнего доступа к локальным кластерам Kubernetes сочетает в себе NGINX Ingress Controller, Calico и BGP. Загрузите полную пошаговую инструкцию.

 

Настройка NGINX и NGINX Plus в качестве веб-сервера

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

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

  • Настройка виртуальных серверов
  • Настройка местоположений
    • Приоритет местоположения
  • Использование переменных
  • Возврат определенных кодов состояния
  • Перезапись URI в запросах
  • Перезапись ответов HTTP
  • Обработка ошибок

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

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

На высоком уровне настройка NGINX Plus в качестве веб-сервера заключается в определении того, какие URL-адреса он обрабатывает и как он обрабатывает HTTP-запросы на ресурсы по этим URL-адресам. На более низком уровне конфигурация определяет набор виртуальных серверов , которые управляют обработкой запросов для определенных доменов или IP-адресов. Дополнительные сведения о файлах конфигурации см. в разделе Создание файлов конфигурации NGINX Plus.

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

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

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

Виртуальный сервер определяется директивой server в контексте http , например:

 http {
    сервер {
        # Конфигурация сервера
    }
}

Можно добавить несколько server в контекст http для определения нескольких виртуальных серверов.

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

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

 сервер {
    слушать 127.0.0.1:8080;
    # Дополнительная конфигурация сервера
}

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

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

 сервер {
    слушать 80;
    имя_сервера example.org www.example.org;
    #...
}

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

.

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

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

 сервер {
    слушать 80 default_server;
    #...
}

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

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

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

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

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

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

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

 расположение /некоторые/путь/ {
    #...
}

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

 местоположение ~ \.html? {
    #...
}

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

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

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

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

     местоположение = / {
    #...
}

    Контекст местоположения может содержать директивы, определяющие, как обрабатывать запрос — либо обслуживать статический файл, либо передавать запрос на прокси-сервер. В следующем примере запросы, соответствующие первым контекст местоположения обслуживаются файлы из каталога / data , а запросы, соответствующие второму, передаются на прокси-сервер, на котором размещается контент для домена www.example.com .

     сервер {
    местоположение /изображения/ {
        корень /данные;
    }
    расположение / {
        proxy_pass http://www.example.com;
    }
}

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

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

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

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

    Существует ряд предопределенных переменных, таких как основные переменные HTTP, и вы можете определить пользовательские переменные, используя директивы set, map и geo. Большинство переменных вычисляются во время выполнения и содержат информацию, связанную с конкретным запросом. Например, $remote_addr содержит IP-адрес клиента и $uri содержит текущее значение URI.

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

     местоположение / неправильно / URL {
    вернуть 404;
}

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

     местоположение /постоянно/перемещено/url {
    вернуть 301 http://www.example.com/moved/here;
}

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

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

    URI запроса может быть изменен несколько раз во время обработки запроса с помощью директивы перезаписи, которая имеет один необязательный и два обязательных параметра. Первый (обязательный) параметр — это регулярное выражение, которому должен соответствовать URI запроса. Второй параметр — это URI для замены соответствующего URI. Необязательный третий параметр — это флаг, который может остановить обработку следующих 9/users/(.*)$ /show?user=$1 перерыв;
    }

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

    Вы можете включить несколько директив переписать как в контексты server , так и location . (/download/.*)/audio/(\w+)\.?.*$ $1/mp3/$2.ra последним;
    вернуть 403;
    #…
    }

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

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

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

    Перезапись ответов HTTP

    Иногда вам нужно переписать или изменить содержимое ответа HTTP, заменив одну строку на другую. Вы можете использовать директиву sub_filter, чтобы определить применимую перезапись. Директива поддерживает переменные и цепочки замен, делая возможными более сложные изменения.

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

     местоположение / {
    sub_filter /blog/ /blog-staging/;
    sub_filter_once выключен;
}

    Другой пример изменяет схему с http:// на https:// и заменяет адрес localhost именем хоста из поля заголовка запроса. Директива sub_filter_once указывает NGINX применять директивы sub_filter последовательно в пределах местоположения:

     местоположение / {
    sub_filter 'href="http://127. 0.0.1:8080/" 'href="https://$host/";
    sub_filter 'img src="http://127.0.0.1:8080/" 'img src="https://$host/";
    sub_filter_once включен;
}

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

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

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

     error_page 404 /404.html;

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

    В следующем примере, когда NGINX Plus не может найти страницу, он заменяет код 301 на код 404 и перенаправляет клиента на http:/example.com/new/path.html . Эта конфигурация полезна, когда клиенты все еще пытаются получить доступ к странице по ее старому URI. Код 301 информирует браузер о том, что страница была перемещена навсегда, и ему необходимо автоматически заменить старый адрес на новый при возвращении.

     местоположение /old/path.html {
    error_page 404 = 301 http:/example.com/new/path.html;
}

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

    This entry was posted in Популярное