Как настроить обратный прокси с Apache
Apache — это универсальный веб-сервер, предлагающий полный набор вспомогательных функций, некоторые из которых доступны в виде расширений. В этой статье мы будем использовать модуль mod_proxy
для настройки Apache в роли обратного прокси.
Хотя Apache может быть не лучшим выбором в качестве обратного прокси-сервера, поскольку более современные альтернативы, такие как NGINX, имеют тенденцию привлекать внимание, mod_proxy
полезен для серверов, на которых уже работает Apache и теперь необходимо направить трафик на другой сервис. . Вы можете настроить виртуальный хост Apache для передачи запросов для данного домена на отдельный веб-сервер.
Для целей этого руководства мы используем Apache 2.4 с системой на основе Debian. Мы также предполагаем, что серверы, на которые вы хотите проксировать трафик, уже доступны по сети с вашего хоста Apache. В этой статье основное внимание уделяется включению прокси на основе уникального виртуального хоста, но mod_proxy
также можно настроить глобально, как часть конфигурации вашего сервера Apache или на уровне каталога через .htaccess
. файлы.
Включение прокси-модуля
mod_proxy
включен в установку Apache по умолчанию. Используйте a2enmod
, чтобы активировать модуль и его независимый HTTP-компонент:
sudo a2enmod proxy sudo a2enmod proxy_http
Это настраивает Apache для поддержки проксирования HTTP-соединений с другими хостами. Модуль настраивается с помощью инструкций с префиксом Proxy
в ваших конфигурационных файлах Apache. Мы настроим их дальше.
Настройка проксируемого виртуального хоста
Давайте настроим виртуальный хост, который перенаправляет example.com
на внутренний IP-адрес 192.168.0.1
. Вы должны добавить запись DNS для example.com
, которая указывает на ваш хост Apache.
Прокси в этом сценарии позволяет посетителям прозрачно получать доступ к вашему внутреннему веб-серверу через внешний адрес. Apache действует как привратник, который направляет трафик к конечному пункту назначения. Пользователь увидит example.com
, хотя фактически Apache разрешает запросы через отдельный сервер.
Добавьте новый файл виртуального хоста в /etc/apache2/sites-available
со следующим содержимым:
<VirtualHost *:80> ServerName example.com ProxyPass / http://192.168.0.1/ nocanon ProxyPassReverse / http://192.168.0.1/ </VirtualHost>
Директивы ProxyPass
и ProxyPassReverse
указывают, что трафик на example.com
должен быть проксирован на 192.168.0.1
. Необязательное ключевое слово nocanon
указывает Apache передать необработанный URL-адрес на удаленный сервер. Без этого ключевого слова Apache автоматически канонизирует URL-адрес, что может быть несовместимо с некоторыми серверами и платформами. Использование nocanon
гарантирует совместимость, но может повлиять на вашу безопасность, поскольку отключает встроенную защиту Apache от прокси-атак на основе URL-адресов.
Необходимо указать ProxyPassReverse
, чтобы отличить вашу конфигурацию от настройки обратного прокси-сервера. Apache будет использовать предоставленный URL-адрес для перезаписи заголовков ответов Location
, Content-Location
и URI
, выдаваемых вашим сервером. Это гарантирует, что последующие запросы будут поступать на обратный прокси-сервер вместо того, чтобы напрямую обращаться к внутреннему серверу.
Эта конфигурация будет проксировать все запросы. Вы можете ограничить проксирование определенным путем, например /media
, изменив инструкции ProxyPass
и ProxyPassReverse
:
ProxyPass /media http://192.168.0.1/ ProxyPassReverse /media http://192.168.0.1/
Добавление нескольких правил ProxyPass
позволяет направлять запросы между несколькими целями, используя один виртуальный хост. Правила сопоставляются в порядке их написания. Если вам нужно более сложное поведение маршрутизации, используйте директиву ProxyPassMatch
. Это эквивалентно ProxyPass
, но сопоставляет входящие URL-адреса с регулярным выражением:
ProxyPassMatch ^/client/(.*)/images$ http://192.168.0.1/
Сохраните файл виртуального хоста и включите его с помощью команды a2ensite
. Это берет базовое имя вашего файла относительно каталога sites-available
:
sudo a2ensite example-proxy-vhost
Перезапустите Apache, чтобы применить изменения:
sudo service apache2 restart
Теперь ваш простой прокси должен работать. Попробуйте посетить example.com
— вы должны увидеть контент, обслуживаемый 192.168.0.1
. Запрос завершается на вашем хосте Apache, который затем проксирует его на ваш внутренний сервер.
Использование SSL
В приведенном выше примере SSL не используется. В производственной рабочей нагрузке вы захотите настроить это, добавив параметры SSLCertificateFile
и SSLCertificateKeyFile
на свой виртуальный хост. Они определяют сертификат SSL и ключ, используемые при проверке SSL-соединений. Вы также можете использовать certbot Let’s Encrypt для автоматизации настройки.
Такая настройка SSL означает, что безопасное соединение будет разорвано на вашем хосте Apache. Соединение между Apache и вашим прокси-сервером будет осуществляться через обычный HTTP.
Если вам также необходимо защитить прокси-соединение, вы должны использовать параметры SSLProxy
, предоставляемые mod_ssl
. SSLProxyEngine=On
будет работать как самая базовая конфигурация, при условии, что и Apache, и ваш целевой прокси-сервер имеют доступ к одним и тем же сертификатам. Этот параметр указывает, что информация SSL должна передаваться через прокси-соединение.
Параметры прокси
Обратные прокси-серверы Apache имеют несколько необязательных директив, которые можно использовать для настройки поведения пересылки. Вот некоторые часто используемые варианты:
ProxyAddHeaders
— Apache передаетX-Forwarded-Host
,XForwarded-For
иX -Forwarded-Server
на ваш внутренний сервер по умолчанию. Они позволяют вашему бэкенду определить, что запрос был проксирован через Apache. Установка для этого заголовка значенияOff
запрещает Apache добавлять эти заголовки.ProxyErrorOverride
— Apache не будет вмешиваться в ответы, отправляемые вашим внутренним сервером, если это не указано. Если ваш сервер выдает код ошибки 400, 404, 500 или любой другой, пользователь получит этот контент как есть. ПараметрProxyErrorOverride
изменяет это, позволяя Apache вместо этого заменять содержимое страниц ошибок сконфигурированнымErrorDocument
. Это может быть полезно в ситуациях, когда вы хотите, чтобы ошибки от всех ваших серверных частей обрабатывались единообразно, а конфигурация была централизована на прокси-сервере.ProxyPassReverseCookieDomain
. Эта функция аналогична обязательной (для обратного проксирования) директивеProxyPassReverse
. Он перепишет домен в заголовкахSet-Cookie
, чтобы он ссылался на имя виртуального хоста, а не на имя хоста внутреннего сервера, с которого они происходят.ProxyPreserveHost
— Apache обычно отправляет собственное имя хоста на ваши внутренние серверы в качестве значения заголовкаHost
. Установка этой директивы означает, что вместо этого будет отправлен заголовок originalHost
. Это может быть необходимо, когда ваше серверное программное обеспечение выполняет собственную маршрутизацию на основе имени хоста.ProxyTimeout
— используйте эту директиву, чтобы настроить время ожидания Apache, пока ваш внутренний сервер обрабатывает проксируемый запрос. Apache прервет запрос и вернет клиенту код ошибки, если время ожидания превышено. По умолчанию используется значениеTimeout
на уровне сервера.
Вы можете установить эти директивы как дополнительные строки в вашем файле виртуального хоста. Не забывайте перезапускать службу Apache каждый раз, когда вы применяете изменение.
Балансировка нагрузки
Реализация обратного прокси-сервера Apache также поддерживает балансировку нагрузки между несколькими различными серверными частями. Это позволяет запросу example.com
попасть на любой из серверов в балансировочном пуле.
<Proxy balancer://example-balancer> BalancerMember http://192.168.0.1 BalancerMember http://192.168.0.2 ProxySet lbmethod=bytraffic </Proxy> ProxyPass / balancer://example-balancer ProxyPassReverse / balancer://example-balancer
В этом примере запросы направляются на один из двух серверов в пуле example-balancer
. Алгоритм балансировки нагрузки определяется настройкой lbmethod
; используемое здесь значение bytraffic
пытается гарантировать, что каждый из серверов обрабатывает равный объем трафика.
Альтернативный метод балансировки byrequests
– это более простая версия bytraffic, которая дает каждому бэкенду равную долю входящих запросов. балансировщик по занятости
отслеживает, сколько запросов обслуживает каждый сервер, а затем назначает новые запросы наименее загруженному серверу.
Краткое содержание
Модуль mod_proxy
может превратить Apache в хост обратного прокси-сервера, который позволяет использовать маршрутизацию на основе имен для доступа к нескольким независимым службам. Вы также можете добавить балансировку нагрузки, чтобы обеспечить стабильность и время безотказной работы, распределяя запросы по парку серверов.
Доступны и другие варианты прокси. Вы можете проксировать соединения FTP, WebSocket и HTTP2, среди прочего, установив дополнительные надстройки вместе с mod_proxy
. Полный список модулей доступен в документации Apache.