Apache: настройка обратного прокси

Обзор: настройка обратного прокси с Apache — внешний вид и схема работы

Быстрая навигация

Включение модуля Proxy
Настройка проксированного виртуального хоста
Использование SSL
Параметры прокси
Балансировка нагрузки
Безопасность и харднинг
Отладка и сценарии отказа
Чеклисты ролей и приёмки
Краткое резюме

Apache — универсальный веб-сервер с множеством расширений. В этом руководстве мы используем модуль mod_proxy, чтобы превратить Apache в обратный прокси (reverse proxy). Такой подход полезен, когда Apache уже запущен и нужно пересылать трафик к внутренним сервисам.

Мы ориентируемся на Apache 2.4 и Debian-подобную систему. Предполагается, что целевые серверы уже доступны по сети с хоста Apache. Настройки можно применить на уровне виртуального хоста (recommended) либо глобально в конфиге сервера или через

.htaccess

файлы, если конфигурация сервера это позволяет.

Включение модуля Proxy

Модуль mod_proxy включён в стандартную поставку Apache. Выполните следующие команды, чтобы активировать модуль и его HTTP-компонент:

sudo a2enmod proxy

sudo a2enmod proxy_http

Эти команды включают поддержку проксирования HTTP-подключений. Конфигурация модуля задаётся директивами, начинающимися с префикса Proxy — их мы настроим далее.

Важно: после изменений перезапускайте службу Apache (см. раздел ниже).

Настройка проксированного виртуального хоста

Допустим, вы хотите пробросить example.com на внутренний IP 192.168.0.1. Добавьте DNS-запись, указывающую example.com на публичный IP вашего Apache-хоста.

Виртуальный хост действует как «шлюз»: пользователь видит example.com, а Apache перенаправляет запросы к внутреннему серверу. Создайте файл внутри /etc/apache2/sites-available, например example-proxy.conf, с содержимым ниже:


    ServerName example.com

    ProxyPass / http://192.168.0.1/ nocanon
    ProxyPassReverse / http://192.168.0.1/

Пояснения:

ProxyPass — направляет запросы на бэкенд. Опция nocanon передаёт URL в исходном виде, не канонизируя его.
ProxyPassReverse — переписывает заголовки Location, Content-Location и URI в ответах бэкенда так, чтобы клиент продолжал обращаться к прокси, а не к внутреннему серверу.

Опция nocanon полезна для совместимости с некоторыми фреймворками, но отключает часть защиты от URL-based proxy-атак. Оцените риск и используйте дополнительные проверки в фильтрах доступа.

Чтобы проксировать только путь, например /media, скорректируйте директивы:

ProxyPass /media http://192.168.0.1/
ProxyPassReverse /media http://192.168.0.1/

Для более сложного сопоставления используйте ProxyPassMatch с регулярными выражениями:

ProxyPassMatch ^/client/(.*)/images$ http://192.168.0.1/

После сохранения файла включите сайт и перезапустите Apache:

sudo a2ensite example-proxy-vhost
sudo service apache2 restart

Проверьте: при обращении к example.com вы должны увидеть содержимое, отдаваемое 192.168.0.1.

Использование SSL

В примере выше SSL опущен. В production-среде обычно завершают TLS на уровне прокси (терминация SSL). Добавьте в виртуальный хост директивы для сертификата:

SSLEngine on
SSLCertificateFile /etc/ssl/certs/example.crt
SSLCertificateKeyFile /etc/ssl/private/example.key

Для автоматизации выпуска и обновления сертификатов используйте Let’s Encrypt (certbot).

Если вы хотите шифровать соединение между Apache и бэкендом (end-to-end TLS), включите SSL-проксирование mod_ssl с опциями типа:

SSLProxyEngine On

и настройте доверие к сертификатам на обоих концах. Без включённого SSLProxyEngine Apache не будет устанавливаться как TLS-клиент к бэкенду.

Параметры прокси

Вот распространённые директивы, которые пригодятся при тонкой настройке проксирования:

ProxyAddHeaders — по умолчанию Apache добавляет X-Forwarded-Host, X-Forwarded-For, X-Forwarded-Server. Отключите (Off), если это мешает вашей логике.
ProxyErrorOverride — если включён, Apache заменяет страницы ошибок бэкенда собственными ErrorDocument. Удобно для единообразной обработки ошибок.
ProxyPassReverseCookieDomain — переписывает домен в Set-Cookie, чтобы куки ссылались на виртуальный хост, а не на внутренний хост.
ProxyPreserveHost — при включении Apache отправит оригинальный Host заголовок на бэкенд. Нужно, когда бэкенд осуществляет маршрутизацию на основе имени хоста.
ProxyTimeout — время ожидания ответа от бэкенда; по умолчанию берётся server-level Timeout.

Добавляйте эти директивы внутрь блока или в scope, где они применимы. После изменений — перезапуск.

Балансировка нагрузки

mod_proxy поддерживает балансировку между несколькими бэкендами. Пример конфигурации балансировщика:


    BalancerMember http://192.168.0.1
    BalancerMember http://192.168.0.2
    ProxySet lbmethod=bytraffic


ProxyPass / balancer://example-balancer
ProxyPassReverse / balancer://example-balancer

Пояснения к методам балансировки:

bytraffic — распределяет трафик с учётом объёма трафика, стараясь уравнять нагрузку.
byrequests — простое распределение по числу запросов.
bybusyness — направляет новые запросы на наименее загруженный бэкенд.

Можно задавать опции BalancerMember, например weight или status, чтобы временно выключать ноду или отдавать ей больше трафика.

Безопасность и харднинг

Важно защитить прокси: он может раскрыть внутренние ресурсы или стать каналом для SSRF/прокси-атак. Рекомендации:

Ограничьте ProxyRequests: убедитесь, что Apache не работает как открытый прямой прокси (ProxyRequests Off).
Используйте Require/Allow для контроля источников запросов (Access Control) и включайте только нужные виртуальные хосты.
Включите ProxyPreserveHost, если бэкенд требует оригинальный Host, но проверьте код на уязвимости, зависящие от Host.
Фильтруйте пути и параметры, которые вы проксируете; избегайте передавать необработанные внешние URL.
Включите и регулярно обновляйте модуль mod_security или другой WAF для защиты от веб-атак.
Настройте логирование: доступ и ошибки должны иметь достаточный уровень детализации для расследований.
При использовании SSL храните ключи в защищённых местах и используйте автоматическое обновление сертификатов.

Отладка и журналирование

Полезные команды и файлы логов:

Просмотреть конфигурацию и проверку синтаксиса:

apachectl configtest

Основные логи ошибок и доступа обычно в /var/log/apache2/error.log и /var/log/apache2/access.log.
Включите более подробное логирование для виртуального хоста при необходимости (LogLevel debug для локальной отладки).

Типичные проблемы и как их диагностировать:

502/504 ошибки: проверьте доступность бэкенда и ProxyTimeout.
Неправильные редиректы: проверьте ProxyPassReverse и настройки Location/Host в бэкенде.
Куки отдаются с доменом внутреннего хоста: используйте ProxyPassReverseCookieDomain.

Когда этот подход не подходит

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

Высоконагруженные системы с низкой задержкой: NGINX или специализированные L7-прокси иногда дают лучшую производительность.
Среды с большим числом динамических соединений WebSocket: лучше выбирать решения с оптимизацией для долгоживущих соединений.
Требование продвинутой маршрутизации на основе gRPC или HTTP/2 multiplexing — специализированные прокси могут быть предпочтительнее.

Альтернативные подходы

NGINX: лёгкий, высокопроизводительный и часто предпочтителен в роли L7-прокси и балансировщика.
HAProxy: производительный TCP/HTTP балансировщик с мощным набором методов балансировки и health-check.
Специализированные облачные балансировщики (AWS ALB, GCP Load Balancer): упрощают масштабирование и интеграцию с облаком.

Выбор зависит от требований: производительность, возможности маршрутизации, поддержка протоколов и эксплуатационные навыки команды.

Методика внедрения (мини-методология)

Оцените требования: SSL, WebSocket, HTTP/2, количество бэкендов, лимиты по задержке.
Подготовьте тестовую среду, соответствующую production-сети.
Включите mod_proxy и настройте минимальный виртуальный хост.
Тестируйте функциональность, редиректы, заголовки и куки.
Включите SSL и, при необходимости, SSLProxyEngine.
Настройте мониторинг и health-check для бэкендов.
Поэтапно переключайте трафик, проверяйте логи и метрики.
Документируйте конфигурацию и процедуры отката.

Ролевые чеклисты

Администратор (DevOps):

Включён mod_proxy и proxy_http
Настроен виртуальный хост и включён через a2ensite
Проверено поведение ProxyPass/ProxyPassReverse
SSL настроен и сертификаты установлены
ProxyTimeout и параметры производительности скорректированы
Логи и мониторинг включены

Разработчик приложения:

Приложение корректно обрабатывает X-Forwarded-* заголовки
Протестированы редиректы и абсолютные URL
Установлено корректное поведение cookies (Domain, Path)
Обработаны ошибки 4xx/5xx при проксировании

Безопасность / Compliance:

Проверен доступ к ключам и сертификатам
Включён WAF/модули защиты при необходимости
Проведён обзор конфигурации на предмет SSRF и утечек

План отката и инцидентный рукописный порядок действий

Если после внесения изменений прокси перестал выдавать корректный контент:

Временно отключите сайт: sudo a2dissite example-proxy-vhost && sudo service apache2 restart
Верните предыдущую рабочую конфигурацию из резервной копии.
Проверьте логи /var/log/apache2/error.log и access.log.
Если проблема вызвана SSL, попробуйте временно вернуть порт 80 без SSL для диагностики.
При критическом сбое — переключите DNS на резервный публичный сервер или старый балансировщик.

Критерии приёмки

При обращении к example.com отображается контент от внутреннего сервера.
В заголовках ответа корректно переписываются Location/Set-Cookie (если применимо).
Время ответа не превышает SLA (учтите ProxyTimeout).
Логи фиксируют прохождение запросов и не содержат неожиданных ошибок 5xx.

Тесты / критерии приёма (мини-набор)

Функциональный: запрос GET / возвращает 200 и ожидаемое тело.
Редиректы: бэкенд отдаёт Redirect, клиент получает корректный Location префиксованный доменом прокси.
Cookies: Set-Cookie с доменом внутреннего хоста переписан ProxyPassReverseCookieDomain.
Timeout: симулируйте долгую операцию и убедитесь, что ProxyTimeout отрабатывает как ожидалось.

Глоссарий (1 строка)

Reverse proxy — сервер, принимающий запросы от клиентов и пересылающий их на один или несколько внутренних серверов.

Совместимость и миграционные заметки

Конфигурация mod_proxy подходит для Apache 2.4+. Для Apache 2.2 или старше синтаксис и поведение могут отличаться.
При миграции к NGINX проверьте правила переписывания URL и поведение заголовков: X-Forwarded-* нужно добавить вручную.
Для WebSocket убедитесь, что прокси поддерживает upgrade-заголовки и long-lived соединения.

Полезные сниппеты и шаблоны

Пример минимального виртуального хоста с SSL и проксированием на HTTPS-бэкенд:


    ServerName example.com

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/example.crt
    SSLCertificateKeyFile /etc/ssl/private/example.key

    SSLProxyEngine On
    ProxyPreserveHost On

    ProxyPass / https://192.168.0.1/
    ProxyPassReverse / https://192.168.0.1/

    ErrorLog ${APACHE_LOG_DIR}/example-proxy-error.log
    CustomLog ${APACHE_LOG_DIR}/example-proxy-access.log combined

Отказные сценарии и примеры, когда прокси может «сломаться»

Неправильные права на приватный ключ SSL приводят к ошибке старта Apache.
Бэкенд недоступен — прокси вернёт 502/504; требуются health-check и автоматическое переключение.
Некорректные абсолютные ссылки в контенте — ссылки будут вести напрямую на внутренний хост, если не применено переписывание.
Заголовки Host/Forwarded ломают логику приложения — используйте ProxyPreserveHost и/или настройте бэкенд.

Ресурсы и дальнейшее чтение

Официальная документация Apache по mod_proxy и модулю mod_ssl (см. apache.org).
Руководства по Let’s Encrypt и certbot для автоматизации сертификатов.

Краткое резюме

mod_proxy позволяет превратить Apache в обратный прокси с поддержкой SSL и балансировки нагрузки.
Включите proxy и proxy_http, настройте ProxyPass/ProxyPassReverse и при необходимости SSLProxyEngine.
Обеспечьте безопасность: блокируйте открытый прокси, фильтруйте пути, ведите логирование и применяйте WAF.
Тестируйте поведение при отказах и имейте план отката.

Важно: перед внедрением в production протестируйте конфигурацию в изолированной среде и документируйте изменения.

Настройка обратного прокси с Apache