Обратный прокси принимает запросы клиентов и передаёт их на внутренние серверы, скрывая структуру инфраструктуры, а балансировщик нагрузки распределяет эти запросы между несколькими серверами по заданному алгоритму, чтобы ни один узел не оказался перегружен. Разница в цели: прокси — это посредник, балансировщик — это распределитель. При этом почти любой современный балансировщик работает как обратный TCP-прокси, поэтому на уровне реализации функции пересекаются, и одно устройство часто закрывает обе роли.
Что делает каждый из них
Обратный прокси (reverse proxy) стоит на границе между внешней сетью и бэкендом. Он терминирует TLS-соединение, кеширует статику, сжимает ответы, фильтрует запросы, подменяет заголовки и маршрутизирует трафик по URI, домену или Host-заголовку. Обратный прокси имеет смысл даже при одном-единственном сервере приложений — тогда речь идёт о безопасности, кешировании и разгрузке бэкенда от криптографии.
Балансировщик нагрузки решает другую задачу: у него за спиной пул серверов (upstream-группа), и он выбирает, кому отдать очередной запрос. Алгоритмы распределения — round robin, least connections, взвешенные варианты, хеширование по IP-адресу источника. К этому добавляются проверки доступности узлов (health checks), выведение упавшего сервера из ротации и закрепление сессии за конкретным бэкендом (sticky sessions), если приложение хранит состояние локально.
Практическое правило: если задача — «спрятать бэкенд и обработать запрос по дороге», нужен обратный прокси; если задача — «пережить рост трафика и отказ отдельного сервера», нужен балансировщик. Один сервер за прокси — это не отказоустойчивость, а лишь дополнительный слой обработки.
Ключевые различия по пунктам
- Количество бэкендов. Обратный прокси работоспособен с одним сервером; балансировщик имеет смысл минимум с двумя.
- Уровень модели OSI. Балансировка бывает на L4 (TCP/UDP, по адресам и портам) и на L7 (HTTP, по содержимому запроса). Обратный прокси — почти всегда L7, поскольку ему нужно разбирать протокол прикладного уровня.
- Основная метрика. Для балансировщика — равномерность распределения и время отклика узлов; для прокси — корректность обработки и доля попаданий в кеш.
- Отказоустойчивость. Активные и пассивные проверки состояния, автоматическое исключение узла — область балансировщика. Прокси без пула серверов при падении бэкенда отдаст ошибку.
- Работа с содержимым. И тот и другой могут модифицировать запросы и ответы: переписывать пути, добавлять X-Forwarded-For, вырезать служебные заголовки.
- География. Балансировка применима к приложениям, развёрнутым на нескольких площадках или в разных ЦОД, — прокси такой задачи сам по себе не решает.
Где границы стираются
На практике чаще всего разделение условное. Nginx, HAProxy, Envoy и аппаратные ADC совмещают обе роли: один и тот же процесс терминирует TLS, кеширует, а затем выбирает узел из пула. Продукты класса ADC (Application Delivery Controller) идут дальше — выбор группы серверов делается на основе содержимого запроса и его источника, то есть по URL, cookie, User-Agent, подсети клиента. Такие решения обычно управляются через веб-интерфейс, командную строку и API, а сложные правила и политики описываются на высокоуровневом языке программирования — это удобнее, чем набор жёстко заданных полей в форме. Среди отечественных продуктов этого класса известно российское решение для балансировки нагрузки, подробности есть на сайте разработчика.
Есть и обратный случай: L4-балансировщик, работающий по схеме DSR (direct server return), прокси-сервером не является — он лишь перенаправляет пакеты, а ответ уходит клиенту напрямую, минуя балансировщик. Такая схема даёт минимальные задержки, но лишает возможности работать с HTTP-содержимым.
Как выбрать под конкретную задачу
Один сервер приложений, нужно закрыть его от прямого доступа и снять нагрузку с шифрования — достаточно обратного прокси. Несколько идентичных серверов, требуется горизонтальное масштабирование и переживание отказа узла — нужен балансировщик уровня L7. Резервный ЦОД или несколько площадок — понадобится ещё и глобальная балансировка (GSLB) на уровне DNS поверх локальных балансировщиков. Часто, но не всегда, начинают с одного узла nginx в роли прокси и по мере роста добавляют upstream-группу — миграция при этом сводится к правке конфигурации, а не к смене инструмента.
Не подбирайте инструмент по названию — начните с вопроса, сколько у вас бэкендов и что должно произойти при падении одного из них. Если ответа на второй вопрос нет, вам нужна балансировка с проверками доступности, а не просто прокси. И проверяйте поведение схемы под нагрузкой заранее: конфигурация, корректная при десяти запросах в секунду, при тысяче может вести себя иначе.
