Spec-Zone.ru › Apache HTTP Server

Модуль Apache mod_proxy

Описание: Сервер прокси/шлюз для нескольких протоколов
Статус: Расширение
Идентификатор модуля: proxy_module
Файл исходного кода: mod_proxy.c

Обзор

Предупреждение

Не включайте проксирование с ProxyRequests до тех пор, пока вы не защитите свой сервер. Открытые прокси-серверы представляют опасность как для вашей сети, так и для интернета в целом.

mod_proxy и связанные модули реализуют прокси/шлюз для Apache HTTP Server, поддерживая ряд популярных протоколов и несколько различных алгоритмов балансировки нагрузки. Модули сторонних разработчиков могут добавить поддержку дополнительных протоколов и алгоритмов балансировки нагрузки.

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

  • mod_proxy, который предоставляет базовые возможности проксирования
  • mod_proxy_balancer и один или несколько модулей балансировщика, если требуется балансировка нагрузки. (Дополнительная информация в mod_proxy_balancer)
  • один или несколько модулей схемы проксирования или протокола:
    Протокол Модуль
    AJP13 (протокол Apache JServe версии 1.3) mod_proxy_ajp
    CONNECT (для SSL) mod_proxy_connect
    FastCGI mod_proxy_fcgi
    ftp mod_proxy_ftp
    HTTP/0.9, HTTP/1.0 и HTTP/1.1 mod_proxy_http
    HTTP/2.0 mod_proxy_http2
    SCGI mod_proxy_scgi
    UWSGI mod_proxy_uwsgi
    WS и WSS (веб-сокеты) mod_proxy_wstunnel

Кроме того, расширенные возможности предоставляются другими модулями. Кэширование обеспечивается модулем mod_cache и связанными модулями. Возможность подключения к удаленным серверам с использованием протокола SSL/TLS обеспечивается директивами SSLProxy* модуля mod_ssl. Для использования этих функций потребуется загрузка и настройка этих дополнительных модулей.

Прямые прокси и обратные прокси/шлюзы

Apache HTTP Server может быть настроен как в режиме прямого, так и обратного прокси (также известном как шлюз).

Обычный прямой прокси — это промежуточный сервер, расположенный между клиентом и исходным сервером. Для получения содержимого с исходного сервера клиент отправляет запрос прокси, называя исходный сервер целевым. Затем прокси запрашивает содержимое у исходного сервера и возвращает его клиенту. Клиент должен быть специально настроен для использования прямого прокси для доступа к другим сайтам.

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

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

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

Типичное использование обратного прокси — предоставление пользователям интернета доступа к серверу, находящемуся за брандмауэром. Обратные прокси также могут использоваться для балансировки нагрузки между несколькими серверами back-end или для предоставления кэширования для медленного сервера back-end. Кроме того, обратные прокси могут использоваться просто для объединения нескольких серверов в одном пространстве URL.

Обратный прокси активируется с помощью директивы ProxyPass или флага [P] для директивы RewriteRule. Не нужно включать ProxyRequests для настройки обратного прокси.

Базовые примеры

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

Кроме того, если вы хотите включить кэширование, обратитесь к документации модуля mod_cache.

Обратный прокси

ProxyPass "/foo" "http://foo.example.com/bar"
ProxyPassReverse "/foo" "http://foo.example.com/bar"

Прямой прокси

ProxyRequests On
ProxyVia On

<Proxy "*">
  Require host internal.example.com
</Proxy>

Доступ через обработчик

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

Обратный прокси для скриптов PHP

<FilesMatch "\.php$">
    # Unix sockets require 2.4.7 or later
    SetHandler  "proxy:unix:/path/to/app.sock|fcgi://localhost/"
</FilesMatch>

Эта функция доступна в Apache HTTP Server 2.4.10 и более поздних версиях.

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

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

Два рабочих процесса по умолчанию имеют фиксированную конфигурацию и будут использоваться, если ни один другой рабочий процесс не соответствует запросу. Они не используют HTTP Keep-Alive или повторное использование соединений. Вместо этого TCP-соединения с исходным сервером будут открываться и закрываться для каждого запроса.

Явно настроенные рабочие процессы идентифицируются по своему URL. Обычно они создаются и настраиваются с помощью ProxyPass или ProxyPassMatch при использовании для обратного прокси:

ProxyPass "/example" "http://backend.example.com" connectiontimeout=5 timeout=30

Это создаст рабочий процесс, связанный с URL исходного сервера http://backend.example.com, который будет использовать заданные значения таймаута. При использовании в прямом прокси, рабочие процессы обычно определяются через директиву ProxySet:

ProxySet "http://backend.example.com" connectiontimeout=5 timeout=30

или, альтернативно, с помощью Proxy и ProxySet:

<Proxy "http://backend.example.com">
  ProxySet connectiontimeout=5 timeout=30
</Proxy>

Использование явно настроенных рабочих процессов в режиме прямого прокси не очень распространено, так как прямые прокси обычно взаимодействуют со многими различными исходными серверами. Явное создание рабочих процессов для некоторых исходных серверов может быть полезным, если они используются очень часто. Явно настроенные рабочие процессы сами по себе не имеют понятия о прямом или обратном проксировании. Они обобщают общее понятие взаимодействия с исходными серверами. Рабочий процесс, созданный с помощью ProxyPass для использования в обратном прокси, также будет использоваться для запросов прямого прокси, когда URL исходного сервера соответствует URL рабочего процесса, и наоборот.

URL, идентифицирующий прямой рабочий процесс, — это URL его исходного сервера, включая любые компоненты пути:

ProxyPass "/examples" "http://backend.example.com/examples"
ProxyPass "/docs" "http://backend.example.com/docs"

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

Объединение рабочих процессов

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

ProxyPass "/apps" "http://backend.example.com/" timeout=60
ProxyPass "/examples" "http://backend.example.com/examples" timeout=10

второй рабочий процесс фактически не создается. Вместо этого используется первый рабочий процесс. Преимущество заключается в том, что существует только один пул соединений, поэтому соединения чаще повторно используются. Обратите внимание, что все явно заданные атрибуты конфигурации для последующего рабочего процесса будут игнорироваться. Это будет зарегистрировано как предупреждение. В приведенном выше примере результирующее значение таймаута для URL /examples будет 60, а не 10!

Если вы хотите избежать объединения рабочих процессов, отсортируйте определения рабочих процессов по длине URL, начиная с самых длинных URL рабочих процессов. Если вы хотите максимизировать объединение рабочих процессов, используйте обратный порядок сортировки. Также обратите внимание на связанное предупреждение о порядке директивы ProxyPass.

Явно настроенные рабочие процессы бывают двух типов: прямые рабочие процессы и (балансировщики) рабочие процессы. Они поддерживают множество важных атрибутов конфигурации, которые описаны ниже в директиве ProxyPass. Те же атрибуты также можно задать с помощью ProxySet.

Набор доступных опций для прямого рабочего процесса зависит от протокола, указанного в URL исходного сервера. Доступные протоколы включают ajp, fcgi, ftp, http и scgi.

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

Рабочий процесс балансировщика создается, если его URL рабочего процесса использует balancer в качестве схемы протокола. URL балансировщика уникально идентифицирует рабочий процесс балансировщика. Члены добавляются в балансировщик с помощью BalancerMember.

Разрешение DNS для доменов исходных серверов

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

Управление доступом к вашему прокси

Вы можете управлять тем, кто может получить доступ к вашему прокси, с помощью блока управления <Proxy> , как в следующем примере:

<Proxy "*">
  Require ip 192.168.0
</Proxy>

Дополнительную информацию о директивах управления доступом см. в mod_authz_host.

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

См. также переменную среды Proxy-Chain-Auth.

Замедленная загрузка

Если вы используете директиву ProxyBlock, IP-адреса хостов ищут и кэшируют во время запуска для последующих проверок соответствия. Это может занять несколько секунд (или больше), в зависимости от скорости поиска хостов.

Прокси для внутренней сети

Прокси-сервер Apache httpd, расположенный во внутренней сети, должен пересылать внешние запросы через корпоративный брандмауэр (для этого настройте директиву ProxyRemote для пересылки соответствующего scheme на прокси-сервер брандмауэра). Однако, при доступе к ресурсам внутри внутренней сети, он может обойти брандмауэр при обращении к хостам. Директива NoProxy полезна для указания, какие хосты относятся к внутренней сети и должны обрабатываться напрямую.

Пользователи внутри внутренней сети часто опускают имя локального домена из своих запросов WWW, запрашивая «http://somehost/» вместо http://somehost.example.com/. Некоторые коммерческие прокси-серверы позволяют им это делать и просто обрабатывают запрос, подразумевая настроенный локальный домен. Когда используется директива ProxyDomain и сервер настроен для прокси-обслуживания, Apache httpd может вернуть ответ перенаправления и направить клиента на правильный, полностью квалифицированный, адрес сервера. Это предпочтительный метод, так как файлы закладок пользователя будут содержать полностью квалифицированные хосты.

Настройки протокола

В ситуациях, когда mod_proxy отправляет запросы на сервер происхождения, который не реализует keep-alive или HTTP/1.1 должным образом, существуют две переменные окружения, которые могут заставить запрос использовать HTTP/1.0 без keep-alive. Они задаются с помощью директивы SetEnv.

Это force-proxy-request-1.0 и proxy-nokeepalive заметки.

<Location "/buggyappserver/">
  ProxyPass "http://buggyappserver:7001/foo/"
  SetEnv force-proxy-request-1.0 1
  SetEnv proxy-nokeepalive 1
</Location>

В версиях 2.4.26 и более поздних можно установить переменную среды «no-proxy», чтобы отключить mod_proxy обработку текущего запроса. Эта переменная должна быть установлена с помощью SetEnvIf, так как SetEnv не оценивается достаточно рано.

Тела запросов

Некоторые методы запросов, такие как POST, включают тело запроса. Протокол HTTP требует, чтобы запросы, содержащие тело, либо использовали кодировку chunked transfer, либо отправляли заголовок запроса Content-Length. При передаче этих запросов на сервер происхождения, mod_proxy_http всегда будет пытаться отправить Content-Length. Но если тело большое, а исходный запрос использовал кодировку chunked, то кодировка chunked может быть использована и в запросе к серверу. Вы можете управлять этим выбором с помощью переменных окружения. Установка proxy-sendcl обеспечивает максимальную совместимость с серверами происхождения, всегда отправляя Content-Length, в то время как установка proxy-sendchunked минимизирует использование ресурсов, используя кодировку chunked.

В некоторых случаях серверу необходимо буферизовать тела запросов на диске для удовлетворения запрошенной обработки тел запросов. Например, эта буферизация произойдет, если исходное тело было отправлено с кодировкой chunked (и является большим), но администратор попросил отправлять запросы к бэкенду с Content-Length или как HTTP/1.0. Эта буферизация также может произойти, если тело запроса уже имеет заголовок Content-Length, но сервер настроен на фильтрацию входящих тел запросов.

LimitRequestBody относится только к телам запросов, которые сервер будет буферизовать на диске

Заголовки запроса обратного прокси

При работе в режиме обратного прокси (например, с помощью директивы ProxyPass), mod_proxy_http добавляет несколько заголовков запроса, чтобы передать информацию на сервер происхождения. Эти заголовки:

X-Forwarded-For
IP-адрес клиента.
X-Forwarded-Host
Исходный хост, запрошенный клиентом в заголовке HTTP-запроса Host.
X-Forwarded-Server
Имя хоста прокси-сервера.

Будьте осторожны при использовании этих заголовков на сервере происхождения, так как они могут содержать более одного (разделенного запятой) значения, если исходный запрос уже содержал один из этих заголовков. Например, вы можете использовать %{X-Forwarded-For}i в строке формата журнала сервера происхождения для протоколирования IP-адреса исходного клиента, но вы можете получить более одного адреса, если запрос проходит через несколько прокси-серверов.

См. также директивы ProxyPreserveHost и ProxyVia, которые контролируют другие заголовки запроса.

Примечание: Если вам нужно указать пользовательские заголовки запроса, которые нужно добавить к пересылаемому запросу, используйте директиву RequestHeader.

Директива BalancerGrowth

Описание: Количество дополнительных балансировщиков, которые можно добавить после настройки
Синтаксис:
BalancerGrowth #
Значение по умолчанию:
BalancerGrowth 5
Контекст: настройки сервера, виртуальный хост
Статус: Расширение
Модуль: mod_proxy
Совместимость: BalancerGrowth доступен только в Apache HTTP Server 2.3.13 и более поздних версиях.

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

Директива BalancerInherit

Описание: Наследовать прокси-балансировщики/рабочие процессы от основного сервера
Синтаксис:
BalancerInherit On|Off
Значение по умолчанию:
BalancerInherit On
Контекст: настройки сервера, виртуальный хост
Статус: Расширение
Модуль: mod_proxy
Совместимость: BalancerInherit доступен только в Apache HTTP Server 2.4.5 и более поздних версиях.

Эта директива заставит текущий сервер/виртуальный хост «унаследовать» ProxyPass балансировщики и рабочие процессы, определенные на основном сервере. Это может вызвать проблемы и несогласованное поведение при использовании менеджера балансировщиков, поэтому следует отключить эту функцию при использовании данного инструмента.

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

Директива BalancerMember

Описание: Добавить участника в группу балансировки нагрузки
Синтаксис:
BalancerMember [balancerurl] url [key=value [key=value ...]]
Контекст: каталог
Статус: Расширение
Модуль: mod_proxy
Совместимость: BalancerMember доступен только в Apache HTTP Server 2.2 и более поздних версиях.

Эта директива добавляет участника в группу балансировки нагрузки. Она может использоваться внутри директивы контейнера <Proxy balancer://...> и может принимать любые пары ключ-значение, доступные для директивы ProxyPass.

Доступна одна дополнительная пара ключ-значение только для директивы BalancerMember: loadfactor. Это коэффициент нагрузки участника — десятичное число от 1,0 (по умолчанию) до 100,0, которое определяет взвешенную нагрузку, которая будет применена к данному участнику.

balancerurl требуется только тогда, когда вы не находитесь внутри директивы контейнера <Proxy balancer://...>. Она соответствует URL балансировщика, определенному в директиве ProxyPass.

Компонент пути в URL балансировщика в любой директиве контейнера <Proxy balancer://...> игнорируется.

Следующие косые черты обычно следует удалять из URL BalancerMember.

Директива BalancerPersist

Описание: Попытка сохранить изменения, внесенные менеджером балансировщиков, после перезагрузки.
Синтаксис:
BalancerPersist On|Off
Значение по умолчанию:
BalancerPersist Off
Контекст: настройки сервера, виртуальный хост
Статус: Расширение
Модуль: mod_proxy
Совместимость: BalancerPersist доступен только в Apache HTTP Server 2.4.4 и более поздних версиях.

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

END_OF_DOCUMENT_MARKER

Директива NoProxy

Описание: Хосты, домены или сети, которые будут подключаться напрямую
Синтаксис:
NoProxy host [host] ...
Контекст: настройка сервера, виртуальный хост
Статус: Расширение
Модуль: mod_proxy

Эта директива полезна только для серверов прокси Apache httpd внутри интрасетей. Директива NoProxy задает список подсетей, IP-адресов, хостов и/или доменов, разделенных пробелами. Запрос к хосту, который соответствует одному или нескольким из этих элементов, всегда обслуживается напрямую, без перенаправления на конфигурированный ProxyRemote сервер(ы) прокси.

Пример

ProxyRemote  "*"  "http://firewall.example.com:81"
NoProxy         ".example.com" "192.168.112.0/21"

Аргументы host для директивы NoProxy могут быть одного из следующих типов:

Домен

Домен — это частично квалифицированное имя домена DNS, предваряемое точкой. Он представляет список хостов, которые логически принадлежат тому же домену DNS или зоне (т.е., суффиксы имён хостов заканчиваются на Домен).

Примеры

.com .example.org.

Чтобы отличить Домены от Имен хостов (как синтаксически, так и семантически; домен DNS также может иметь запись DNS A!), Домены всегда пишутся с ведущей точкой.

Примечание

Сравнения имён доменов выполняются без учета регистра, и Домены всегда предполагаются закреплёнными в корне дерева DNS; поэтому два домена .ExAmple.com и .example.com. (обратите внимание на конечную точку) считаются равными. Поскольку сравнение доменов не требует выполнения DNS-запроса, оно гораздо эффективнее, чем сравнение подсетей.

Подсеть

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

192.168 или 192.168.0.0
подсеть 192.168.0.0 с неявной маской в 16 значимых битах (иногда используется в виде маски 255.255.0.0).
192.168.112.0/21
подсеть 192.168.112.0/21 с маской в 21 значимый бит (также используется в виде маски 255.255.248.0).

В качестве вырожденного случая, Подсеть с 32 значимыми битами эквивалентна IPAddr, а Подсеть с нулём значимых битов (например, 0.0.0.0/0) эквивалентна константе _Default_, соответствующей любому IP-адресу.

IPAddr

IPAddr представляет собой полностью квалифицированный интернет-адрес в числовом (точечный квад) формате. Обычно этот адрес представляет хост, но с ним необязательно должен быть связан DNS-домен.

Пример

192.168.123.7

Примечание

IPAddr не требуется разрешать системой DNS, поэтому он может обеспечить более эффективную работу Apache.

Имя хоста

Имя хоста — это полностью квалифицированное имя домена DNS, которое может быть разрешено до одного или нескольких IPAddrs через службу доменных имён DNS. Он представляет собой логический хост (в отличие от Доменов, см. выше) и должен быть разрешим хотя бы до одного IPAddr (или, часто, до списка хостов с различными IPAddr).

Примеры

prep.ai.example.edu
www.example.org

Примечание

Во многих ситуациях эффективнее указать IPAddr вместо Имени хоста, поскольку можно избежать разрешения DNS. Разрешение имён в Apache httpd может занимать значительное время, когда соединение с сервером имён использует медленный PPP-канал.

Сравнения Имен хостов выполняются без учета регистра, и Имена хостов всегда предполагаются закреплёнными в корне дерева DNS; поэтому два хоста WWW.ExAmple.com и www.example.com. (обратите внимание на конечную точку) считаются равными.

См. также

  • Проблемы DNS

<Proxy> Директива

Описание: Контейнер для директив, применяемых к проксируемым ресурсам
Синтаксис:
<Proxy wildcard-url> ...</Proxy>
Контекст: настройка сервера, виртуальный хост
Статус: Расширение
Модуль: mod_proxy

Директивы, помещённые в <Proxy> секции, применяются только к соответствующему проксируемому содержимому. Разрешены оболочки-маски в стиле shell.

Например, следующее позволит только хостам в yournetwork.example.com получать доступ к содержимому через ваш прокси-сервер:

<Proxy "*">
  Require host yournetwork.example.com
</Proxy>

Следующий пример обработает все файлы в каталоге foo из example.com через фильтр INCLUDES при передаче через прокси-сервер:

<Proxy "http://example.com/foo/*">
  SetOutputFilter INCLUDES
</Proxy>

Различия от раздела конфигурации Location

URL бэкенда соответствует разделу конфигурации, если он начинается с строки wildcard-url, даже если последний сегмент пути в директиве соответствует только префиксу URL бэкенда. Например, <Proxy "http://example.com/foo"> соответствует всем http://example.com/foo, http://example.com/foo/bar и http://example.com/foobar. Соответствие конечного URL отличается от поведения раздела <Location>, который в целях этой заметки обрабатывает конечный компонент пути как будто он заканчивается слешем.

Для большего контроля над соответствием см. <ProxyMatch>.

См. также

  • <ProxyMatch>

Директива Proxy100Continue

Описание: Передача ожидания 100-continue на сервер происхождения
Синтаксис:
Proxy100Continue Off|On
Значение по умолчанию:
Proxy100Continue On
Контекст: настройка сервера, виртуальный хост, каталог
Статус: Расширение
Модуль: mod_proxy
Совместимость: Доступно в версии 2.4.40 и более поздних

Эта директива определяет, следует ли прокси пересылать ожидание 100-continue Expect: на сервер происхождения, чтобы он определял, когда/если следует читать тело HTTP-запроса, или когда Off прокси сам должен сгенерировать промежуточный ответ 100 Continue перед пересылкой тела запроса.

Эффективность

Этот параметр полезен только для проксирования HTTP, как обрабатывается mod_proxy_http.

Директива ProxyAddHeaders

Описание: Добавление прокси-информации в заголовки X-Forwarded-*
Синтаксис:
ProxyAddHeaders Off|On
Значение по умолчанию:
ProxyAddHeaders On
Контекст: настройка сервера, виртуальный хост, каталог
Статус: Расширение
Модуль: mod_proxy
Совместимость: Доступно в версии 2.3.10 и более поздних

Эта директива определяет, передавать ли информацию о прокси на сервер бэкенда через HTTP-заголовки X-Forwarded-For, X-Forwarded-Host и X-Forwarded-Server.

Эффективность

Этот параметр полезен только для проксирования HTTP, как обрабатывается mod_proxy_http.

Директива ProxyBadHeader

Описание: Определяет, как обрабатывать некорректные строки заголовков в ответе
Синтаксис:
ProxyBadHeader IsError|Ignore|StartBody
Значение по умолчанию:
ProxyBadHeader IsError
Контекст: настройка сервера, виртуальный хост
Статус: Расширение
Модуль: mod_proxy

Директива ProxyBadHeader определяет поведение mod_proxy при получении от сервера происхождения синтаксически некорректных строк заголовков (т.е. содержащих двоеточие). Доступны следующие аргументы:

IsError
Прервать запрос и получить ответ 502 (Bad Gateway). Это поведение по умолчанию.
Ignore
Обрабатывать некорректные строки заголовков так, как если бы они не были отправлены.
StartBody
При получении первой некорректной строки заголовка завершить чтение заголовков и обрабатывать оставшуюся часть как тело. Это помогает обойти ошибочные бэкенд-серверы, которые забывают вставить пустую строку между заголовками и телом.

Директива ProxyBlock

Описание: Слова, хосты или домены, которые запрещено проксировать
Синтаксис:
ProxyBlock *|word|host|domain [word|host|domain] ...
Контекст: настройка сервера, виртуальный хост
Статус: Расширение
Модуль: mod_proxy

Директива ProxyBlock задает список слов, хостов и/или доменов, разделенных пробелами. Запросы документов HTTP, HTTPS и FTP к сайтам, имена которых содержат совпадающие слова, хосты или домены, блокируются прокси-сервером. Модуль прокси также попытается определить IP-адреса элементов списка, которые могут быть именами хостов во время запуска, и кэшировать их для проверки соответствия. Это может замедлить время запуска сервера.

Пример

ProxyBlock "news.example.com" "auctions.example.com" "friends.example.com"

Обратите внимание, что example также будет достаточно для соответствия любому из этих сайтов.

Хосты также будут соответствовать, если ссылаться на них по IP-адресу.

Также обратите внимание,

ProxyBlock "*"

блокирует соединения со всеми сайтами.

Директива ProxyDomain

Описание: По умолчанию доменное имя для запросов прокси
Синтаксис:
ProxyDomain Domain
Контекст: конфигурация сервера, виртуальный хост
Статус: Расширение
Модуль: mod_proxy

Эта директива полезна только для серверов прокси Apache httpd внутри интрасетей. Директива ProxyDomain задает по умолчанию домен, к которому будет принадлежать сервер прокси apache. Если встретится запрос на хост без имени домена, будет сгенерирован ответ перенаправления на тот же хост с добавленным в конец сконфигурированным значением Domain.

Пример

ProxyRemote  "*"  "http://firewall.example.com:81"
NoProxy         ".example.com" "192.168.112.0/21"
ProxyDomain     ".example.com"

Директива ProxyErrorOverride

Описание: Переопределение страниц ошибок для проксируемого контента
Синтаксис:
ProxyErrorOverride Off|On [code ...]
Значение по умолчанию:
ProxyErrorOverride Off
Контекст: конфигурация сервера, виртуальный хост, директория
Статус: Расширение
Модуль: mod_proxy
Совместимость: Список кодов состояния был добавлен в версии 2.5.1

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

Эта директива не влияет на обработку информационных (1xx), нормальных успешных (2xx) или перенаправляющих (3xx) ответов.

По умолчанию ProxyErrorOverride влияет на все ответы с кодами между 400 (включительно) и 600 (исключительно).

Пример для поведения по умолчанию

ProxyErrorOverride  On

Для изменения поведения по умолчанию можно указать коды состояний для рассмотрения, разделенные пробелами. В этом случае все остальные коды состояния будут игнорироваться. Можно указывать только коды состояния, которые считаются кодами ошибок: между 400 (включительно) и 600 (исключительно).

Пример для пользовательских кодов состояния

ProxyErrorOverride  On 403 405 500 501 502 503 504

Директива ProxyIOBufferSize

Описание: Определение размера внутреннего буфера передачи данных
Синтаксис:
ProxyIOBufferSize bytes
Значение по умолчанию:
ProxyIOBufferSize 8192
Контекст: конфигурация сервера, виртуальный хост
Статус: Расширение
Модуль: mod_proxy

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

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

При использовании с AJP эта директива устанавливает максимальный размер пакета AJP в байтах. Значения, превышающие 65536, устанавливаются в 65536. Если вы изменяете это значение от значения по умолчанию, вы должны также изменить атрибут packetSize вашего подключения AJP на стороне Tomcat! Атрибут packetSize доступен только в Tomcat 5.5.20+ и 6.0.2+

Обычно не требуется изменять максимальный размер пакета. Были сообщения о проблемах с значением по умолчанию при отправке сертификатов или цепочек сертификатов.

<ProxyMatch> Директива

Описание: Контейнер для директив, применяемых к проксируемым ресурсам, соответствующим регулярному выражению
Синтаксис:
<ProxyMatch regex> ...</ProxyMatch>
Контекст: конфигурация сервера, виртуальный хост
Статус: Расширение
Модуль: mod_proxy

Директива <ProxyMatch> идентична директиве <Proxy>, за исключением того, что она сопоставляет URL-адреса с помощью регулярных выражений.

Начиная с версии 2.4.8, именованные группы и ссылки на обратные совпадения (backreferences) записываются в среду с соответствующим именем, префиксным «MATCH_» и заглавными буквами. Это позволяет ссылаться на элементы URL-адресов из выражений и модулей, таких как mod_rewrite. Для предотвращения путаницы, пронумерованные (безымянные) backreferences игнорируются. Используйте именованные группы.

<ProxyMatch "^http://(?<sitename>[^/]+)">
    Require ldap-group cn=%{env:MATCH_SITENAME},ou=combined,o=Example
</ProxyMatch>

См. также

  • <Proxy>

Директива ProxyMaxForwards

Описание: Максимальное количество прокси, через которое может быть перенаправлен запрос
Синтаксис:
ProxyMaxForwards number
Значение по умолчанию:
ProxyMaxForwards -1
Контекст: конфигурация сервера, виртуальный хост
Статус: Расширение
Модуль: mod_proxy
Совместимость: Поведение по умолчанию изменено в версии 2.2.7

Директива ProxyMaxForwards указывает максимальное количество прокси, через которое запрос может пройти, если запрос не содержит заголовка Max-Forwards. Это может быть установлено для предотвращения бесконечных циклов прокси или атак типа DoS.

Пример

ProxyMaxForwards 15

Обратите внимание, что установка ProxyMaxForwards нарушает протокол HTTP/1.1 (RFC2616), который запрещает установку Proxy Max-Forwards, если клиент его не установил. Более ранние версии Apache httpd всегда его устанавливали. Отрицательное значение ProxyMaxForwards, включая значение по умолчанию -1, обеспечивает соответствие протоколу, но может оставить вас открытыми для циклов.

Директива ProxyPass

Описание: Отображает удаленные серверы в адресном пространстве локального сервера
Синтаксис:
ProxyPass [path] !|url [key=value [key=value ...]] [nocanon] [interpolate] [noquery]
Контекст: настройка сервера, виртуальный хост, директория
Статус: Расширение
Модуль: mod_proxy
Совместимость: Поддержка Unix Domain Socket (UDS) добавлена в версии 2.4.7

Данная директива позволяет отображать удалённые серверы в адресном пространстве локального сервера. Локальный сервер не действует как прокси в традиционном смысле, а скорее как зеркало удалённого сервера. Локальный сервер часто называют обратным прокси или шлюзом. path — имя локального виртуального пути; url — частичный URL удалённого сервера и не может содержать строку запроса.

Перед дальнейшим изучением этой секции настоятельно рекомендуется ознакомиться с концепцией Worker.
Данная директива не поддерживается в <Directory>, <If> и <Files> контейнерах.
Директива ProxyRequests обычно должна быть выключена при использовании ProxyPass.

В версиях 2.4.7 и выше доступна поддержка использования Unix Domain Socket, используя целевой путь, начинающийся с unix:/path/lis.sock|. Например, чтобы проксировать HTTP и направить запрос на UDS по адресу /home/www.socket, используйте unix:/home/www.socket|http://localhost/whatever/.

Примечание: Путь, связанный с unix: URL, является DefaultRuntimeDir-осознанным.

При использовании внутри <Location> секции, первый аргумент опускается, а локальная директория берётся из <Location>. То же самое произойдёт внутри <LocationMatch> секции; однако, ProxyPass не интерпретирует регулярное выражение как таковое, поэтому в этом случае необходимо использовать ProxyPassMatch.

Предположим, что локальный сервер имеет адрес http://example.com/; тогда

<Location "/mirror/foo/">
    ProxyPass "http://backend.example.com/"
</Location>

приведёт к тому, что локальный запрос к http://example.com/mirror/foo/bar будет внутренне преобразован в запрос прокси к http://backend.example.com/bar.

Если вам нужна более гибкая настройка обратного прокси, обратитесь к директиве RewriteRule с флагом [P].

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

ProxyPass "/mirror/foo/" "http://backend.example.com/"

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

Директива ! полезна в ситуациях, когда вы не хотите проксировать поддиректорию, например

<Location "/mirror/foo/">
    ProxyPass "http://backend.example.com/"
</Location>
<Location "/mirror/foo/i">
    ProxyPass "!"
</Location>
ProxyPass "/mirror/foo/i" "!"
ProxyPass "/mirror/foo" "http://backend.example.com"

будет проксировать все запросы к /mirror/foo к backend.example.com за исключением запросов, отправленных к /mirror/foo/i.

Смешивание настроек ProxyPass в разных контекстах не работает:

ProxyPass "/mirror/foo/i" "!"
<Location "/mirror/foo/">
    ProxyPass "http://backend.example.com/"
</Location>

В этом случае запрос к /mirror/foo/i будет проксирован, потому что директива ProxyPass в блоке Location будет обработана первой. Тот факт, что ProxyPass поддерживает контексты сервера и директорий, не означает, что их область действия и положение в файле конфигурации гарантируют порядок или переопределение.

Порядок директив ProxyPass

Настроенные правила ProxyPass и ProxyPassMatch проверяются в порядке конфигурации. Первое совпадающее правило применяется. Поэтому обычно следует сортировать конфликтующие правила ProxyPass по убыванию длины URL-адресов, начиная с самых длинных. В противном случае, более поздние правила для более длинных URL-адресов будут скрыты любым более ранним правилом, использующим начальный подстроку URL-адреса. Обратите внимание, что существует некоторая взаимосвязь с разделением worker.

Порядок директив ProxyPass в блоках Location

Только одна директива ProxyPass может быть размещена в блоке Location и самое конкретное расположение имеет приоритет.

Исключения и переменная среды no-proxy

Исключения должны идти перед общими директивами ProxyPass. В версиях 2.4.26 и выше, переменная среды "no-proxy" является альтернативой исключениям и единственный способ настроить исключение директивы ProxyPass в контексте Location. Эта переменная должна быть установлена с помощью SetEnvIf, так как SetEnv не оценивается достаточно рано.

Параметры ProxyPass key=value

В Apache HTTP Server 2.1 и более поздних версиях, mod_proxy поддерживает пулы подключений к бэкенд-серверу. Созданные по требованию подключения могут храниться в пуле для дальнейшего использования. Ограничения на размер пула и другие настройки могут быть заданы в директиве ProxyPass с использованием параметров key=value, описанных в таблицах ниже.

Максимальное количество подключений к бэкенду

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

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

Пример

ProxyPass "/example" "http://backend.example.com" max=20 ttl=120 retry=300
Параметры Worker|BalancerMember
Параметр Значение по умолчанию Описание
min 0 Минимальное количество записей в пуле подключений, не связанное с фактическим количеством подключений. Изменять это значение от значения по умолчанию необходимо только в особых случаях, когда требуется предварительная выделение или сохранение оперативной памяти, связанной с подключениями к бэкенду.
max 1...n Максимальное количество подключений, которое будет разрешено к серверу бэкенда. Значение по умолчанию для этого ограничения — количество потоков на процесс в активном MPM. В MPM Prefork это всегда 1, а в других MPM — контролируется директивой ThreadsPerChild.
smax max Записи в пуле подключений, хранящиеся сверх этого предела, освобождаются во время определенных операций, если они не использовались в течение времени, контролируемого параметром ttl. Если запись в пуле подключений имеет связанное подключение, оно будет закрыто. Изменять это значение от значения по умолчанию необходимо только в особых случаях, когда записи в пуле подключений и любые связанные подключения, превысившие время существования, должны быть освобождены или закрыты более агрессивно.
acquire - Если установлено, это будет максимальное время ожидания свободного подключения в пуле подключений в миллисекундах. Если в пуле нет свободных подключений, Apache httpd вернет клиенту статус SERVER_BUSY.
connectiontimeout timeout Тайм-аут установления соединения в секундах. Количество секунд, которое Apache httpd ждет завершения создания подключения к серверу бэкенда. Добавление суффикса ms позволяет задать тайм-аут в миллисекундах.
disablereuse Off Этот параметр необходимо использовать, когда вы хотите заставить mod_proxy немедленно закрыть подключение к бэкенду после использования, тем самым отключив постоянное подключение и пул для этого бэкенда. Это помогает в различных ситуациях, когда брандмауэр между Apache httpd и сервером бэкенда (независимо от протокола) имеет тенденцию к безмолвному разрыву подключений или когда бэкенды могут находиться под управлением DNS-балансировки. Когда повторное использование подключений включено, каждый домен бэкенда разрешается (с запросом DNS) только один раз на процесс-потомка и кэшируется для всех последующих подключений до перезапуска процесса-потомка. Для отключения повторного использования подключений установите значение этого свойства в On.
enablereuse On Это обратное значение для 'disablereuse' выше, предоставленное для удобства обработчиков схем, которые требуют явного включения повторного использования подключений (например, mod_proxy_fcgi). 2.4.11 и более поздние версии.
flushpackets off Определяет, будет ли модуль прокси автоматически сбрасывать выходной пакет после каждого "фрагмента" данных. 'off' означает, что сброс выполняется только при необходимости; 'on' — после отправки каждого фрагмента; а 'auto' — проверять/ждать определенное время и сбрасывать, если за это время не было получено входных данных в течение 'flushwait' миллисекунд. В настоящее время это эффективно только для mod_proxy_ajp и mod_proxy_fcgi.
flushwait 10 Время ожидания дополнительных входных данных в миллисекундах перед сбросом выходного пакета, если 'flushpackets' равно 'auto'.
iobuffersize 8192 Изменяет размер внутренней буфера IO для временного хранения данных. Это позволяет переопределить ProxyIOBufferSize для конкретного рабочего процесса. Это значение должно быть как минимум 512 или равно 0 для использования системного значения по умолчанию 8192.
responsefieldsize 8192 Изменяет размер буфера поля ответа прокси. Размер буфера должен быть не меньше размера самого большого ожидаемого размера заголовка ответа проксируемого объекта. Установка значения в 0 использует системное значение по умолчанию 8192 байта.
Доступно в Apache HTTP Server 2.4.34 и более поздних версиях.
keepalive Off

Этот параметр следует использовать, когда между вашим Apache httpd и сервером бэкенда есть брандмауэр, который имеет тенденцию к разрыву неактивных подключений. Этот флаг укажет операционной системе отправлять сообщения KEEP_ALIVE на неактивных подключениях, тем самым предотвращая разрыв соединения брандмауэром. Для включения keepalive установите значение этого свойства в On.

Частота начальных и последующих зондов TCP keepalive зависит от глобальных настроек ОС и может составлять до 2 часов. Для эффективности, частота, настроенная в ОС, должна быть меньше порога, используемого брандмауэром.

lbset 0 Устанавливает набор кластеров балансировщика нагрузки, к которому принадлежит рабочий процесс. Балансировщик нагрузки попытается обработать все члены с более низким номером lbset, прежде чем обработать члены с более высоким номером.
ping 0 Параметр ping сообщает веб-серверу "проверить" подключение к бэкенду перед пересылкой запроса. Для AJP, он заставляет mod_proxy_ajp отправить запрос CPING по подключению ajp13 (реализовано в Tomcat 3.3.2+, 4.1.28+ и 5.0.13+). Для HTTP он заставляет mod_proxy_http отправить запрос 100-Continue бэкенду (действительно только для HTTP/1.1 — для бэкендов, не поддерживающих HTTP/1.1, этот параметр не имеет эффекта). В обоих случаях, параметр — задержка в секундах ожидания ответа. Эта функция добавлена для предотвращения проблем с зависшими и загруженными бэкендами. Это увеличит сетевой трафик во время нормальной работы, что может быть проблемой, но уменьшит трафик, если некоторые узлы кластера недоступны или перегружены. Добавление суффикса ms позволяет задать задержку в миллисекундах.
receivebuffersize 0 Изменяет размер явного (TCP/IP) сетевого буфера для прокси-соединений. Это позволяет переопределить ProxyReceiveBufferSize для конкретного рабочего процесса. Это значение должно быть как минимум 512 или равно 0 для использования системного значения по умолчанию.
redirect - Маршрут перенаправления рабочего процесса. Это значение обычно устанавливается динамически для безопасного удаления узла из кластера. Если установлено, все запросы без идентификатора сессии будут перенаправлены на BalancerMember, у которого параметр маршрута равен этому значению.
retry 60 Тайм-аут повторной попытки рабочего процесса пула подключений в секундах. Если рабочий процесс пула подключений к серверу бэкенда находится в состоянии ошибки, Apache httpd не будет пересылать запросы на этот сервер до истечения тайм-аута. Это позволяет выключить сервер бэкенда для обслуживания и включить его позже. Значение 0 означает, что рабочие процессы в состоянии ошибки всегда будут перепробованы без тайм-аута.
route - Маршрут рабочего процесса при использовании внутри балансировщика нагрузки. Маршрут — это значение, добавляемое к идентификатору сессии.
status - Односимвольное значение, определяющее начальное состояние этого рабочего процесса.
D: Рабочий процесс отключен и не будет принимать запросы.
S: Рабочий процесс административно остановлен.
I: Рабочий процесс в режиме игнорирования ошибок и всегда будет считаться доступным.
R: Рабочий процесс является резервным. Для каждого недоступного рабочего процесса в заданном lbset (отключение, остановка, ошибка и т. д.) будет использоваться доступный резервный рабочий процесс с тем же lbset. Резервные рабочие процессы могут помочь гарантировать, что определенное количество рабочих процессов всегда будет доступно для использования балансировщиком.
H: Рабочий процесс в режиме горячего резервирования и будет использоваться только если другие доступные рабочие процессы или резервные процессы в наборе балансировщиков недоступны.
E: Рабочий процесс в состоянии ошибки.
N: Рабочий процесс в режиме отключения и будет принимать только существующие «привязанные» сессии, предназначенные для него, и игнорировать все другие запросы.
Состояние может быть установлено (что является значением по умолчанию) добавлением '+' или сброшено добавлением '-'. Таким образом, значение 'S-E' устанавливает рабочий процесс в состояние остановки и сбрасывает флаг ошибки.
timeout ProxyTimeout Тайм-аут соединения в секундах. Количество секунд, которое Apache httpd ждет данных, отправленных/полученных от бэкенда.
ttl - Время жизни неактивных подключений и соответствующих записей в пуле подключений в секундах. После достижения этого предела подключение больше не будет использоваться; оно будет закрыто в какой-то момент позже.
flusher flush

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

secret - Значение секрета, используемого mod_proxy_ajp. Оно должно быть идентичным секрету, настроенному на стороне сервера AJP-соединения.
Доступно в Apache HTTP Server 2.4.42 и более поздних версиях.
upgrade WebSocket

Протокол, принятый в заголовке Upgrade mod_proxy_wstunnel. Смотрите документацию этого модуля для получения дополнительной информации.

mapping -

Тип сопоставления между путем и адресом. Это определяет нормализацию и/или (не)декодирование, которое mod_proxy применит к запрошенному uri-пути перед сопоставлением с путем. Если сопоставление найдено, оно применяется к uri-пути, таким образом, все контексты каталогов, использующие путь (например, <Location> ), будут сопоставляться с использованием того же сопоставления.

mapping=encoded предотвращает %-декодирование uri-пути, чтобы можно было использовать, например, такие конфигурации:

ProxyPass "/special%3Fsegment" "https://example.com/special%3Fsegment" mapping=encoded
<Location "/special%3Fsegment">
  Require ip 172.17.2.0/24
</Location>

mapping=servlet относится к нормализации, определенной спецификацией Servlet, которая, например, применяется Apache Tomcat для контейнеров Servlet (в частности, параметры пути игнорируются для сопоставления). uri-путь , например, /some;foo/path , сопоставляется как /some/path , поэтому соответствует любому из следующих, независимо от запрошенных параметров пути:

ProxyPass "/some/path" "https://servlet.example.com/some/path" mapping=servlet
<Location "/some/path">
  Require valid-user
</Location>

Примечание

Рекомендуется использовать то же сопоставление на стороне Apache httpd, что и на стороне бэкенда. Например, при настройке авторизаций в блоках <Location> для путей, которые сопоставляются mod_proxy с некоторыми контейнерами Servlet (например, приложения, запущенные в Apache Tomcat), следует использовать настройку mapping=servlet для предотвращения того, чтобы параметры пути и им подобные мешали авторизациям, которые должны быть реализованы Apache httpd.

Если схема директивы Proxy начинается с balancer:// (например: balancer://cluster, любая информация о пути игнорируется), тогда создается виртуальный рабочий процесс, который не взаимодействует напрямую с сервером бэкенда. Вместо этого он отвечает за управление несколькими "реальными" рабочими процессами. В этом случае к этому виртуальному рабочему процессу можно добавить специальный набор параметров. См. mod_proxy_balancer для получения дополнительной информации о работе балансировщика.

Параметры балансировщика
Параметр Значение по умолчанию Описание
lbmethod byrequests Метод балансировки нагрузки балансировщика. Выберите метод планировщика балансировки нагрузки, который нужно использовать. Либо byrequests, для выполнения взвешенного подсчета запросов; bytraffic, для выполнения балансировки по взвешенному количеству байтов трафика; или bybusyness, для выполнения балансировки по ожидающим запросам. Значение по умолчанию byrequests.
maxattempts На один меньше, чем количество рабочих процессов, или 1 для одного рабочего процесса. Максимальное количество попыток переключения перед отказом.
nofailover Выключено Если установлено в On, сессия прервется, если рабочий процесс находится в состоянии ошибки или отключен. Установите это значение в On, если серверы бэкэнда не поддерживают репликацию сессий.
stickysession - Имя сессии с "прилипанием" балансировщика. Значение обычно устанавливается на что-то вроде JSESSIONID или PHPSESSIONID, и зависит от сервера приложений бэкэнда, который поддерживает сессии. Если сервер приложений бэкэнда использует другое имя для файлов cookie и закодированных URL-идентификаторов (например, контейнеры сервлетов), используйте | для разделения. Первая часть — для файла cookie, вторая — для пути.
Доступно в Apache HTTP Server 2.4.4 и более поздних версиях.
stickysessionsep "." Устанавливает символ разделения в файле cookie сессии. Некоторые серверы приложений бэкэнда не используют '.' в качестве символа. Например, сервер Oracle Weblogic использует '!'. Правильный символ можно установить с помощью этого параметра. Установка 'Выключено' означает, что символ не используется.
scolonpathdelim Выключено Если установлено в On, символ точки с запятой ';' будет использоваться в качестве дополнительного разделителя/разделителя пути сессии с "прилипанием". Это в основном используется для эмуляции поведения mod_jk при работе с путями, такими как JSESSIONID=6736bcf34;foo=aabfa
timeout 0 Таймаут балансировщика в секундах. Если установлено, это будет максимальное время ожидания свободного рабочего процесса. Значение по умолчанию — не ждать.
failonstatus - Список одного или нескольких HTTP-кодов состояния, разделенных запятыми. Если установлено, это заставит рабочий процесс перейти в состояние ошибки, когда бэкенд вернет любой код состояния из списка. Восстановление рабочего процесса происходит так же, как и при других ошибках рабочего процесса.
failontimeout Выключено Если установлено, таймаут чтения ввода-вывода после отправки запроса на бэкенд заставит рабочий процесс перейти в состояние ошибки. Восстановление рабочего процесса происходит так же, как и при других ошибках рабочего процесса.
Доступно в Apache HTTP Server 2.4.5 и более поздних версиях.
nonce <авто> Защитный nonce, используемый на странице приложения balancer-manager. Значение по умолчанию — автоматически определенный nonce на основе UUID, обеспечивающий дополнительную защиту страницы. Если задано, nonce устанавливается в это значение. Установка None отключает все проверки nonce.

Примечание

В дополнение к nonce страница balancer-manager должна быть защищена с помощью ACL.

growth 0 Количество дополнительных BalancerMembers, которые разрешено добавить к этому балансировщику в дополнение к тем, которые определены в конфигурации.
forcerecovery Включено Вынужденное немедленное восстановление всех рабочих процессов без учета параметра повторной попытки рабочих процессов, если все рабочие процессы балансировщика находятся в состоянии ошибки. Могут быть случаи, когда уже перегруженный бэкенд может попасть в более серьезные проблемы, если восстановление всех рабочих процессов выполняется без учета параметра повторной попытки каждого рабочего процесса. В этом случае установите Off.
Доступно в Apache HTTP Server 2.4.2 и более поздних версиях.

Пример настройки балансировщика:

ProxyPass "/special-area" "http://special.example.com" smax=5 max=10
ProxyPass "/" "balancer://mycluster/" stickysession=JSESSIONID|jsessionid nofailover=On
<Proxy "balancer://mycluster">
    BalancerMember "ajp://1.2.3.4:8009"
    BalancerMember "ajp://1.2.3.5:8009" loadfactor=20
    # Less powerful server, don't send as many requests there,
    BalancerMember "ajp://1.2.3.6:8009" loadfactor=5
</Proxy>

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

ProxyPass "/" "balancer://sparecluster/"
<Proxy balancer://sparecluster>
    BalancerMember ajp://1.2.3.4:8009
    BalancerMember ajp://1.2.3.5:8009
    # The servers below are hot spares. For each server above that is unusable
    # (draining, stopped, unreachable, in error state, etc.), one of these spares
    # will be used in its place. Two servers will always be available for a request
    # unless one or more of the spares is also unusable.
    BalancerMember ajp://1.2.3.6:8009 status=+R
    BalancerMember ajp://1.2.3.7:8009 status=+R
</Proxy>

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

ProxyPass "/" "balancer://hotcluster/"
<Proxy "balancer://hotcluster">
    BalancerMember "ajp://1.2.3.4:8009" loadfactor=1
    BalancerMember "ajp://1.2.3.5:8009" loadfactor=2.25
    # The server below is on hot standby
    BalancerMember "ajp://1.2.3.6:8009" status=+H
    ProxySet lbmethod=bytraffic
</Proxy>

Дополнительные ключевые слова ProxyPass

Обычно mod_proxy канонизирует URL-адреса ProxyPass. Однако это может быть несовместимо с некоторыми бэкендами, особенно теми, которые используют PATH_INFO. Необязательный ключевой запрос nocanon подавляет это и передает путь URL "в сыром" виде бэкенду. Обратите внимание, что этот ключевой запрос может повлиять на безопасность вашего бэкэнда, так как он удаляет обычную ограниченную защиту от атак на основе URL, предоставляемую прокси.

Обычно mod_proxy включает строку запроса при генерации переменной среды SCRIPT_FILENAME. Необязательный ключевой запрос noquery (доступный в httpd 2.4.1 и более поздних версиях) предотвращает это.

Необязательный ключевой запрос interpolate в сочетании с ProxyPassInterpolateEnv, заставляет ProxyPass интерполировать переменные среды, используя синтаксис ${VARNAME}. Обратите внимание, что многие стандартные переменные среды, полученные от CGI, не будут существовать при этой интерполяции, поэтому вам все равно может потребоваться mod_rewrite для сложных правил. Также обратите внимание, что интерполяция поддерживается только в схеме/имени хоста/порту URL для переменных, которые доступны при разборе директивы (например, Define). Динамическое определение этих полей можно выполнить с помощью mod_rewrite. Следующий пример описывает, как использовать mod_rewrite для динамической установки схемы на http или https:

RewriteEngine On

RewriteCond "%{HTTPS}" =off
RewriteRule "." "-" [E=protocol:http]
RewriteCond "%{HTTPS}" =on
RewriteRule "." "-" [E=protocol:https]

RewriteRule "^/mirror/foo/(.*)" "%{ENV:protocol}://backend.example.com/$1" [P]
ProxyPassReverse  "/mirror/foo/" "http://backend.example.com/"
ProxyPassReverse  "/mirror/foo/" "https://backend.example.com/"

Директива ProxyPassInherit

Описание: Наследовать директивы ProxyPass, определенные с главного сервера
Синтаксис:
ProxyPassInherit On|Off
Значение по умолчанию:
ProxyPassInherit On
Контекст: конфигурация сервера, виртуальный хост
Статус: Расширение
Модуль: mod_proxy
Совместимость: ProxyPassInherit доступна только в Apache HTTP Server 2.4.5 и более поздних версиях.

Эта директива заставит текущий сервер/виртуальный хост "унаследовать" ProxyPass директивы, определенные на главном сервере. Это может вызвать проблемы и несогласованное поведение при использовании Balancer Manager для динамических изменений, и поэтому следует отключить, если используется эта функция.

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

Отключение ProxyPassInherit также отключает BalancerInherit.

Директива ProxyPassInterpolateEnv

Описание: Включить интерполяцию переменных среды в конфигурациях обратного прокси
Синтаксис:
ProxyPassInterpolateEnv On|Off
Значение по умолчанию:
ProxyPassInterpolateEnv Off
Контекст: конфигурация сервера, виртуальный хост, каталог
Статус: Расширение
Модуль: mod_proxy
Совместимость: Доступно в httpd 2.2.9 и более поздних версиях

Эта директива, в сочетании с аргументом interpolate для ProxyPass, ProxyPassReverse, ProxyPassReverseCookieDomain, и ProxyPassReverseCookiePath, позволяет динамически настраивать обратные прокси с использованием переменных среды, которые могут быть установлены другим модулем, например, mod_rewrite. Она влияет на директивы ProxyPass, ProxyPassReverse, ProxyPassReverseCookieDomain, и ProxyPassReverseCookiePath, и заставляет их заменять значение переменной среды varname строкой ${varname} в конфигурационных директивах, если установлен параметр interpolate.

Часть схемы/имени хоста/порта ProxyPass может содержать переменные, но только те, которые доступны при разборе директивы (например, с помощью Define). Для всех других случаев использования рекомендуется использовать mod_rewrite вместо этого.

Предупреждение о производительности

Держите это отключенным, если вам это не нужно! Добавление переменных в ProxyPass может привести к использованию рабочих процессов mod_proxy по умолчанию (которые не позволяют никакой тонкой настройки, как повторное использование соединений и т. д.).

Директива ProxyPassMatch

Описание: Сопоставляет удаленные серверы с локальным пространством URL с использованием регулярных выражений
Синтаксис:
ProxyPassMatch [regex] !|url [key=value [key=value ...]]
Контекст: конфигурация сервера, виртуальный хост, каталог
Статус: Расширение
Модуль: mod_proxy

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

Примечание: Эта директива не может использоваться в контексте <Directory>.

Предположим, что локальный сервер имеет адрес http://example.com/; тогда

ProxyPassMatch "^/(.*\.gif)$" "http://backend.example.com/$1"

приведет к тому, что локальный запрос на http://example.com/foo/bar.gif будет внутренне преобразован в запрос прокси на http://backend.example.com/foo/bar.gif.

Примечание

Аргумент URL должен быть парсируем как URL до подстановки regexp (а также после). Это ограничивает используемые сопоставления. Например, если бы мы использовали

ProxyPassMatch "^(/.*\.gif)$" "http://backend.example.com:8000$1"

в нашем предыдущем примере, это приведет к ошибке синтаксиса при запуске сервера. Это ошибка (PR 46665 в ASF bugzilla), и решение — переформулировать сопоставление:

ProxyPassMatch "^/(.*\.gif)$" "http://backend.example.com:8000/$1"

Директива ! полезна в ситуациях, когда вы не хотите делать обратный прокси для подкаталога.

Когда используется внутри раздела <LocationMatch>, первый аргумент опускается, а regexp берётся из <LocationMatch>.

Если требуется более гибкая конфигурация обратного прокси, см. директиву RewriteRule со флагом [P].

Подстановка по умолчанию

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

Предупреждение о безопасности

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

Директива ProxyPassReverse

Описание: Настраивает URL в заголовках HTTP-ответов, отправляемых обратным прокси-сервером
Синтаксис:
ProxyPassReverse [path] url [interpolate]
Контекст: настройка сервера, виртуальный хост, директория
Статус: Расширение
Модуль: mod_proxy

Эта директива позволяет Apache httpd настраивать URL в заголовках Location, Content-Location и URI при ответах на HTTP-перенаправления. Это необходимо, когда Apache httpd используется в качестве обратного прокси-сервера (или шлюза), чтобы избежать обхода обратного прокси из-за HTTP-перенаправлений на серверах, расположенных за обратным прокси.

Будут переписаны только заголовки HTTP-ответов, упомянутые выше. Apache httpd не будет переписывать другие заголовки ответов, а также по умолчанию не переписывает ссылки URL внутри HTML-страниц. Это означает, что если проксируемый контент содержит абсолютные ссылки URL, они будут обойдут прокси. Для переписывания HTML-контента для соответствия прокси, необходимо загрузить и включить mod_proxy_html.

path — это имя локального виртуального пути; url — частичный URL для удаленного сервера. Эти параметры используются так же, как и для директивы ProxyPass.

Например, предположим, что локальный сервер имеет адрес http://example.com/; тогда

ProxyPass         "/mirror/foo/" "http://backend.example.com/"
ProxyPassReverse  "/mirror/foo/" "http://backend.example.com/"
ProxyPassReverseCookieDomain  "backend.example.com"  "public.example.com"
ProxyPassReverseCookiePath  "/"  "/mirror/foo/"

не только вызовет локальный запрос на http://example.com/mirror/foo/bar для внутренней конвертации в запрос к прокси http://backend.example.com/bar (функциональность, которую ProxyPass предоставляет здесь). Она также обрабатывает перенаправления, которые сервер backend.example.com отправляет при перенаправлении http://backend.example.com/bar на http://backend.example.com/quux . Apache httpd настраивает это на http://example.com/mirror/foo/quux перед отправкой ответа на HTTP-перенаправление клиенту. Обратите внимание, что имя хоста, используемое для построения URL, выбирается с учетом настроек директивы UseCanonicalName.

Обратите внимание, что эта директива ProxyPassReverse также может использоваться совместно с функцией прокси (RewriteRule ... [P]) из mod_rewrite, так как она не зависит от соответствующей директивы ProxyPass.

Необязательное ключевое слово interpolate, используемое вместе с ProxyPassInterpolateEnv, позволяет интерполировать переменные окружения, указанные в формате ${VARNAME}. Обратите внимание, что интерполяция не поддерживается в схеме части URL.

При использовании внутри раздела <Location>, первый аргумент опускается, и локальная директория извлекается из <Location>. То же самое происходит внутри раздела <LocationMatch>, но, вероятно, не будет работать как ожидалось, так как ProxyPassReverse будет интерпретировать regexp буквально как путь; если это необходимо в такой ситуации, укажите ProxyPassReverse вне раздела или в отдельном разделе <Location>.

Эта директива не поддерживается в разделах <Directory> или <Files>.

Директива ProxyPassReverseCookieDomain

Описание: Настраивает строку Domain в заголовках Set-Cookie от обратного прокси-сервера
Синтаксис:
ProxyPassReverseCookieDomain internal-domain public-domain [interpolate]
Контекст: настройка сервера, виртуальный хост, директория
Статус: Расширение
Модуль: mod_proxy

Использование в основном аналогично ProxyPassReverse, но вместо переписывания заголовков, являющихся URL, эта директива переписывает строку domain в заголовках Set-Cookie.

Директива ProxyPassReverseCookiePath

Описание: Настраивает строку Path в заголовках Set-Cookie от обратного прокси-сервера
Синтаксис:
ProxyPassReverseCookiePath internal-path public-path [interpolate]
Контекст: настройка сервера, виртуальный хост, директория
Статус: Расширение
Модуль: mod_proxy

Полезно в сочетании с ProxyPassReverse в ситуациях, когда пути URL на сервере-обработчике сопоставляются с общедоступными путями на обратном прокси. Эта директива переписывает строку path в заголовках Set-Cookie. Если начало пути cookie совпадает с internal-path, путь cookie заменится на public-path.

В примере, приведенном с ProxyPassReverse, директива:

ProxyPassReverseCookiePath  "/"  "/mirror/foo/"

перепишет cookie с путем на сервере-обработчике / (или /example или, фактически, с любым) на /mirror/foo/.

Директива ProxyPreserveHost

Описание: Использование заголовка HTTP запроса Host для запроса прокси
Синтаксис:
ProxyPreserveHost On|Off
Значение по умолчанию:
ProxyPreserveHost Off
Контекст: настройка сервера, виртуальный хост, директория
Статус: Расширение
Модуль: mod_proxy
Совместимость: Используется в контексте директории начиная с 2.3.3 и выше.

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

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

Директива ProxyReceiveBufferSize

Описание: Размер сетевого буфера для проксируемых HTTP и FTP-соединений
Синтаксис:
ProxyReceiveBufferSize bytes
Значение по умолчанию:
ProxyReceiveBufferSize 0
Контекст: настройка сервера, виртуальный хост
Статус: Расширение
Модуль: mod_proxy

Директива ProxyReceiveBufferSize задаёт явный размер сетевого буфера (TCP/IP) для проксируемых HTTP и FTP-соединений, для повышения пропускной способности. Он должен быть больше 512 или установлен на 0 для использования системного значения буфера по умолчанию.

Пример

ProxyReceiveBufferSize 2048

Директива ProxyRemote

Описание: Удалённый прокси, используемый для обработки определённых запросов
Синтаксис:
ProxyRemote match remote-server
Контекст: настройка сервера, виртуальный хост
Статус: Расширение
Модуль: mod_proxy

Определяет удалённые прокси для этого прокси. match — это либо имя схемы URL, которую поддерживает удалённый сервер, либо частичный URL, для которого должен использоваться удалённый сервер, либо * для указания сервера, к которому следует обращаться для всех запросов. remote-server — частичный URL для удалённого сервера. Синтаксис:

remote-server = scheme://hostname[:port]

scheme — это фактически протокол, который должен использоваться для связи с удалённым сервером; только http и https поддерживаются этим модулем. При использовании https, запросы пересылаются через удалённый прокси с помощью метода HTTP CONNECT.

Пример

ProxyRemote "http://goodguys.example.com/" "http://mirrorguys.example.com:8000"
ProxyRemote "*" "http://cleverproxy.localdomain"
ProxyRemote "ftp" "http://ftpproxy.mydomain:8080"

В последнем примере прокси будет пересылать FTP-запросы, инкапсулированные как ещё один HTTP-запрос прокси, другому прокси, который может их обработать.

Этот параметр также поддерживает конфигурацию обратного прокси; бэкенд-веб-сервер может быть встроен в пространство URL виртуального хоста, даже если этот сервер скрыт другим прямым прокси.

Директива ProxyRemoteMatch

Описание: Удалённый прокси, используемый для обработки запросов, соответствующих регулярным выражениям
Синтаксис:
ProxyRemoteMatch regex remote-server
Контекст: настройка сервера, виртуальный хост
Статус: Расширение
Модуль: mod_proxy

Директива ProxyRemoteMatch идентична директиве ProxyRemote, за исключением того, что первый аргумент — регулярное выражение, сопоставляемое с запрошенным URL.

Директива ProxyRequests

Описание: Включает запросы forward (стандартные) прокси
Синтаксис:
ProxyRequests On|Off
Значение по умолчанию:
ProxyRequests Off
Контекст: настройка сервера, виртуальный хост
Статус: Расширение
Модуль: mod_proxy

Это позволяет или запрещает Apache httpd функционировать как сервер forward-прокси. (Установка ProxyRequests на Off не отключает использование директивы ProxyPass.)

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

Для получения возможности проксирования HTTP или FTP-сайтов также необходимы mod_proxy_http или mod_proxy_ftp (или оба) в сервере.

Для получения возможности проксирования HTTPS-сайтов (вперед) необходима активация mod_proxy_connect в сервере.

Предупреждение

Не включайте проксирование с ProxyRequests до тех пор, пока не защитите свой сервер. Открытые прокси-серверы опасны как для вашей сети, так и для интернета в целом.

См. также

  • Прямые и обратные прокси/шлюзы

Директива ProxySet

Описание: Устанавливает различные параметры балансировщика прокси или члена
Синтаксис:
ProxySet url key=value [key=value ...]
Контекст: конфигурация сервера, виртуальный хост, каталог
Статус: Расширение
Модуль: mod_proxy
Совместимость: ProxySet доступен только в Apache HTTP Server 2.2 и более поздних версиях.

Эта директива используется в качестве альтернативного способа установки любого параметра, доступного балансировщикам и рабочим процессам прокси, обычно выполняемого с помощью директивы ProxyPass. Если используется внутри контейнерной директивы <Proxy balancer url|worker url>, аргумент url не требуется. В качестве побочного эффекта создается соответствующий балансировщик или рабочий процесс. Это может быть полезно при выполнении обратного проксирования через RewriteRule вместо директивы ProxyPass.

<Proxy "balancer://hotcluster">
    BalancerMember "http://www2.example.com:8080" loadfactor=1
    BalancerMember "http://www3.example.com:8080" loadfactor=2
    ProxySet lbmethod=bytraffic
</Proxy>
<Proxy "http://backend">
    ProxySet keepalive=On
</Proxy>
ProxySet "balancer://foo" lbmethod=bytraffic timeout=15
ProxySet "ajp://backend:7001" timeout=15

Предупреждение

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

Директива ProxySourceAddress

Описание: Установить локальный IP-адрес для исходящих подключений прокси
Синтаксис:
ProxySourceAddress address
Контекст: конфигурация сервера, виртуальный хост
Статус: Расширение
Модуль: mod_proxy
Совместимость: Доступно в версии 2.3.9 и более поздних версиях

Эта директива позволяет задать определенный локальный адрес для привязки при подключении к серверу бэкенда.

Директива ProxyStatus

Описание: Показать статус Proxy LoadBalancer в mod_status
Синтаксис:
ProxyStatus Off|On|Full
Значение по умолчанию:
ProxyStatus Off
Контекст: конфигурация сервера, виртуальный хост
Статус: Расширение
Модуль: mod_proxy
Совместимость: Доступно в версии 2.2 и более поздних версиях

Данная директива определяет, отображается ли информация о статусе прокси-балансировщика на странице сервера mod_status.

Примечание

Полный синоним Включен

Директива ProxyTimeout

Описание: Таймаут сети для запросов прокси
Синтаксис:
ProxyTimeout seconds
Значение по умолчанию:
Value of Timeout
Контекст: конфигурация сервера, виртуальный хост
Статус: Расширение
Модуль: mod_proxy

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

Директива ProxyVia

Описание: Информация, предоставленная в заголовке HTTP-ответа Via для запросов прокси
Синтаксис:
ProxyVia On|Off|Full|Block
Значение по умолчанию:
ProxyVia Off
Контекст: конфигурация сервера, виртуальный хост
Статус: Расширение
Модуль: mod_proxy

Эта директива управляет использованием заголовка HTTP Via: прокси. Предполагается, что она контролирует поток запросов прокси по цепочке прокси-серверов. См. RFC 2616 (HTTP/1.1), раздел 14.45 для объяснения строк заголовка Via:.

  • Если установлено Off, что является значением по умолчанию, специальная обработка не выполняется. Если запрос или ответ содержат заголовок Via:, он передается без изменений.
  • Если установлено On, для каждого запроса и ответа добавляется строка заголовка Via: для текущего хоста.
  • Если установлено Full, каждая сгенерированная строка заголовка Via: дополнительно будет иметь версию сервера Apache httpd, отображаемую как поле комментария Via:.
  • Если установлено Block, все строки заголовка Via: удаляются из каждого запроса прокси. Новый заголовок Via: не будет сгенерирован.

© 2018 The Apache Software Foundation
Licensed under the Apache License, Version 2.0.
https://httpd.apache.org/docs/2.4/en/mod/mod_proxy.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API