Apache как обратный прокси: полное руководство по настройке mod_proxy | AdminWiki
Logo

Apache как обратный прокси: полное руководство по настройке mod_proxy

01 августа 2026 9 мин. чтения
Содержание статьи

Apache HTTP Server выполняет роль обратного прокси, принимая клиентские запросы и перенаправляя их на внутренние серверы. Для этой задачи используются модули mod_proxy, mod_proxy_http и mod_proxy_wstunnel. Первый предоставляет базовый функционал проксирования, второй добавляет поддержку HTTP, третий обрабатывает WebSocket-соединения. Настройка сводится к загрузке модулей, конфигурации VirtualHost и определению директив ProxyPass и ProxyPassReverse.

Эта инструкция содержит проверенные примеры конфигураций для проксирования веб-приложений и WebSocket. Вы получите готовые решения для продакшена: от базовой настройки до балансировки нагрузки и SSL-терминации. Материал учитывает особенности Apache 2.4.x и актуален на август 2026 года.

Что такое обратный прокси и зачем он нужен

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

Ключевые преимущества такой архитектуры:

  • Балансировка нагрузки. Прокси распределяет входящие запросы между несколькими бэкендами, предотвращая перегрузку одного сервера.
  • SSL-терминация. Шифрование и расшифровка HTTPS-трафика выполняются на прокси. Внутренние серверы работают по HTTP, что снижает нагрузку на них.
  • Кэширование. Прокси сохраняет ответы бэкенда и отдает их повторно без обращения к внутреннему серверу. Сокращается время отклика и нагрузка.
  • Безопасность. Внутренние серверы скрыты от прямого доступа из интернета. Прокси фильтрует запросы, блокирует вредоносный трафик и ограничивает доступ по IP.
  • Единая точка входа. Несколько приложений на разных портах или серверах доступны через один домен и порт.

Типовые сценарии использования:

  • Проксирование веб-приложений на Node.js, Python, Java, Go. Бэкенд слушает порт 3000 или 8080, Apache принимает запросы на 80/443 порту и пробрасывает их.
  • Организация доступа к микросервисам. Каждый сервис работает на своем порту, прокси маршрутизирует запросы по путям: /api, /auth, /admin.
  • Проксирование WebSocket-серверов для чатов, дашбордов реального времени, терминалов в браузере.

Необходимые модули Apache и их активация

Для работы обратного прокси требуется набор модулей. Их состав зависит от типа проксируемого трафика. Минимальный набор: mod_proxy и mod_proxy_http. Для WebSocket добавляется mod_proxy_wstunnel. Для балансировки нагрузки подключается mod_proxy_balancer.

mod_proxy и mod_proxy_http: основа для HTTP-проксирования

mod_proxy - ядро проксирования в Apache. Он предоставляет базовую инфраструктуру: управление соединениями с бэкендами, обработку директив ProxyPass и ProxyPassReverse, поддержку пулов соединений. Без mod_proxy_http этот модуль не умеет обрабатывать HTTP-запросы. mod_proxy_http добавляет реализацию HTTP-протокола: формирует запросы к бэкенду, обрабатывает ответы, корректирует заголовки. Оба модуля всегда подключаются вместе для HTTP-проксирования.

mod_proxy_wstunnel: проксирование WebSocket

WebSocket устанавливает постоянное TCP-соединение и выполняет обновление протокола с HTTP на WebSocket через заголовки Upgrade и Connection. Стандартный mod_proxy_http не обрабатывает такое обновление - соединение разрывается. mod_proxy_wstunnel перехватывает запрос, обнаруживает заголовок Upgrade: websocket и переключается в режим туннелирования. Весь последующий трафик передается между клиентом и бэкендом без изменений.

Активация модулей в Debian/Ubuntu:

sudo a2enmod proxy
sudo a2enmod proxy_http
sudo a2enmod proxy_wstunnel
sudo systemctl restart apache2

В CentOS/RHEL модули подключаются раскомментированием строк в /etc/httpd/conf/httpd.conf или отдельными файлами в /etc/httpd/conf.modules.d/:

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
LoadModule proxy_wstunnel_module modules/mod_proxy_wstunnel.so

Проверка загруженных модулей:

httpd -M | grep proxy

Вывод должен содержать proxy_module, proxy_http_module и proxy_wstunnel_module.

Базовая настройка обратного прокси для HTTP-приложения

Минимальная конфигурация состоит из VirtualHost с директивами ProxyPass и ProxyPassReverse. Создайте файл /etc/apache2/sites-available/app-proxy.conf (Debian/Ubuntu) или секцию VirtualHost в /etc/httpd/conf.d/proxy.conf (CentOS/RHEL).

<VirtualHost *:80>
    ServerName app.example.com

    ProxyPreserveHost On
    ProxyPass / http://localhost:3000/
    ProxyPassReverse / http://localhost:3000/

    ErrorLog ${APACHE_LOG_DIR}/app-proxy-error.log
    CustomLog ${APACHE_LOG_DIR}/app-proxy-access.log combined
</VirtualHost>

Разбор директив:

  • ProxyPreserveHost On - передает бэкенду оригинальный заголовок Host от клиента. Приложение получает доменное имя, к которому обратился пользователь.
  • ProxyPass / http://localhost:3000/ - все запросы к корню сайта направляются на внутренний сервер, слушающий порт 3000.
  • ProxyPassReverse / http://localhost:3000/ - корректирует заголовки Location, Content-Location и URI в ответах бэкенда, заменяя http://localhost:3000 на публичный URL.

После создания конфигурации активируйте сайт и перезагрузите Apache:

sudo a2ensite app-proxy.conf
sudo systemctl reload apache2

Директива ProxyPass: синтаксис и параметры

Полный синтаксис ProxyPass:

ProxyPass [путь] ! | url [ключ=значение [ключ=значение ...]]

Параметры, критичные для продакшена:

  • timeout - время ожидания ответа от бэкенда в секундах. Значение по умолчанию - 60 секунд. Для долгих операций увеличивайте до 300.
  • retry - пауза перед повторной попыткой подключения к упавшему бэкенду. По умолчанию 60 секунд.
  • disablereuse - запрещает повторное использование соединений. Полезно при проблемах с keepalive на стороне бэкенда.
  • connectiontimeout - таймаут установки TCP-соединения с бэкендом.

Пример с параметрами:

ProxyPass / http://backend:8080/ timeout=120 retry=30 connectiontimeout=5

Исключение пути из проксирования - восклицательный знак вместо URL:

ProxyPass /static/ !
ProxyPass / http://localhost:3000/

Запросы к /static/ Apache обрабатывает самостоятельно как статические файлы. Остальные запросы уходят на бэкенд.

Директива ProxyPassReverse: зачем она нужна

Бэкенд формирует ответы с абсолютными URL, содержащими свой внутренний адрес. Например, редирект после логина: Location: http://localhost:3000/dashboard. Клиент получит этот заголовок и попытается обратиться к localhost:3000 - соединение оборвется. ProxyPassReverse сканирует заголовки Location, Content-Location и URI в теле ответа, заменяя внутренний URL на внешний. Для редиректа из примера заголовок станет Location: https://app.example.com/dashboard.

Для приложений, генерирующих ссылки в теле ответа (HTML, JSON), одной директивы ProxyPassReverse недостаточно. Требуется настройка самого приложения или использование mod_proxy_html для перезаписи ссылок в теле ответа.

Настройка проксирования WebSocket-соединений

WebSocket-проксирование требует модуля mod_proxy_wstunnel и указания протокола ws:// или wss:// в ProxyPass. Конфигурация совмещается с HTTP-проксированием в одном VirtualHost.

Пример конфигурации для WebSocket-приложения

<VirtualHost *:80>
    ServerName ws.example.com

    # HTTP-проксирование для основного приложения
    ProxyPass / http://localhost:8080/
    ProxyPassReverse / http://localhost:8080/

    # WebSocket-проксирование для эндпоинта /ws/
    ProxyPass /ws/ ws://localhost:8080/ws/
    ProxyPassReverse /ws/ ws://localhost:8080/ws/

    # Заголовки для корректного обновления протокола
    RewriteEngine On
    RewriteCond %{HTTP:Upgrade} =websocket [NC]
    RewriteRule /(.*) ws://localhost:8080/$1 [P,L]
</VirtualHost>

Блок RewriteEngine перехватывает запросы с заголовком Upgrade: websocket и направляет их через mod_proxy_wstunnel. Остальные запросы обрабатываются стандартным HTTP-прокси.

Для защищенного WebSocket (WSS) через HTTPS-прокси:

ProxyPass /ws/ wss://backend:8080/ws/
ProxyPassReverse /ws/ wss://backend:8080/ws/

Проверка работы WebSocket-прокси: откройте инструменты разработчика в браузере, перейдите на вкладку Network, отфильтруйте по WS. Успешное соединение показывает статус 101 Switching Protocols.

Обеспечение безопасности обратного прокси

Прокси-сервер - точка входа в инфраструктуру. Его компрометация открывает доступ ко всем внутренним серверам. Настройка безопасности включает HTTPS, ограничение доступа и скрытие информации о сервере.

Настройка HTTPS для прокси

SSL-терминация на прокси: клиенты подключаются по HTTPS, Apache расшифровывает трафик и передает его бэкенду по HTTP. Конфигурация VirtualHost на 443 порту:

<VirtualHost *:443>
    ServerName secure.example.com

    SSLEngine On
    SSLCertificateFile /etc/letsencrypt/live/secure.example.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/secure.example.com/privkey.pem

    ProxyPreserveHost On
    ProxyPass / http://localhost:8080/
    ProxyPassReverse / http://localhost:8080/

    # Проброс заголовков для бэкенда
    RequestHeader set X-Forwarded-Proto "https"
    RequestHeader set X-Forwarded-Port "443"
</VirtualHost>

Заголовки X-Forwarded-Proto и X-Forwarded-Port информируют бэкенд о том, что клиент использовал HTTPS. Приложение должно доверять этим заголовкам для корректной генерации ссылок.

Если бэкенд работает по HTTPS, включите SSLProxyEngine:

SSLProxyEngine On
ProxyPass / https://backend:8443/
ProxyPassReverse / https://backend:8443/

Ограничение доступа по IP через директиву Require:

<Location />
    Require ip 192.168.1.0/24 10.0.0.0/8
</Location>

Скрытие информации о сервере:

ServerTokens Prod
ServerSignature Off

ServerTokens Prod оставляет в заголовке Server только «Apache». ServerSignature Off убирает подпись сервера со страниц ошибок.

Сравнение Apache и Nginx в роли обратного прокси

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

Производительность. Nginx использует событийную модель обработки соединений: один рабочий процесс обслуживает тысячи клиентов в неблокирующем режиме. Apache с MPM event приближается к этой модели, но уступает при проксировании большого объема статики. На синтетических тестах Nginx обрабатывает на 15-25% больше запросов в секунду при равном потреблении памяти.

Потребление ресурсов. Nginx потребляет фиксированный объем памяти независимо от количества соединений. Apache с prefork MPM выделяет процесс на каждое соединение, что приводит к линейному росту потребления RAM. При 500 одновременных соединений Apache prefork занимает в 2-3 раза больше памяти.

Гибкость конфигурации. Apache предоставляет модули для сложной обработки запросов: mod_rewrite с полным набором правил, mod_security как WAF, mod_proxy_html для перезаписи контента. Nginx реализует базовую логику через конфигурационные блоки, сложные сценарии требуют скриптов на Lua (OpenResty) или внешних модулей.

Поддержка WebSocket. Оба сервера проксируют WebSocket. В Apache требуется отдельный модуль mod_proxy_wstunnel и правило mod_rewrite. В Nginx достаточно указать заголовки Upgrade и Connection в блоке location.

Рекомендации по выбору:

  • Nginx - для высоконагруженного проксирования статики, API и микросервисов с простой маршрутизацией.
  • Apache - для приложений, требующих сложной обработки запросов, интеграции с .htaccess, использования mod_rewrite и mod_security.
  • Гибридная схема: Nginx как внешний прокси для статики и SSL-терминации, Apache как внутренний сервер для динамики. Подробный анализ архитектуры и производительности обеих систем приведен в сравнении Nginx и Apache.

Типовые проблемы и их решение

При настройке обратного прокси возникают предсказуемые ошибки. Диагностика начинается с логов Apache: /var/log/apache2/error.log (Debian/Ubuntu) или /var/log/httpd/error_log (CentOS/RHEL).

Ошибка 502 Bad Gateway: причины и исправление

502 означает, что прокси получил некорректный ответ от бэкенда или не смог установить соединение. Причины и решения:

  • Бэкенд не запущен. Проверьте статус сервиса: systemctl status app-service. Запустите, если остановлен.
  • Неверный адрес или порт в ProxyPass. Проверьте, что бэкенд слушает указанный порт: ss -tlnp | grep PORT.
  • Брандмауэр блокирует соединение. Для локальных соединений localhost брандмауэр не участвует. Для удаленных бэкендов проверьте iptables или firewalld.
  • Таймаут соединения. Бэкенд не успевает ответить за отведенное время. Увеличьте timeout в ProxyPass: ProxyPass / http://backend:8080/ timeout=300.
  • Бэкенд возвращает некорректный HTTP-ответ. Проверьте логи бэкенда. Запросите бэкенд напрямую через curl для изоляции проблемы.

Диагностика через curl:

curl -v http://localhost:8080/

Если curl получает ответ напрямую, но через прокси возвращается 502 - проблема в конфигурации Apache или сетевом взаимодействии.

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

Симптомы: клиент пытается подключиться по WebSocket, соединение сбрасывается или не переключается с HTTP.

Проверьте по порядку:

  1. Загружен ли mod_proxy_wstunnel. Выполните httpd -M | grep wstunnel. Если модуль отсутствует, активируйте его.
  2. Протокол в ProxyPass. Для WebSocket должен быть ws:// или wss://, не http://.
  3. Заголовки Upgrade и Connection. Браузер отправляет их автоматически. Прокси должен их пробросить. Правило RewriteRule с проверкой %{HTTP:Upgrade} решает эту задачу.
  4. Порядок правил. Правило для WebSocket должно быть выше общего ProxyPass /, иначе запрос перехватывается HTTP-прокси.

Инструменты разработчика браузера показывают статус WebSocket-соединения. Код 101 - успех, 400 или 502 - ошибка конфигурации прокси.

Оптимизация производительности Apache как прокси

Производительность обратного прокси зависит от MPM, keepalive-соединений и таймаутов. Для прокси-нагрузки переключитесь на MPM event:

sudo a2dismod mpm_prefork
sudo a2enmod mpm_event
sudo systemctl restart apache2

MPM event обрабатывает соединения в потоках, а не процессах. Keepalive-соединения не блокируют рабочие потоки - они передаются специальному слушателю.

Настройка keepalive и таймаутов в VirtualHost:

KeepAlive On
MaxKeepAliveRequests 100
KeepAliveTimeout 5

ProxyTimeout 60
ProxyBadHeader Ignore

KeepAliveTimeout 5 секунд - компромисс между удержанием соединения для повторных запросов и освобождением ресурсов. ProxyTimeout ограничивает время ожидания ответа от бэкенда.

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

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

<Proxy balancer://backend-cluster>
    BalancerMember http://192.168.1.10:8080
    BalancerMember http://192.168.1.11:8080
    BalancerMember http://192.168.1.12:8080
</Proxy>

ProxyPass / balancer://backend-cluster/
ProxyPassReverse / balancer://backend-cluster/

Методы балансировки задаются параметром lbmethod:

  • byrequests (по умолчанию) - распределение по количеству запросов.
  • bytraffic - по объему переданного трафика в байтах.
  • bybusyness - по загруженности бэкенда. Сервер с наименьшим количеством активных соединений получает следующий запрос.

Включение мониторинга через mod_status:

<Location /balancer-manager>
    SetHandler balancer-manager
    Require ip 192.168.1.0/24
</Location>

Страница /balancer-manager показывает состояние бэкендов, количество запросов и ошибок. Полезна для отладки и мониторинга продакшен-среды.

Для углубленного изучения конфигурации Apache в продакшене, включая настройку безопасности и оптимизацию, обратитесь к руководству по профессиональной настройке Apache2. Если вы рассматриваете Nginx как альтернативу, полное руководство по Nginx Reverse Proxy содержит готовые конфигурации для SSL-терминации, балансировки и WebSocket.

Поделиться:
Сохранить гайд? В закладки браузера