Назад | Перейти на главную страницу

Может ли обратный прокси-сервер сделать запрос к другому прокси-серверу и переписать URL-адреса в содержимом ответа?

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

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

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

У меня вопрос, возможно ли это вообще? Если да, то где я мог бы начать искать, чтобы реализовать это?

Любая помощь приветствуется, спасибо!

изменить: я нашел способ переписать URL-адреса в прокси-сервере, используя mod_replace. Но до сих пор не нашел способ пересылать веб-запросы через другой прокси

Это из документации Apache

ProxyPass Директива

Описание: Сопоставляет удаленные серверы с URL-пространством локального сервера.

Синтаксис: ProxyPass [path] !|url [key=value [key=value ...]] [nocanon] [interpolate] [noquery]

Контекст: конфигурация сервера, виртуальный хост, каталог

Положение дел: Расширение

Модуль: mod_proxy

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

Заметка: Эта директива не может использоваться в контексте.

В ProxyRequests директива обычно должна быть установлена выключен когда используешь ProxyPass.

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

ProxyPass http://backend.example.com/

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

Возможен следующий альтернативный синтаксис, однако он может привести к снижению производительности при наличии в очень большом количестве. Преимущество синтаксиса ниже в том, что он позволяет динамическое управление через интерфейс 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 директивы.

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

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

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

пример

ProxyPass /example http://backend.example.com max=20 ttl=120 retry=300

Рассмотрим ответ @Tim Dunkley и расширим его с помощью ProxyRemote директива. Объединение ProxyPass и ProxyRemote должен привести к желаемому результату и будет очень гибким.

http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxyremote

http://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxyremote