Proxy pass nginx что это
В этой мы рассмотрим возможности сервера NGINX в http проксировании, что помогает перенаправлять запросы на бекэнд сервера для дальнейшей обработки. Довольно часто Nginx настраивают в качестве реверсивного прокси для упрощения масштабирования инфраструктуры или для перенапраления запросов на сервера, которые не предназначены для работы при большой нагрузке.
Также мы затронем каким образом можно осуществить масштабирование при помощи встроенных в Nginx средствах балансировки и каким образом буферизация и кеширование помогут вам улучшить работоспособность прокси.
Общая информация по прокси
Если раньше вы сталкивались только с простыми односерверными настройками, то наверняка у вас возникает вопрос: «А зачем вообще перенаправлять запросы?».
Одна из основных причин — масштабирование инфраструктуры. Изначально Nginx был создан с возможностью обрабатывать множество одновременных соединений. Таким образом он способен перенаправлять запрос какому угодно количеству бекэнд-серверов, что позволяет вам распределить нагрузку. Также архитектура сервера помогает вам легко добавлять новые или отключать старые бекэнд-сервера.
Другой причиной может служит ситуация, когда ваш бекэнд-сервер не может обрабатывать поступающий к нему напрямую запрос. Многие фреймворки имеют в своем составе веб-сервера, но им, как правило, далеко до возможностей Nginx. Разместив Nginx до этих серверов ускорит работу и повысит безопасность вашего приложения.
Проксирование в Nginx работает путем изменения полученного запроса и передачи его серверам, отвечающим за его обработку. Результат отправляется обратно Nginx, который в свою очередь отвечает клиенту. В роли тех самых «других» серверов могут выступать удаленные или локальные машины, а иногда очередные виртуальные сервера, созданные в пределах Nginx. Сервера, на которые nginx перенаправляет запросы называются вышестоящими серверами ( upstream servers ).
Nginx способен перенаправлять запросы используя http(s), FastCGI, uwsgi или memcached протоколы посредством различных наборов директив для каждого типа прокси. В этой статье мы остановимся на протоколе http. Nginx отвечает за передачу запроса в таком виде, в котором вышестоящий сервер способен его понять.
Разбираем базовый проход через http прокси
Давайте взглянем на пример:
В этом примере в конце описания сервера не указан URI адрес. При получении запроса, соответствующего этой настройке, он будет без изменения передан вышестоящему серверу.
Приведем другой пример:
Такая замена не всегда возможна. В таком случае URI игнорируется и вышестоящий сервер получает либо оригинальный запрос, либо измененный другими директивами.
Разбираемся как Nginx обрабатывает заголовки
Стоит понимать, что одного только URI не достаточно, чтобы вышестоящий сервер корректно обработал запрос. Перенаправленный nginx запрос будет немного видоизменен. Больше всего будут затронуты заголовки запроса.
При передаче запроса Nginx вносит необходимые изменения в заголовки:
Nginx убирает все пустые заголовки. Нет никакого смысла загружать сервер пустыми заголовками.
Часто используемые значения заголовка host:
Установка или переназначение заголовков
Конечно, есть смысл перенести директиву proxy_set_header в раздел серверного или http контекста, чтобы можно было ссылаться на неё из разных мест настройки.
Определение вышестоящего контекста для балансировки прокси соединений
В предыдущем примере мы рассмотрели как создать простое прокси http соединение до бекэнд сервера. Nginx позволяет нам указывать целый пул серверов, которым можно переадресовывать запросы.
Эту возможность можно использовать при помощи директивы upstream задав ей список доступных серверов. Такая настройка подразумевает, что каждый сервер из этого списка способен полностью ответить на поступивший к нему запрос. То есть мы можем легко масштабировать свою инфраструктуру без лишних проблем. Директива upstream должна быть указана в контексте http настройки nginx сервера.
Разберем простой пример:
Изменение алгоритма балансировки
Изменить алгоритм в пределах пула серверов можно при задании определенных флагов и директив:
При изменении алгоритма балансировки блок настройки принимает следующий вид:
Указание весов серверов при балансировки
При задании списка серверов, каждый сервер имеет равнозначный вес. То есть каждый сервер может и должен обрабатывать одну и ту же степень нагрузки (принимая во внимания алгоритм балансировки). Но вы так же можете задать каждому серверу определенный вес.
В этом примере сервер host1.example.com будет получать в три раза больше запросов, чем два других сервера. По-умолчанию значение веса для каждого сервера устанавливается в единицу.
Использованию буферов для освобождения бекэнд серверов
Главный вопрос при проксировании это насколько изменится скорость работы при добавлении дополнительного сервера. Переход на большее или меньшее количество серверов может быть значительно смягчен при помощи системы буферизации и кеширования nginx.
При передачи запроса серверу следует учитывать скорость обоих соединений:
соединение клиент — nginx сервер соединение nginx сервер — бекэнд сервер
Nginx способен изменять свое поведение в зависимости от того, какое из соединений вы планируете оптимизировать.
Без использования буферов данные поступившие от прокси сервера сразу же возвращаются клиенту. Если вы отталкиваетесь от того, что клиентское соединение достаточно быстрое, то буферизацию можно отключить. При использовании буферов Nginx какое-то время хранит ответ полученный от бекэнд сервера и потом отправляет его клиенту. Если клиент не достаточно быстр, то nginx закрывает соединение с бекэнд-сервером как можно быстрее, а данные отправляет клиенту как только тот будет готов их принять.
proxy_busy_buffer_size : эта директива указывает максимально возможное количество занятых буферов. Хотя клиент может читать информацию только из одного буфера за подход, буферы образуют очередь для отправки данных клиентам. Таким образом она указывает на объем информации в буфере, которая имеет такое состояние.
proxy_max_temp_file_size : максимальный размер временного файла на диске на каждый запрос. Они создаются в случае, если ответ бекэнд сервера не помещается в один буфер. proxy_temp_file_write_size : максимально возможный объем информации, которая записывается за один подход в файл, если ответ сервера не помещается в буфер. proxy_temp_path : путь к месту на диске, где Nginx разрешается хранить временные файлы, если ответ не умещается в буфер.
Настройка прокси кеширования для уменьшения времени ответа
Буферизация помогает ослабить нагрузку на бекэнд-сервера, тем самым обработать большее число запросов. Nginx также предлагает механизм для кеширования ответов от бекэнд-серверов. Что помогает вообще отказаться от обращению к вышестоящим серверам при повторных запросах.
Настройка прокси кеша
В следующем примере мы выполним необходимые настройки для поднятия системы кеширования:
Пареметр level= указывает организацию кеша. Nginx будет создавать ключ кеша исходя из хеша значения ключа (настраивается ниже). Мы указали уровни таким образом, что получим каталог, название которого состоит из одного символа и вложенный в него каталог с названием из двух символов. Вам скорее всего не придется вдаваться в эти подробности, но эти параметры помогают Nginx быстрее найти нужную информацию.
Директива proxy_chache_key задает ключ для хранения кешированных значений. Он же применяется при поиске данных в кеше. Мы используем комбинацию из схемы соединения, метода, хоста и URI.
Директива proxy_cache_valid может быть указана несколько раз. Она указывает срок хранения данных в зависимости от кода ответа. В нашем примере мы храним данные в течение 10 минут для удачных и перенаправленных ответов и всего лишь одну минуту для ответов со статусом 404.
Итак мы настроили зону кеширования, но не указали Nginx, когда именно применять кеширование.
Эта информация указывается в контексте location для бекэнд серверов:
При использовании директивы proxy_cache мы указываем, что зона backcache должна быть использована для данного контекста. Таким образом nginx перед тем как обратиться к бекэнд серверу проверит наличие ответа в кеше.
Нюансы кешированных ответов
Кеширование значительно повышает скорость работы вашего прокси-сервера. Но не стоит забывать о нескольких моментах.
No-cache : указывает, что ответ не должен отправляться до тех пор, пока сервер не проверит не изменились ли данные на бекэнд-сервере. Такое значение используется при работе с динамическими данными. Хешированные метаданные заголовка Etag проверяются при каждом запросе. Если бекэнд отдает такие же значения, то тогда данные отправляются из кеша.
No-store : в этом случае ни при каких условиях данные не должны храниться в кеше. Такой подход является самым безопасным при работе с личными данными.
private : данные не должны кешироваться в общем пространстве кеша. При таком подходе, например, браузер пользователя может кешировать данные в то время как, прокси сервер нет.
Public : данные разрешается кешировать везде.
Значение этого заголовка зависит от чувствительности данных. При правильном использовании личные данные будут в безопасности, а часто изменяемое содержимое останется актуальным.
🐹 Nginx: Проксирование запросов с помощью proxy_pass.
Опубликовано 2020-11-12 · Обновлено 2021-01-30
Содержание:
На чем было опробовано:
1. Введение.
В nginx имеется одна интересная директива proxy_pass. Она позволяет проксировать запросы на удалённый сервер.
2. Настройка proxy_pass в nginx.
Проксирование ресурса с IP-адреса за NAT в интернет, мы передаем реальный IP-адрес клиента с помощью директивы proxy_set_header, которая добавляет в заголовок X-Real-IP настоящий IP-адрес клиента.
Будем проксировать файл myip.php с содержимым.
Текст файла конфигурации примет вид:
3. Передача реального IP-адреса (Real IP) клиента в nginx при proxy_pass.
В этом примере нужно на принимающей стороне, то есть test_srv сделать обратную замену — заменить информацию об адресе отправителя на ту, что указана в заголовке X-Real-IP.
Добавляем в секцию server следующие параметры:
Полностью секция server на test_srv в самом простом варианте получается следующей:
4. Передача https через nginx с помощью proxy pass.
Рассмотрим пример с бесплатным сертификатом Let’s Encrypt.
Очень удобно настроить на одном сервере автоматическое получение всех необходимых сертификатов.
Полная секция server нашего тестового сайта на момент получения сертификата будет выглядеть вот так:
Пересчитываем файл конфигурации nginx и получаем сертификат.
После этого файл конфигурации меняем на следующий:
Происходит проксирование с другого IP-адреса и шифрование по https.
5. Проксирование определенной директории или файлов.
Вы можете отдавать картинки с одного сервера, а все остальное с другого. В моем примере, картинки будут жить на том же сервере, где nginx, а остальной сайт на другом сервере.
6. Руководство пользователя.
Подробнее о модуле ngx_http_proxy_module можно узнать из официальной документации по nginx.
Модуль ngx_http_proxy_module
Модуль ngx_http_proxy_module позволяет передавать запросы другому серверу.
Пример конфигурации
Директивы
Эта директива появилась в версии 0.8.22.
Параметр transparent (1.11.0) позволяет задать нелокальный IP-aдрес, который будет использоваться в исходящих соединениях с проксируемым сервером, например, реальный IP-адрес клиента:
Задаёт размер буфера, в который будет читаться первая часть ответа, получаемого от проксируемого сервера. В этой части ответа находится, как правило, небольшой заголовок ответа. По умолчанию размер одного буфера равен размеру страницы памяти. В зависимости от платформы это или 4K, или 8K, однако его можно сделать меньше.
Разрешает или запрещает использовать буферизацию ответов проксируемого сервера.
Если буферизация включена, то nginx принимает ответ проксируемого сервера как можно быстрее, сохраняя его в буферы, заданные директивами proxy_buffer_size и proxy_buffers. Если ответ не вмещается целиком в память, то его часть может быть записана на диск во временный файл. Запись во временные файлы контролируется директивами proxy_max_temp_file_size и proxy_temp_file_write_size.
Если буферизация выключена, то ответ синхронно передаётся клиенту сразу же по мере его поступления. nginx не пытается считать весь ответ проксируемого сервера. Максимальный размер данных, который nginx может принять от сервера за один раз, задаётся директивой proxy_buffer_size.
Буферизация может быть также включена или выключена путём передачи значения “ yes ” или “ no ” в поле “X-Accel-Buffering” заголовка ответа. Эту возможность можно запретить с помощью директивы proxy_ignore_headers.
Задаёт число и размер буферов для одного соединения, в которые будет читаться ответ, получаемый от проксируемого сервера. По умолчанию размер одного буфера равен размеру страницы. В зависимости от платформы это или 4K, или 8K.
При включённой буферизации ответов проксируемого сервера, ограничивает суммарный размер буферов, которые могут быть заняты для отправки ответа клиенту, пока ответ ещё не прочитан целиком. Оставшиеся буферы тем временем могут использоваться для чтения ответа и, при необходимости, буферизации части ответа во временный файл. По умолчанию размер ограничен величиной двух буферов, заданных директивами proxy_buffer_size и proxy_buffers.
Задаёт зону разделяемой памяти, используемой для кэширования. Одна и та же зона может использоваться в нескольких местах. В значении параметра можно использовать переменные (1.7.9). Параметр off запрещает кэширование, унаследованное с предыдущего уровня конфигурации.
Эта директива появилась в версии 1.11.10.
Позволяет запустить фоновый подзапрос для обновления просроченного элемента кэша, в то время как клиенту возвращается устаревший закэшированный ответ. Использование устаревшего закэшированного ответа в момент его обновления должно быть разрешено.
Задаёт условия, при которых ответ не будет браться из кэша. Если значение хотя бы одного из строковых параметров непустое и не равно “0”, то ответ не берётся из кэша:
Можно использовать совместно с директивой proxy_no_cache.
Эта директива появилась в версии 1.9.7.
Задаёт ключ для кэширования, например,
По умолчанию значение директивы близко к строке
Эта директива появилась в версии 1.1.12.
Если включено, одновременно только одному запросу будет позволено заполнить новый элемент кэша, идентифицируемый согласно директиве proxy_cache_key, передав запрос на проксируемый сервер. Остальные запросы этого же элемента будут либо ожидать появления ответа в кэше, либо освобождения блокировки этого элемента, в течение времени, заданного директивой proxy_cache_lock_timeout.
Эта директива появилась в версии 1.7.8.
Эта директива появилась в версии 1.1.12.
Задаёт таймаут для proxy_cache_lock. По истечении указанного времени запрос будет передан на проксируемый сервер, однако ответ не будет закэширован.
До версии 1.7.8 такой ответ мог быть закэширован.
Эта директива появилась в версии 1.11.6.
Задаёт смещение в байтах для запросов с указанием диапазона запрашиваемых байт (byte-range requests). Если диапазон находится за указанным смещением, range-запрос будет передан на проксируемый сервер и ответ не будет закэширован.
Эта директива появилась в версии 0.7.59.
Если метод запроса клиента указан в этой директиве, то ответ будет закэширован. Методы “ GET ” и “ HEAD ” всегда добавляются в список, но тем не менее рекомендуется перечислять их явно. См. также директиву proxy_no_cache.
Задаёт число запросов, после которого ответ будет закэширован.
| Синтаксис: | proxy_cache_path путь [ levels = уровни ] [ use_temp_path = on | off ] keys_zone = имя : размер [ inactive = время ] [ max_size = размер ] [ min_free = размер ] [ manager_files = число ] [ manager_sleep = время ] [ manager_threshold = время ] [ loader_files = число ] [ loader_sleep = время ] [ loader_threshold = время ] [ purger = on | off ] [ purger_files = число ] [ purger_sleep = время ] [ purger_threshold = время ]; |
|---|---|
| Умолчание: | — |
| Контекст: | http |
Задаёт путь и другие параметры кэша. Данные кэша хранятся в файлах. Именем файла в кэше является результат функции MD5 от ключа кэширования. Параметр levels задаёт уровни иерархии кэша: можно задать от 1 до 3 уровней, на каждом уровне допускаются значения 1 или 2. Например, при использовании
имена файлов в кэше будут такого вида:
Кэшируемый ответ сначала записывается во временный файл, а потом этот файл переименовывается. Начиная с версии 0.8.9 временные файлы и кэш могут располагаться на разных файловых системах. Однако нужно учитывать, что в этом случае вместо дешёвой операции переименовывания в пределах одной файловой системы файл копируется с одной файловой системы на другую. Поэтому лучше, если кэш будет находиться на той же файловой системе, что и каталог с временными файлами. Какой из каталогов будет использоваться для временных файлов определяется параметром use_temp_path (1.7.10). Если параметр не задан или установлен в значение “ on ”, то будет использоваться каталог, задаваемый директивой proxy_temp_path для данного location. Если параметр установлен в значение “ off ”, то временные файлы будут располагаться непосредственно в каталоге кэша.
Как часть коммерческой подписки в зоне разделяемой памяти также хранится расширенная информация о кэше, поэтому для хранения аналогичного количества ключей необходимо указывать больший размер зоны. Например зоны размером в 1 мегабайт достаточно для хранения около 4 тысяч ключей.
Через минуту после старта активируется специальный процесс “cache loader”, который загружает в зону кэша информацию о ранее закэшированных данных, хранящихся на файловой системе. Загрузка также происходит итерациями. За одну итерацию загружается не более loader_files элементов (по умолчанию 100). Кроме того, время работы одной итерации ограничено параметром loader_threshold (по умолчанию 200 миллисекунд). Между итерациями делается пауза на время, заданное параметром loader_sleep (по умолчанию 50 миллисекунд).
Кроме того, следующие параметры доступны как часть коммерческой подписки:
purger = on | off Указывает, будут ли записи в кэше, соответствующие маске, удалены с диска при помощи процесса “cache purger” (1.7.12). Установка параметра в значение on (по умолчанию off ) активирует процесс “cache purger”, который проходит по всем записям в кэше и удаляет записи, соответствующие этой маске. purger_files = число Задаёт число элементов, которые будут сканироваться за одну итерацию (1.7.12). По умолчанию purger_files равен 10. purger_threshold = время Задаёт продолжительность одной итерации (1.7.12). По умолчанию purger_threshold равен 50 миллисекундам. purger_sleep = время Задаёт паузу между итерациями (1.7.12). По умолчанию purger_sleep равен 50 миллисекундам.
В версиях 1.7.3, 1.7.7 и 1.11.10 формат заголовка кэша был изменён. При обновлении на более новую версию nginx ранее закэшированные ответы будут считаться недействительными.
Эта директива появилась в версии 1.5.7.
Задаёт условия, при которых запрос будет считаться запросом на очистку кэша. Если значение хотя бы одного из строковых параметров непустое и не равно “0”, то запись в кэше с соответствующим ключом кэширования удаляется. В результате успешной операции возвращается ответ с кодом 204 (No Content).
Если ключ кэширования запроса на очистку заканчивается звёздочкой (“ * ”), то все записи в кэше, соответствующие этой маске, будут удалены из кэша. Тем не менее, эти записи будут оставаться на диске или до момента удаления из-за отсутствия обращения к данным, или до обработки их процессом “cache purger” (1.7.12), или до попытки клиента получить к ним доступ.
Эта директива появилась в версии 1.5.7.
Разрешает ревалидацию просроченных элементов кэша при помощи условных запросов с полями заголовка “If-Modified-Since” и “If-None-Match”.
Определяет, в каких случаях можно использовать устаревший закэшированный ответ. Параметры директивы совпадают с параметрами директивы proxy_next_upstream.
Параметр error также позволяет использовать устаревший закэшированный ответ при невозможности выбора проксированного сервера для обработки запроса.
Кроме того, дополнительный параметр updating разрешает использовать устаревший закэшированный ответ, если на данный момент он уже обновляется. Это позволяет минимизировать число обращений к проксированным серверам при обновлении закэшированных данных.
Использование устаревшего закэшированного ответа может также быть разрешено непосредственно в заголовке ответа на определённое количество секунд после того, как ответ устарел (1.11.10). Такой способ менее приоритетен, чем задание параметров директивы.
Чтобы минимизировать число обращений к проксированным серверам при заполнении нового элемента кэша, можно воспользоваться директивой proxy_cache_lock.
Задаёт время кэширования для разных кодов ответа. Например, директивы
задают время кэширования 10 минут для ответов с кодами 200 и 302 и 1 минуту для ответов с кодом 404.
Если указано только время кэширования,
то кэшируются только ответы 200, 301 и 302.
Кроме того, можно кэшировать любые ответы с помощью параметра any :
Параметры кэширования могут также быть заданы непосредственно в заголовке ответа. Такой способ приоритетнее, чем задание времени кэширования с помощью директивы.
Обработка одного или более из этих полей заголовка может быть отключена при помощи директивы proxy_ignore_headers.
Задаёт таймаут для установления соединения с проксированным сервером. Необходимо иметь в виду, что этот таймаут обычно не может превышать 75 секунд.
Эта директива появилась в версии 1.1.15.
Задаёт текст, который нужно изменить в атрибуте domain полей “Set-Cookie” заголовка ответа проксируемого сервера. Предположим, проксируемый сервер вернул поле заголовка “Set-Cookie” с атрибутом “ domain=localhost ”. Директива
перепишет данный атрибут в виде “ domain=example.org ”.
В строках домен и замена можно использовать переменные:
Директиву также можно задать при помощи регулярных выражений. При этом домен должен начинаться с символа “
”. Регулярное выражение может содержать именованные и позиционные выделения, а замена ссылаться на них:
На одном уровне может быть указано несколько директив proxy_cookie_domain :
Если к куке могут быть применены несколько директив, будет выбрана первая из них.
Эта директива появилась в версии 1.19.3.
Куки также можно задать при помощи регулярных выражений. При этом кука должна начинаться с символа “
На одном уровне конфигурации может быть указано несколько директив proxy_cookie_flags :
Параметр off отменяет действие всех директив proxy_cookie_flags на данном уровне.
Эта директива появилась в версии 1.1.15.
Задаёт текст, который нужно изменить в атрибуте path полей “Set-Cookie” заголовка ответа проксируемого сервера. Предположим, проксируемый сервер вернул поле заголовка “Set-Cookie” с атрибутом “ path=/two/some/uri/ ”. Директива
перепишет данный атрибут в виде “ path=/some/uri/ ”.
В строках путь и замена можно использовать переменные:
Директиву также можно задать при помощи регулярных выражений. При этом путь должен начинаться либо с символа “
”, если при сравнении следует учитывать регистр символов, либо с символов “
* ”, если регистр символов учитывать не нужно. Регулярное выражение может содержать именованные и позиционные выделения, а замена ссылаться на них:
На одном уровне может быть указано несколько директив proxy_cookie_path :
Если к куке могут быть применены несколько директив, будет выбрана первая из них.
Эта директива появилась в версии 1.7.7.
Включает поддержку диапазонов запрашиваемых байт (byte-range) для кэшированных и некэшированных ответов проксируемого сервера вне зависимости от наличия поля “Accept-Ranges” в заголовках этих ответов.
Задаёт размер корзины для хэш-таблиц, используемых директивами proxy_hide_header и proxy_set_header. Подробнее настройка хэш-таблиц обсуждается в отдельном документе.
Задаёт максимальный размер хэш-таблиц, используемых директивами proxy_hide_header и proxy_set_header. Подробнее настройка хэш-таблиц обсуждается в отдельном документе.
По умолчанию nginx не передаёт клиенту поля заголовка “Date”, “Server”, “X-Pad” и “X-Accel-. ” из ответа проксированного сервера. Директива proxy_hide_header задаёт дополнительные поля, которые не будут передаваться. Если же передачу полей нужно разрешить, можно воспользоваться директивой proxy_pass_header.
Эта директива появилась в версии 1.1.4.
Задаёт версию протокола HTTP для проксирования. По умолчанию используется версия 1.0. Для работы постоянных соединений и проверки подлинности NTLM рекомендуется версия 1.1.
Определяет, закрывать ли соединение с проксированным сервером в случае, если клиент закрыл соединение, не дождавшись ответа.
Запрещает обработку некоторых полей заголовка из ответа проксированного сервера. В директиве можно указать поля “X-Accel-Redirect”, “X-Accel-Expires”, “X-Accel-Limit-Rate” (1.1.6), “X-Accel-Buffering” (1.1.6), “X-Accel-Charset” (1.1.6), “Expires”, “Cache-Control”, “Set-Cookie” (0.8.44) и “Vary” (1.7.7).
Если не запрещено, обработка этих полей заголовка заключается в следующем:
Определяет, передавать ли клиенту проксированные ответы с кодом больше либо равным 300, или же перехватывать их и перенаправлять на обработку nginx’у с помощью директивы error_page.
Эта директива появилась в версии 1.7.7.
Ограничивает скорость чтения ответа от проксируемого сервера. Скорость задаётся в байтах в секунду. Значение 0 отключает ограничение скорости. Ограничение устанавливается на запрос, поэтому, если nginx одновременно откроет два соединения к проксируемому серверу, суммарная скорость будет вдвое выше заданного ограничения. Ограничение работает только в случае, если включена буферизация ответов проксируемого сервера.
Если включена буферизация ответов проксируемого сервера, и ответ не вмещается целиком в буферы, заданные директивами proxy_buffer_size и proxy_buffers, часть ответа может быть записана во временный файл. Эта директива задаёт максимальный размер временного файла. Размер данных, сбрасываемых во временный файл за один раз, задаётся директивой proxy_temp_file_write_size.
Значение 0 отключает возможность буферизации ответов во временные файлы.
Данное ограничение не распространяется на ответы, которые будут закэшированы или сохранены на диске.
Определяет, в каких случаях запрос будет передан следующему серверу:
Необходимо понимать, что передача запроса следующему серверу возможна только при условии, что клиенту ещё ничего не передавалось. То есть, если ошибка или таймаут возникли в середине передачи ответа клиенту, то исправить это уже невозможно.
Передача запроса следующему серверу может быть ограничена по количеству попыток и по времени.
Эта директива появилась в версии 1.7.5.
Ограничивает время, в течение которого возможна передача запроса следующему серверу. Значение 0 отключает это ограничение.
Эта директива появилась в версии 1.7.5.
Ограничивает число допустимых попыток для передачи запроса следующему серверу. Значение 0 отключает это ограничение.
Задаёт условия, при которых ответ не будет сохраняться в кэш. Если значение хотя бы одного из строковых параметров непустое и не равно “0”, то ответ не будет сохранён:
Можно использовать совместно с директивой proxy_cache_bypass.
Задаёт протокол и адрес проксируемого сервера, а также необязательный URI, на который должен отображаться location. В качестве протокола можно указать “ http ” или “ https ”. Адрес может быть указан в виде доменного имени или IP-адреса, и необязательного порта:
или в виде пути UNIX-сокета, который указывается после слова “ unix ” и заключается в двоеточия:
Если доменному имени соответствует несколько адресов, то все они будут использоваться по очереди (round-robin). Кроме того, в качестве адреса можно указать группу серверов.
В значении параметра можно использовать переменные. В этом случае, если адрес указан в виде доменного имени, имя ищется среди описанных групп серверов и если не найдено, то определяется с помощью resolver’а.
URI запроса передаётся на сервер так:
До версии 1.1.12, если proxy_pass указана без URI, в ряде случаев при изменении URI на сервер мог передаваться URI первоначального запроса вместо изменённого URI.
В ряде случаев часть URI запроса, подлежащую замене, выделить невозможно:
В этих случаях proxy_pass следует указывать без URI.
В этом случае URI, указанный в директиве, игнорируется, и на сервер передаётся изменённый URI запроса целиком.
Проксирование WebSocket требует особой настройки и поддерживается начиная с версии 1.3.13.
Разрешает передавать от проксируемого сервера клиенту запрещённые для передачи поля заголовка.
Позволяет запретить передачу исходного тела запроса на проксируемый сервер.
Позволяет запретить передачу полей заголовка исходного запроса на проксируемый сервер.
Задаёт таймаут при чтении ответа проксированного сервера. Таймаут устанавливается не на всю передачу ответа, а только между двумя операциями чтения. Если по истечении этого времени проксируемый сервер ничего не передаст, соединение закрывается.
Задаёт текст, который нужно изменить в полях заголовка “Location” и “Refresh” в ответе проксируемого сервера. Предположим, проксируемый сервер вернул поле заголовка “ Location: http://localhost:8000/two/some/uri/ ”. Директива
перепишет эту строку в виде “ Location: http://frontend/one/some/uri/ ”.
В заменяемой строке можно не указывать имя сервера:
тогда будут подставлены основное имя сервера и порт, если он отличен от 80.
Параметр default недопустим, если в proxy_pass используются переменные.
В строке замена можно использовать переменные:
В строке перенаправление тоже можно использовать (1.1.11) переменные:
Директиву также можно задать (1.1.11) при помощи регулярных выражений. При этом перенаправление должно начинаться либо с символа “
”, если при сравнении следует учитывать регистр символов, либо с символов “
* ”, если регистр символов учитывать не нужно. Регулярное выражение может содержать именованные и позиционные выделения, а замена ссылаться на них:
На одном уровне может быть указано несколько директив proxy_redirect :
Если к полям заголовка в ответе проксируемого сервера могут быть применены несколько директив, будет выбрана первая из них.
С помощью этой директивы можно также добавлять имя хоста к относительным перенаправлениям, выдаваемым проксируемым сервером:
Эта директива появилась в версии 1.7.11.
Разрешает или запрещает использовать буферизацию тела запроса клиента.
Если буферизация включена, то тело запроса полностью читается от клиента перед отправкой запроса на проксируемый сервер.
Если буферизация выключена, то тело запроса отправляется на проксируемый сервер сразу же по мере его поступления. В этом случае запрос не может быть передан следующему серверу, если nginx уже начал отправку тела запроса.
Если для отправки тела исходного запроса используется HTTP/1.1 и передача данных частями (chunked transfer encoding), то тело запроса буферизуется независимо от значения директивы, если для проксирования также не включён HTTP/1.1.
Эта директива игнорируется на Linux, Solaris и Windows.
Задаёт таймаут при передаче запроса проксированному серверу. Таймаут устанавливается не на всю передачу запроса, а только между двумя операциями записи. Если по истечении этого времени проксируемый сервер не примет новых данных, соединение закрывается.
Позволяет переопределить тело запроса, передаваемое на проксируемый сервер. В качестве значения можно использовать текст, переменные и их комбинации.
Если включено кэширование, поля заголовка “If-Modified-Since”, “If-Unmodified-Since”, “If-None-Match”, “If-Match”, “Range” и “If-Range” исходного запроса не передаются на проксируемый сервер.
Неизменённое поле заголовка запроса “Host” можно передать так:
Кроме того, можно передать имя сервера вместе с портом проксируемого сервера:
Если значение поля заголовка — пустая строка, то поле вообще не будет передаваться проксируемому серверу:
Эта директива появилась в версии 1.15.6.
Эта директива появилась в версии 1.7.8.
Задаёт файл с сертификатом в формате PEM для аутентификации на проксируемом HTTPS-сервере.
Начиная с версии 1.21.0 в имени файла можно использовать переменные.
Эта директива появилась в версии 1.7.8.
Задаёт файл с секретным ключом в формате PEM для аутентификации на проксируемом HTTPS-сервере.
Начиная с версии 1.21.0 в имени файла можно использовать переменные.
Эта директива появилась в версии 1.5.6.
Описывает разрешённые шифры для запросов к проксируемому HTTPS-серверу. Шифры задаются в формате, поддерживаемом библиотекой OpenSSL.
Полный список можно посмотреть с помощью команды “ openssl ciphers ”.
Эта директива появилась в версии 1.19.4.
Задаёт произвольные конфигурационные команды OpenSSL при установлении соединения с проксируемым HTTPS-сервером.
Директива поддерживается при использовании OpenSSL 1.0.2 и выше.
Следует учитывать, что изменение настроек OpenSSL напрямую может привести к неожиданному поведению.
Эта директива появилась в версии 1.7.0.
Указывает файл с отозванными сертификатами (CRL) в формате PEM, используемыми при проверке сертификата проксируемого HTTPS-сервера.
Эта директива появилась в версии 1.7.0.
Позволяет переопределить имя сервера, используемое при проверке сертификата проксируемого HTTPS-сервера, а также для передачи его через SNI при установлении соединения с проксируемым HTTPS-сервером.
По умолчанию используется имя хоста из URL’а, заданного директивой proxy_pass.
Эта директива появилась в версии 1.7.8.
Задаёт файл с паролями от секретных ключей, где каждый пароль указан на отдельной строке. Пароли применяются по очереди в момент загрузки ключа.
Эта директива появилась в версии 1.5.6.
Разрешает указанные протоколы для запросов к проксируемому HTTPS-серверу.
Эта директива появилась в версии 1.7.0.
Разрешает или запрещает передачу имени сервера через расширение Server Name Indication протокола TLS (SNI, RFC 6066) при установлении соединения с проксируемым HTTPS-сервером.
Определяет, использовать ли повторно SSL-сессии при работе с проксированным сервером. Если в логах появляются ошибки “ SSL3_GET_FINISHED:digest check failed ”, то можно попробовать выключить повторное использование сессий.
Эта директива появилась в версии 1.7.0.
Задаёт файл с доверенными сертификатами CA в формате PEM, используемыми при проверке сертификата проксируемого HTTPS-сервера.
Эта директива появилась в версии 1.7.0.
Разрешает или запрещает проверку сертификата проксируемого HTTPS-сервера.
Эта директива появилась в версии 1.7.0.
Устанавливает глубину проверки в цепочке сертификатов проксируемого HTTPS-сервера.
Разрешает сохранение на диск файлов. Параметр on сохраняет файлы в соответствии с путями, указанными в директивах alias или root. Параметр off запрещает сохранение файлов. Кроме того, имя файла можно задать явно с помощью строки с переменными:
Время изменения файлов выставляется согласно полученному полю “Last-Modified” в заголовке ответа. Ответ сначала записывается во временный файл, а потом этот файл переименовывается. Начиная с версии 0.8.9 временный файл и постоянное место хранения ответа могут располагаться на разных файловых системах. Однако нужно учитывать, что в этом случае вместо дешёвой операции переименовывания в пределах одной файловой системы файл копируется с одной файловой системы на другую. Поэтому лучше, если сохраняемые файлы будут находиться на той же файловой системе, что и каталог с временными файлами, задаваемый директивой proxy_temp_path для данного location.
Директиву можно использовать для создания локальных копий статических неизменяемых файлов, например, так:
Задаёт права доступа для создаваемых файлов и каталогов, например,
Ограничивает размер данных, сбрасываемых во временный файл за один раз, при включённой буферизации ответов проксируемого сервера во временные файлы. По умолчанию размер ограничен двумя буферами, заданными директивами proxy_buffer_size и proxy_buffers. Максимальный размер временного файла задаётся директивой proxy_max_temp_file_size.
Задаёт имя каталога для хранения временных файлов с данными, полученными от проксируемых серверов. В каталоге может использоваться иерархия подкаталогов до трёх уровней. Например, при такой конфигурации
временный файл будет следующего вида:
См. также параметр use_temp_path директивы proxy_cache_path.
Встроенные переменные
В модуле ngx_http_proxy_module есть встроенные переменные, которые можно использовать для формирования заголовков с помощью директивы proxy_set_header:
