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

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

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

Предположим, что локальный сервер имеет адрес 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 и ProxyPassMatch правила проверяются в порядке настройки. Выигрывает первое совпадающее правило. Поэтому обычно вы должны сортировать конфликтующие ProxyPass правила, начиная с самых длинных URL-адресов. В противном случае более поздние правила для более длинных URL-адресов будут скрыты любым более ранним правилом, использующим начальную подстроку URL-адреса. Обратите внимание, что существует некоторая связь с совместным использованием рабочих процессов. Напротив, ProxyPass в блоке может быть размещена только одна директива Location , и более конкретное расположение будет иметь приоритет.

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

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

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

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

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://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-адреса ProxyPassed. Но это может быть несовместимо с некоторыми бэкендами, особенно с теми, которые используют PATH_INFO . Необязательное ключевое слово nocanon подавляет это и передает URL-адрес «сырым» в серверную часть. Обратите внимание, что это ключевое слово может повлиять на безопасность вашего бэкэнда, поскольку оно удаляет обычную ограниченную защиту от атак на основе URL, обеспечиваемую прокси-сервером.

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

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

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/"