Daniil Fedorov

августа 24, 2026

Обновлено августа 24, 2026

Прокси и балансировщик нагрузки: отличия, настройка и выбор

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

Прокси в первую очередь выступает посредником между двумя сторонами соединения. Он может скрывать реальный адрес сервера, завершать TLS, кэшировать ответы, фильтровать запросы и направлять их к нужному приложению. Балансировщик нагрузки решает более узкую задачу — распределяет запросы между несколькими backend-серверами, чтобы инфраструктура могла выдерживать больше трафика и продолжать работать при отказе отдельных узлов.

При этом одно не исключает другое. Nginx, HAProxy, Traefik и другие решения могут одновременно работать как reverse proxy и распределять запросы между несколькими экземплярами приложения.

В этой статье разберем, как работают прокси и балансировщики нагрузки, чем forward proxy отличается от reverse proxy, что такое балансировка L4 и L7, какие алгоритмы распределения трафика существуют и какую архитектуру выбрать для VPS, сайта, API или растущего веб-проекта.

Разверните серверную инфраструктуру в Serverspace

Для настройки reverse proxy, балансировщика нагрузки или нескольких backend-серверов удобно использовать облачную инфраструктуру, которую можно масштабировать вместе с проектом.

В Serverspace вы можете создать VPS для Nginx, HAProxy, Traefik, API, приложений и других компонентов, самостоятельно выбрать конфигурацию сервера и получить полный контроль над программным окружением. По мере роста нагрузки к архитектуре можно добавлять новые виртуальные машины и распределять между ними отдельные роли.

Например, начать с одного VPS с Nginx и приложением, а затем вынести proxy на отдельный сервер и подключить несколько backend-узлов для балансировки.

Создайте VPS в Serverspace и разверните инфраструктуру для сайта, API или другого серверного проекта.

Что такое прокси-сервер?

Proxy server — это промежуточный узел, через который проходит сетевой трафик между клиентом и конечным сервером.

Вместо прямого соединения:

Клиент → Сервер

появляется дополнительный уровень:

Клиент → Proxy → Сервер

Прокси получает запрос, при необходимости анализирует или изменяет его, отправляет дальше и затем возвращает ответ клиенту.

В зависимости от архитектуры proxy может:

скрывать IP-адрес клиента или backend-сервера;
ограничивать доступ;
фильтровать запросы;
кэшировать контент;
завершать HTTPS-соединение;
маршрутизировать запросы между приложениями;
добавлять или изменять HTTP-заголовки;
собирать логи входящего трафика;
защищать backend от прямого доступа из интернета.

При обсуждении серверной инфраструктуры важно различать два основных варианта: forward proxy и reverse proxy.

Forward proxy: прокси со стороны клиента

Forward proxy располагается ближе к клиенту и представляет его интересы при обращении к внешним ресурсам.

Схема выглядит так:

Пользователь

→

Forward Proxy

→

Интернет

Внешний сервер при такой схеме взаимодействует прежде всего с proxy, а не непосредственно с устройством пользователя.

Forward proxy может использоваться для:

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

Для размещения обычного сайта forward proxy обычно не нужен. В серверной архитектуре значительно чаще используется reverse proxy.

Reverse proxy: прокси перед сервером

Reverse proxy находится со стороны серверной инфраструктуры.

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

Клиент

↓

Reverse Proxy

↓

Frontend

API

Admin Panel

Пользователю не обязательно знать адрес каждого внутреннего сервиса. Он подключается к reverse proxy, который определяет, куда отправить запрос.

Например:

example.kz → frontend

example.kz/api/ → API

admin.example.kz → административная панель

Такой подход особенно удобен при размещении нескольких приложений на одном VPS или при построении инфраструктуры из нескольких серверов.

Разверните прокси-сервер на VPS Serverspace

Для reverse proxy удобно использовать отдельный облачный сервер, на котором можно установить Nginx, HAProxy, Traefik или другое подходящее решение.

В Serverspace можно создать VPS с нужной конфигурацией и использовать его как входную точку для сайта, API или нескольких backend-сервисов. Доступ к серверу позволяет самостоятельно настроить маршрутизацию, HTTPS, firewall, кэширование и правила проксирования.

Такой подход подходит как для простой схемы из одного VPS с Nginx, так и для инфраструктуры, где отдельный proxy принимает запросы и распределяет их между несколькими серверами приложений.

Создайте облачный сервер в Serverspace и настройте собственный reverse proxy под требования проекта.

Что такое балансировщик нагрузки?

Load balancer — это компонент инфраструктуры, который принимает входящий трафик и распределяет его между несколькими серверами.

Без балансировки клиент может обращаться непосредственно к одному серверу:

Пользователь

↓

Server 1

Если Server 1 перегружен или недоступен, приложение перестает нормально работать.

С балансировщиком архитектура меняется:

Пользователи

↓

Load Balancer

↙ ↓ ↘

Server 1

Server 2

Server 3

Теперь отдельный backend может быть временно исключен из обработки запросов, а оставшиеся серверы продолжат обслуживать пользователей.

Главные задачи балансировщика:

распределять нагрузку между несколькими узлами;
не отправлять запросы на недоступные серверы;
позволять горизонтально масштабировать приложение;
снижать вероятность перегрузки одного backend;
обеспечивать единую точку входа в кластер.

Прокси и балансировщик нагрузки — в чем разница?

Главное различие находится не столько в положении компонента в сети, сколько в его основной задаче.

Критерий	Reverse Proxy	Load Balancer
Основная задача	Посредник и маршрутизация запросов	Распределение нагрузки между несколькими узлами
Количество backend	Может работать даже с одним сервером	Обычно имеет смысл при двух и более backend
TLS termination	Да	Может поддерживаться
Кэширование	Частая функция	Не является обязательной функцией
Health checks	Зависят от реализации	Один из ключевых механизмов
Горизонтальное масштабирование	Возможно	Основной сценарий

При этом один и тот же Nginx может выполнять обе роли.

Например:

Internet

↓

Nginx

Reverse Proxy

↙ ↓ ↘

Frontend

API

/api

Storage

/files

Nginx маршрутизирует запросы к разным сервисам в зависимости от URL

Это reverse proxy.

Если API запущен в трех экземплярах:

Internet

↓

Nginx

Reverse Proxy + Load Balancer

↓

API Pool

↙ ↓ ↘

API-1

API-2

API-3

Nginx распределяет входящие запросы между несколькими экземплярами API

Nginx одновременно становится балансировщиком нагрузки для этого backend-пула.

Можно ли использовать reverse proxy без балансировки?

Да.

Это распространенный сценарий для небольших VPS.

Например, на сервере могут одновременно работать:

Nginx :80/:443

Node.js :3000

Grafana :3001

API :8000

Открывать каждый внутренний порт в интернет необязательно.

Nginx может принимать весь внешний трафик:

site.example.kz → localhost:3000

api.example.kz → localhost:8000

monitor.example.kz → localhost:3001

В этом случае Nginx является reverse proxy, но фактически ничего не балансирует — у каждого направления есть только один backend.

Можно ли использовать балансировщик как reverse proxy?

На прикладном уровне — да.

Многие современные решения объединяют эти функции.

Например:

Nginx;
HAProxy;
Traefik;
Caddy;
Envoy.

Они могут принимать внешние соединения, определять назначение запроса и распределять трафик между несколькими узлами.

Поэтому в реальном проекте вопрос часто звучит не «proxy или load balancer?», а:

Какие функции нужны на входном узле инфраструктуры?

Балансировка L4 и L7: в чем разница?

Один из важнейших критериев выбора — уровень модели OSI, на котором работает балансировка.

Чаще всего сравнивают Layer 4 и Layer 7.

L4-балансировка

Layer 4 работает на транспортном уровне и принимает решения на основании TCP или UDP.

Балансировщику не обязательно анализировать содержимое HTTP-запроса.

Упрощенно:

Клиент

TCP :443

↓

L4 Load Balancer

↙ ↓ ↘

Server 1

Server 2

Server 3

Балансировка TCP-трафика на уровне L4

Такой подход подходит не только для HTTP.

Через L4 можно балансировать различные TCP- или UDP-сервисы в зависимости от возможностей конкретного ПО.

Плюсы:

меньше анализа прикладного трафика;
подходит для разных сетевых протоколов;
может использоваться там, где HTTP-маршрутизация не требуется.

Минус — балансировщик знает меньше о содержимом запроса.

Он не может принять решение вроде:

/api → один кластер

/images → другой кластер

если не анализирует HTTP на прикладном уровне.

L7-балансировка

Layer 7 работает на уровне прикладного протокола.

Для HTTP балансировщик может анализировать:

hostname;
URL;
HTTP method;
headers;
cookies;
другие параметры запроса.

Например:

example.kz/api/* → API Pool
example.kz/static/* → Static Pool
admin.example.kz/* → Admin Pool

L7 дает более гибкую маршрутизацию и широко используется для сайтов, API и микросервисов.

L4 или L7 — что выбрать?

Для обычного веб-приложения чаще всего нужен L7 reverse proxy или load balancer.

L4 стоит рассматривать, если:

нужно проксировать произвольный TCP/UDP-трафик;
содержимое HTTP-запроса не влияет на маршрутизацию;
TLS должен завершаться непосредственно на backend;
приложение использует протокол, который неудобно обрабатывать на L7.

L7 удобнее, если требуется:

маршрутизация по домену или URL;
TLS termination;
HTTP redirects;
работа с headers и cookies;
кэширование;
детальные HTTP-логи;
разные backend-пулы для разных частей сайта.

Какие алгоритмы балансировки существуют?

После создания пула из нескольких backend нужно определить, как выбирать сервер для следующего запроса.

Round Robin

Самый понятный вариант.

Запросы распределяются последовательно:

Request 1 → Server A

Request 2 → Server B

Request 3 → Server C

Request 4 → Server A

Round Robin хорошо работает, когда backend-серверы имеют примерно одинаковую производительность, а запросы сопоставимы по стоимости обработки.

Weighted Round Robin

Если серверы отличаются по ресурсам, каждому можно назначить вес.

Например:

Server A weight=3

Server B weight=1

Server A будет получать большую долю трафика.

Это полезно, если один backend имеет больше CPU или RAM.

Least Connections

Новый запрос отправляется на сервер с меньшим количеством активных соединений.

Схема особенно полезна, если запросы сильно различаются по длительности.

Например:

Server A → 150 connections

Server B → 43 connections
Новый запрос → Server B

IP Hash

Сервер выбирается на основании IP клиента.

При стабильных условиях один пользователь будет чаще попадать на один и тот же backend.

Это может использоваться для session persistence, но у подхода есть ограничения. Пользователи за NAT могут иметь один публичный IP, а IP конкретного клиента со временем может измениться.

Hash по другому параметру

Некоторые балансировщики позволяют вычислять backend по определенному ключу:

cookie;
URI;
заголовку;
идентификатору клиента.

Такой механизм полезен для специализированных систем, где важно стабильно распределять одинаковые категории запросов.

Что такое health check?

Балансировка бесполезна, если трафик продолжает отправляться на сервер, который перестал работать.

Для этого используются health checks.

Балансировщик периодически проверяет состояние backend:

Load Balancer

↓

GET /health

↓

Server A → 200 OK

Server B → 200 OK

Server C → timeout

После нескольких неудачных проверок Server C может быть временно исключен из пула.

До сбоя

↙ ↓ ↘

После сбоя C

↙ ↘

C недоступен

После восстановления

↙ ↓ ↘

Балансировщик исключает недоступный backend из пула и возвращает его после восстановления

Проверять только факт открытия TCP-порта не всегда достаточно.

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

Поэтому для веб-приложений полезен специальный endpoint:

GET /health

или:

GET /healthz

который возвращает успешный статус только тогда, когда приложение действительно готово обслуживать запросы.

Active и passive health checks

Проверки можно условно разделить на активные и пассивные.

Passive health checks

Proxy анализирует реальные запросы пользователей.

Если backend несколько раз подряд не отвечает или возвращает ошибку соединения, он временно считается недоступным.

Преимущество — не нужны отдельные проверки.

Недостаток — проблема обнаруживается уже во время обработки пользовательского трафика.

Active health checks

Балансировщик сам регулярно отправляет тестовые запросы:

GET /health → 200 OK

Если проверки начинают завершаться ошибкой, backend исключается из пула еще до того, как на него попадет следующий пользовательский запрос.

Возможности активных и пассивных проверок зависят от выбранного ПО и его версии.

Что такое sticky sessions?

В идеальной архитектуре любой экземпляр приложения должен уметь обработать запрос любого пользователя.

Но иногда состояние сессии хранится непосредственно в памяти конкретного сервера.

Например:

User A

↓

Server 1

↓

Session stored in RAM

Сессия привязана к Server 1

Если следующий запрос попадет на Server 2, тот может не знать об авторизации пользователя.

Sticky sessions, или session persistence, пытаются закрепить клиента за определенным backend:

User A

Request 1 ↓

Request 2 ↓

Request 3 ↓

Server 1

Все запросы User A

User B

Request 1 ↓

Request 2 ↓

Server 2

Все запросы User B

Sticky sessions закрепляют пользователя за одним backend-сервером

Это может работать, но повышает зависимость пользователя от конкретного узла.

Более масштабируемый вариант — вынести состояние сессий во внешнее хранилище:

Server 1

Server 2

Server 3

↘

→

↗

Redis / Database

Общее хранилище сессий

Все backend-серверы используют общее внешнее хранилище состояния

Тогда любой backend сможет обработать следующий запрос.

Что такое TLS termination?

Reverse proxy или load balancer может завершать HTTPS-соединение вместо приложения.

Снаружи:

Client

↓

HTTPS

↓

Reverse Proxy

Дальше возможны два варианта.

Первый:

Reverse Proxy

↓

HTTP

↓

Application

Второй:

Reverse Proxy

↓

HTTPS

↓

Application

Первый вариант проще, если proxy и приложение находятся внутри доверенной приватной сети или на одном сервере.

Второй позволяет сохранить шифрование между входным узлом и backend, что особенно важно для распределенной инфраструктуры и сред с повышенными требованиями безопасности.

TLS termination дает несколько преимуществ:

сертификаты можно централизовать на входном узле;
backend не нужно напрямую публиковать в интернет;
проще управлять HTTPS для нескольких приложений;
можно централизовать redirects и security headers.

Зачем нужны X-Forwarded-For и другие proxy headers?

После появления reverse proxy backend видит соединение не непосредственно от пользователя, а от proxy.

Например:

Пользователь: 203.0.113.50
↓ запрос
Nginx: 10.0.0.10
↓ запрос
Backend: 10.0.0.20

Если ничего не настроить, backend может считать адресом клиента:

10.0.0.10

то есть IP самого proxy.

Для передачи исходной информации используются заголовки вроде:

X-Forwarded-For

X-Real-IP

X-Forwarded-Proto

Host

В Nginx распространена конфигурация:

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

Важно не доверять таким заголовкам от произвольных внешних клиентов. Приложение должно считать proxy-заголовки достоверными только тогда, когда запрос действительно поступил от доверенного proxy.

Как настроить простой reverse proxy в Nginx?

Предположим, приложение работает локально:

127.0.0.1:3000

Nginx будет принимать внешний трафик на порту 80.

Установите Nginx на Ubuntu или Debian:

sudo apt update

sudo apt install nginx -y

Создайте конфигурацию:

server {

listen 80;

server_name example.kz;
location / {

proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

}
}

Проверьте синтаксис:

sudo nginx -t

Если конфигурация корректна:

sudo systemctl reload nginx

Теперь пользователи обращаются к Nginx, а приложение на порту 3000 можно не публиковать непосредственно в интернет.

Как добавить балансировку нагрузки в Nginx?

Допустим, приложение запущено на трех внутренних серверах:

10.0.0.11:8080

10.0.0.12:8080

10.0.0.13:8080

Создайте upstream:

upstream backend {

server 10.0.0.11:8080;

server 10.0.0.12:8080;

server 10.0.0.13:8080;

}
server {

listen 80;

server_name example.kz;
location / {

proxy_pass http://backend;
proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

}
}

По умолчанию запросы могут распределяться между серверами по принципу Round Robin.

Архитектура:

Internet

↓

Nginx

↓

upstream backend

├── 10.0.0.11:8080

├── 10.0.0.12:8080

└── 10.0.0.13:8080

Как включить Least Connections в Nginx?

Добавьте:

least_conn;

Пример:

upstream backend {

least_conn;
server 10.0.0.11:8080;

server 10.0.0.12:8080;

server 10.0.0.13:8080;
}

Теперь Nginx будет учитывать количество активных соединений при выборе backend.

Как использовать серверы разной мощности?

Можно задавать веса:

upstream backend {

server 10.0.0.11:8080 weight=3;

server 10.0.0.12:8080 weight=2;

server 10.0.0.13:8080 weight=1;

}

Это означает, что первый сервер должен получать большую долю запросов, чем третий.

Такой подход полезен во время постепенного масштабирования, когда новые узлы имеют более мощную конфигурацию.

Как настроить отказоустойчивость backend в Nginx?

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

upstream backend {

server 10.0.0.11:8080 max_fails=3 fail_timeout=30s;

server 10.0.0.12:8080 max_fails=3 fail_timeout=30s;

server 10.0.0.13:8080 max_fails=3 fail_timeout=30s;

}

Значения нужно выбирать под конкретное приложение.

Слишком агрессивное исключение узла может реагировать на кратковременные сетевые задержки, а слишком мягкое — продолжать отправлять трафик на проблемный backend слишком долго.

Как настроить балансировку через HAProxy?

HAProxy — специализированный proxy и load balancer, который широко используется для HTTP и TCP-трафика.

Установите его:

sudo apt update

sudo apt install haproxy -y

Базовая HTTP-конфигурация может выглядеть так:

frontend http_front

bind *:80

default_backend web_servers
backend web_servers

balance roundrobin

server web1 10.0.0.11:8080 check

server web2 10.0.0.12:8080 check

server web3 10.0.0.13:8080 check

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

sudo haproxy -c -f /etc/haproxy/haproxy.cfg

Если ошибок нет:

sudo systemctl restart haproxy

Проверить статус:

sudo systemctl status haproxy

Как добавить HTTP health check в HAProxy?

Для приложения со страницей:

/health

можно использовать проверку HTTP:

backend web_servers

balance leastconn
option httpchk GET /health

http-check expect status 200
server web1 10.0.0.11:8080 check

server web2 10.0.0.12:8080 check

server web3 10.0.0.13:8080 check

Теперь HAProxy будет учитывать состояние узлов перед отправкой трафика.

Nginx или HAProxy: что выбрать?

Оба решения способны работать как proxy и load balancer, но их типичные сценарии немного различаются.

Критерий	Nginx	HAProxy
Reverse proxy	Отлично подходит	Поддерживается
HTTP load balancing	Да	Да
TCP load balancing	Поддерживается при соответствующей конфигурации	Один из основных сценариев
Статические файлы	Может отдавать напрямую	Обычно не используется как полноценный web server для этой задачи
Кэширование HTTP	Развитые возможности	Не основной сценарий
Специализация	Web server + reverse proxy + load balancer	Proxy и балансировка трафика

Если нужно разместить сайт, отдать статику, настроить HTTPS и одновременно проксировать приложение, Nginx часто становится удобной универсальной точкой входа.

Если основной компонент должен специализироваться на сложной балансировке HTTP/TCP-трафика и health checks, имеет смысл рассмотреть HAProxy.

Когда использовать Traefik?

Traefik особенно удобен в динамической контейнерной инфраструктуре.

Например, при использовании Docker приложения могут регулярно запускаться и удаляться.

В классической конфигурации Nginx список backend часто описывается вручную:

server 10.0.0.11:8080;

server 10.0.0.12:8080;

server 10.0.0.13:8080;

Traefik умеет интегрироваться с источниками конфигурации и автоматически обнаруживать сервисы в некоторых сценариях.

Поэтому его часто рассматривают для:

Docker;
контейнерных приложений;
микросервисов;
динамической маршрутизации;
автоматизированного управления HTTPS.

Для одного обычного сайта Nginx может оказаться проще.

Когда использовать Caddy?

Caddy подходит для проектов, где важна простая конфигурация web server и reverse proxy с автоматизацией HTTPS.

Простейшая логика может быть значительно короче сложной конфигурации классического web server.

Он хорошо подходит для:

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

В более крупных инфраструктурах выбор между Caddy, Nginx, HAProxy, Traefik и Envoy лучше делать на основании архитектуры, а не только количества строк конфигурации.

Разделите proxy и backend на облачных серверах

Когда нагрузка растет, необязательно переносить все компоненты на одну более мощную машину. Инфраструктуру можно разделить на несколько VPS.

Например:

VPS 1

Nginx / HAProxy

↙ ↓ ↘

VPS 2

Application

VPS 3

Application

VPS 4

Application

Nginx или HAProxy распределяет входящий трафик между тремя application-серверами

В таком варианте proxy отвечает за входящий трафик, а вычислительная нагрузка распределяется между отдельными backend.

В Serverspace можно развернуть несколько виртуальных серверов и подобрать ресурсы каждого узла под его роль. Это позволяет отдельно масштабировать входной proxy и серверы приложений, не объединяя всю инфраструктуру на одной машине.

Например, можно начать с одного VPS, а после роста трафика добавить новые backend-серверы и включить их в upstream Nginx или HAProxy.

Разверните облачную инфраструктуру в Serverspace и масштабируйте серверную часть проекта по мере роста нагрузки.

Нужен ли отдельный сервер для балансировщика?

Не всегда.

Для небольшого проекта Nginx может находиться на той же VPS, что и приложение:

VPS

↙ ↓ ↘

Nginx

:443

Application

:3000

Database

:5432

Все компоненты работают на одной VPS

Это простая и экономичная архитектура.

Когда появляются несколько backend:

Proxy VPS

Reverse Proxy / Load Balancer

↙ ↓ ↘

App VPS 1

App VPS 2

App VPS 3

Proxy VPS принимает входящий трафик и распределяет его между application-серверами

отдельный входной сервер становится логичнее.

Он позволяет:

централизовать TLS;
не публиковать backend в интернет;
добавлять новые серверы без изменения публичного IP приложения;
разделить ресурсы proxy и application layer;
упростить сетевые правила между компонентами.

Но здесь возникает новый вопрос — что произойдет, если сам load balancer перестанет работать?

Почему один балансировщик остается точкой отказа?

Представим:

Users

↓

Load Balancer

↙ ↓ ↘

Server A

Server B

Server C

Load Balancer распределяет пользовательский трафик между доступными backend-серверами

Backend-серверов три, но входной узел один.

Если откажет Server B, сервис продолжит работать.

Если откажет Load Balancer, пользователи не смогут попасть ни на один backend.

То есть архитектура все еще содержит Single Point of Failure:

SPOF

Single Point of Failure

↓

Users

→

Load Balancer

Единственная точка входа

→

Backend Pool

При отказе единственного Load Balancer пользователи теряют доступ ко всему backend-пулу

Для действительно отказоустойчивой инфраструктуры сам входной слой также должен иметь резервирование.

Как убрать Single Point of Failure балансировщика?

Один из вариантов — использовать два proxy/load balancer:

Internet

↓

VIP

Virtual IP

↙ ↘

LB 1

Load Balancer

LB 2

Load Balancer

↓

Backend Pool

Application Servers

Virtual IP направляет трафик через доступный балансировщик к backend-пулу

При отказе одного узла второй продолжает принимать трафик.

Конкретная реализация может использовать:

виртуальный IP;
Keepalived/VRRP;
DNS-механизмы;
внешний managed load balancer;
другой уровень отказоустойчивой сетевой инфраструктуры.

Важно понимать, что установка трех backend-серверов сама по себе еще не делает весь сервис высокодоступным.

Нужно анализировать всю цепочку:

DNS

↓

Load Balancer

↓

Application

↓

Database

↓

Storage

Отказ любого незарезервированного критического компонента может остановить приложение.

Нужно ли ставить базу данных за load balancer?

Не по той же схеме, что обычные stateless web-серверы.

Веб-приложения часто легко масштабируются:

App 1

App 2

App 3

потому что каждый экземпляр выполняет одинаковую функцию.

База данных хранит состояние и требует отдельной стратегии репликации, failover и согласованности данных.

Простая схема:

Load Balancer

↓

PostgreSQL 1

PostgreSQL 2

без понимания ролей primary/replica может привести к проблемам.

Для базы данных обычно требуется специализированная архитектура, учитывающая:

какой узел принимает запись;
какие узлы обслуживают чтение;
как выполняется репликация;
как определяется отказ primary;
кто выполняет failover;
как приложение узнает новый адрес primary.

Поэтому балансировка базы данных — отдельная тема и не должна механически копировать схему HTTP backend.

Как proxy помогает разместить несколько сайтов на одной VPS?

Reverse proxy может определять backend по имени домена.

Например:

site1.kz

site2.kz

api.site1.kz

↘ ↓ ↙

Nginx

Reverse Proxy

↙ ↓ ↘

127.0.0.1:3001

site1.kz

127.0.0.1:3002

site2.kz

127.0.0.1:8000

api.site1.kz

Nginx определяет нужное приложение по имени домена и проксирует запрос на соответствующий локальный порт

Пользователи работают через стандартные порты 80 и 443, а внутренние приложения используют собственные порты.

Это позволяет:

не открывать каждый application port во внешний интернет;
управлять HTTPS в одной точке;
размещать несколько сервисов на одном IP;
централизовать access logs;
переносить приложения между портами без изменения публичного URL.

Как proxy используется с Docker?

Один из распространенных вариантов:

Internet

↓

Nginx / Traefik

Reverse Proxy

↓

Docker Network

↙ ↓ ↘

frontend

Container

backend

Container

admin

Container

Nginx или Traefik принимает внешний трафик и направляет его к сервисам внутри Docker Network

Наружу можно публиковать только proxy:

80:80

443:443

Остальные контейнеры доступны через внутреннюю Docker network.

Это уменьшает количество публичных портов и дает одну точку управления входящим HTTP-трафиком.

Для production лучше избегать ручной привязки всей архитектуры к случайным IP контейнеров, поскольку после пересоздания они могут изменяться. Используйте механизм service discovery, DNS контейнерной сети или другое воспроизводимое решение.

Как load balancer используется с Docker?

Допустим, запущено несколько экземпляров backend:

backend-1

backend-2

backend-3

Балансировщик распределяет запросы между ними:

Internet

↓

Proxy / Load Balancer

↙ ↓ ↘

backend-1

backend-2

backend-3

Proxy или Load Balancer распределяет входящий трафик между несколькими backend-экземплярами

В динамической контейнерной среде особенно важно автоматизировать обнаружение новых экземпляров.

Если каждый новый контейнер приходится вручную добавлять в статическую конфигурацию, преимущества быстрого масштабирования снижаются.

Именно поэтому в контейнерных системах востребованы инструменты, которые умеют получать информацию о сервисах автоматически.

Что происходит при масштабировании приложения?

Представим, что изначально используется один backend:

LB

↓

App 1

При росте трафика появляется второй:

LB

├── App 1

└── App 2

Затем третий:

LB

├── App 1

├── App 2

└── App 3

Это называется горизонтальным масштабированием.

Вертикальное масштабирование выглядит иначе:

App Server

↓

2 CPU / 4 GB RAM

Начальная конфигурация

↓

4 CPU / 8 GB RAM

Увеличение ресурсов

↓

8 CPU / 16 GB RAM

Более мощный сервер

Вертикальное масштабирование: производительность увеличивается за счет ресурсов одного сервера

Оба подхода полезны.

Вертикальное масштабирование проще, но имеет предел.

Горизонтальное требует более сложной архитектуры, зато позволяет постепенно увеличивать количество экземпляров приложения.

Load balancer является одним из ключевых компонентов именно горизонтального масштабирования.

Что выбрать для одного небольшого сайта?

Если проект работает на одной VPS, отдельный load balancer обычно не нужен.

Практичная архитектура:

Internet

↓

Nginx

↓

Application

Nginx выполняет роль reverse proxy и может:

обрабатывать HTTPS;
перенаправлять HTTP на HTTPS;
выдавать статические файлы;
проксировать запросы в приложение;
вести access/error logs.

Добавлять отдельный балансировщик перед единственным сервером только ради самого факта его наличия обычно нет смысла.

Что выбрать для нескольких экземпляров приложения?

Если приложение запущено на нескольких серверах:

App 1

App 2

App 3

нужен компонент, который будет определять, куда отправить следующий запрос.

Вариант:

Internet

↓

Nginx / HAProxy

↓

Application Pool

Здесь уже используется полноценная балансировка.

Для большинства HTTP-приложений подойдет L7.

Для TCP-сервисов или архитектуры, где не требуется анализировать HTTP, можно рассмотреть L4.

Что выбрать для API?

Для одного API:

Client

↓

Nginx

↓

API

reverse proxy обычно достаточно.

Для масштабируемого API:

Client

↓

Load Balancer

↓

├── API 1

├── API 2

└── API 3

лучше использовать балансировку с health checks.

При этом API желательно проектировать stateless, чтобы запрос одного пользователя мог безопасно обрабатываться разными экземплярами.

Что выбрать для микросервисов?

Микросервисная архитектура может содержать десятки отдельных сервисов.

Простой вариант:

Client

↓

Reverse Proxy / Gateway

Маршрутизация по URL

↙ ↙ ↘ ↘

User Service

/users

Order Service

/orders

Payment Service

/payments

Catalog Service

/catalog

Gateway анализирует URL запроса и направляет его к соответствующему микросервису

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

/users

Входящие запросы

↓

User Service Pool

↙ ↓ ↘

user-1

user-2

user-3

Запросы к /users распределяются между несколькими экземплярами User Service

В результате входной компонент одновременно выполняет маршрутизацию и балансировку.

Для крупных микросервисных платформ дополнительно могут появиться:

API Gateway;
Ingress Controller;
service mesh;
internal load balancing;
service discovery.

Proxy, API Gateway и Load Balancer — это одно и то же?

Нет, хотя функциональность пересекается.

Reverse proxy перенаправляет запросы к backend.

Load balancer распределяет нагрузку между несколькими backend.

API Gateway обычно добавляет функции, ориентированные непосредственно на управление API:

authentication;
rate limiting;
API keys;
маршрутизация методов;
квоты;
трансформация запросов;
централизованная политика доступа.

На практике один программный продукт может реализовывать несколько ролей одновременно.

Нужна ли CDN, если уже есть reverse proxy?

Reverse proxy около backend и CDN решают разные задачи.

Локальный proxy:

Client

↓

Nginx

↓

Application

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

Client

↓

CDN Edge

↓

Reverse Proxy

↓

Application

CDN особенно полезна для:

кэширования статического контента;
снижения количества запросов к origin;
ускорения доставки пользователям из разных регионов;
дополнительной фильтрации трафика в зависимости от сервиса.

Использование CDN не отменяет необходимости правильно организовать внутренний входной слой инфраструктуры.

Как защитить backend от прямого доступа?

Если пользователи должны подключаться только через proxy, backend необязательно публиковать во внешний интернет.

Предпочтительная схема:

Internet

↓

Public IP

↓

Reverse Proxy

↓

Private Network

↓

Backend Servers

На backend firewall можно разрешить порт приложения только для адреса или приватной сети proxy.

Например, логика правил:

Internet → Backend:8080 = DENY
Proxy → Backend:8080 = ALLOW

Это уменьшает количество непосредственно доступных извне компонентов.

Какие порты открывать на proxy?

Для стандартного публичного веб-сервиса обычно используются:

TCP 80

TCP 443

SSH:

TCP 22

необязательно оставлять открытым всему интернету.

Лучше ограничить административный доступ доверенными адресами, VPN или другой подходящей политикой.

Backend-порты:

если они используются только внутри инфраструктуры, не следует автоматически открывать для всех источников.

Нужно ли включать rate limiting?

Reverse proxy является удобной точкой для базового ограничения частоты запросов.

Например, можно ограничивать количество запросов от одного клиента к определенному endpoint.

Это полезно для:

login;
registration;
API;
дорогих поисковых запросов;
защиты приложения от простых всплесков запросов.

При этом rate limiting на Nginx не следует считать полноценной заменой DDoS-защите или WAF. Эти механизмы решают более широкий класс задач.

Какие таймауты нужно настроить?

Proxy не должен бесконечно ждать backend.

Обычно рассматриваются:

connect timeout — сколько ждать установления соединения;
read timeout — сколько ждать данные от backend;
send timeout — ограничения при отправке данных;
idle timeout — сколько может жить неактивное соединение.

Пример для Nginx:

proxy_connect_timeout 5s;

proxy_send_timeout 60s;

proxy_read_timeout 60s;

Не копируйте значения без учета приложения.

Если backend выполняет задачи по несколько минут, слишком короткий read timeout оборвет нормальные запросы.

Если обычный API отвечает за сотни миллисекунд, ожидание зависшего backend в течение нескольких минут может быть излишним.

Как proxy работает с WebSocket и долгоживущими соединениями?

Не весь трафик между клиентом и сервером состоит из коротких HTTP-запросов. Чаты, панели мониторинга, multiplayer-сервисы, системы уведомлений и некоторые API могут поддерживать соединение открытым в течение минут или даже часов. В таких сценариях настройки reverse proxy и балансировщика требуют отдельного внимания.

Обычный HTTP-запрос выглядит примерно так:

Client → Request → Proxy → Backend → Response → соединение завершено

При WebSocket соединение после первоначального HTTP-handshake остается открытым:

Client

↓

Proxy / Load Balancer

↓

Backend

↕

Долгоживущее соединение

Это влияет на выбор алгоритма балансировки. Например, сервер с небольшим количеством HTTP-запросов может одновременно обслуживать большое число активных WebSocket-соединений. Поэтому распределение только по количеству новых запросов не всегда отражает реальную нагрузку на backend.

Для Nginx при проксировании WebSocket обычно необходимо корректно передать заголовки Upgrade и Connection:

proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection "upgrade";

Также важно учитывать `proxy_read_timeout`. Если timeout меньше времени, в течение которого соединение может оставаться без обмена данными, proxy способен закрыть исправный WebSocket как неактивный.

При масштабировании таких приложений проверьте:

поддерживает ли выбранный балансировщик WebSocket;
сколько одновременных соединений способен держать каждый backend;
как настроены idle и read timeouts;
нужна ли привязка соединения к конкретному серверу;
что произойдет с активными клиентами при перезапуске backend;
как новые соединения будут перераспределяться после исключения узла из пула.

Для обычного REST API основным показателем нагрузки может быть количество запросов в секунду, а для WebSocket-приложения не менее важны число активных соединений, используемая память и длительность каждой сессии. Поэтому одну и ту же схему балансировки не стоит автоматически применять ко всем типам трафика.

Что мониторить на reverse proxy и load balancer?

Сам факт запуска процесса Nginx или HAProxy еще не означает, что инфраструктура работает нормально.

Полезно наблюдать за:

количеством запросов;
HTTP status codes;
долей 4xx и 5xx;
временем ответа;
количеством активных соединений;
ошибками соединения с upstream;
состоянием каждого backend;
CPU и RAM proxy-сервера;
сетевым трафиком;
истечением TLS-сертификатов.

Особенно полезно разделять:

Время ответа proxy
и
Время ответа backend

Иначе сложно понять, где именно возникла задержка.

Какие логи нужны?

На reverse proxy полезно хранить access и error logs.

В access log обычно нужны:

время запроса;
HTTP method;
URL;
status code;
размер ответа;
время обработки;
выбранный upstream;
результат обращения к upstream.

Это помогает разбирать ситуации вроде:

Пользователь получил 502

↓

Какой backend выбрал proxy?

↓

Ответил ли backend?

↓

Был timeout или connection refused?

Без логирования подобные ошибки значительно сложнее расследовать.

Что означает ошибка 502 Bad Gateway?

502 часто означает, что proxy не смог получить корректный ответ от upstream.

Например:

Client

↓

Nginx

Reverse Proxy

↓

✕ Backend unavailable

Nginx не может получить корректный ответ от upstream

↓

502 Bad Gateway

Проверьте:

запущено ли приложение;
правильный ли IP и порт указаны в proxy_pass;
доступен ли backend с proxy-сервера;
не блокирует ли соединение firewall;
не слушает ли приложение только localhost на другом сервере;
есть ли ошибки в логах proxy и приложения.

Для проверки:

curl http://10.0.0.11:8080/health

Если proxy сам не может подключиться к backend, проблема находится ниже уровня пользовательского браузера.

Что означает 504 Gateway Timeout?

504 обычно связано с тем, что proxy дождался соединения с upstream, но не получил ответ вовремя.

Схема:

Client

↓

Proxy

↓

Backend

↓

Слишком долгий ответ

↓

504 Gateway Timeout

Причины могут включать:

медленный SQL-запрос;
перегрузку backend;
зависшую внешнюю интеграцию;
слишком низкий timeout;
нехватку CPU/RAM;
длительную синхронную задачу.

Не стоит автоматически увеличивать timeout до очень большого значения. Сначала выясните, почему приложение отвечает медленно.

Основные ошибки при настройке прокси и балансировщика

Backend опубликован напрямую в интернет

Если к приложению должны обращаться только через proxy, внешний доступ к backend-порту часто не нужен.

Проверьте firewall и правила сети.

Не передается реальный IP клиента

В результате все запросы в логах приложения могут выглядеть так, будто пришли от proxy.

Настройте соответствующие headers и правила доверенных proxy.

Нет health checks

Один backend перестает отвечать, но продолжает получать часть запросов.

В результате пользователи периодически видят ошибки.

Сессии хранятся только в памяти приложения

После добавления второго backend пользователь начинает случайно терять авторизацию.

Используйте session persistence как временное решение или вынесите состояние во внешнее хранилище.

Один load balancer считается полностью отказоустойчивой архитектурой

Три backend не помогут, если единственный входной узел недоступен.

Продумайте отказоустойчивость самого proxy.

Одинаковая нагрузка отправляется на серверы разной мощности

Если один backend значительно слабее остальных, обычный Round Robin может распределять трафик неоптимально.

Рассмотрите веса или другой алгоритм.

Слишком долгие таймауты

Зависшие соединения занимают ресурсы и маскируют проблемы backend.

Слишком короткие таймауты

Нормальные длительные операции начинают завершаться ошибкой.

Нет мониторинга 5xx

Сервис технически работает, но часть пользователей регулярно получает ошибки.

Без метрик команда может обнаружить проблему только по жалобам.

Как выбрать между proxy и load balancer?

Используйте простой алгоритм.

Если есть один backend и нужно:

подключить домен;
настроить HTTPS;
скрыть внутренний порт;
маршрутизировать запросы;

достаточно reverse proxy.

Схема:

Internet → Reverse Proxy → App

Если есть несколько одинаковых backend:

App 1

App 2

App 3

добавьте балансировку:

Internet → Load Balancer → Backend Pool

Если нужны обе функции:

Internet

↓

Reverse Proxy + Load Balancer

↓

Application Pool

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

Какой вариант выбрать для разных проектов?

Сценарий	Начальный вариант	Почему
Один сайт на VPS	Nginx reverse proxy	Простая маршрутизация и HTTPS без отдельного балансировщика
Несколько приложений на одном сервере	Reverse proxy	Маршрутизация по доменам и URL
Несколько одинаковых web backend	L7 load balancer	Распределение HTTP-запросов и health checks
TCP-сервис	L4 load balancer	Нет необходимости анализировать HTTP
Docker с динамическими сервисами	Traefik или другой proxy с service discovery	Удобнее автоматизировать обнаружение контейнеров
API с несколькими экземплярами	Nginx или HAProxy + health checks	Можно объединить reverse proxy и балансировку
Высоконагруженная отказоустойчивая система	Несколько балансировщиков + несколько backend	Нужно исключить единые точки отказа

Checklist перед запуском proxy или load balancer

Перед публикацией инфраструктуры проверьте:

☐ Определите, нужен только reverse proxy или несколько backend требуют балансировки.

☐ Решите, нужен L4 или L7.

☐ Выберите алгоритм балансировки.

☐ Настройте health checks.

☐ Проверьте поведение при отказе одного backend.

☐ Настройте правильную передачу IP клиента.

☐ Определите, где завершается TLS.

☐ Закройте внутренние порты от ненужного внешнего доступа.

☐ Настройте connect/read/send timeouts.

☐ Проверьте, где хранятся пользовательские сессии.

☐ Настройте access и error logs.

☐ Добавьте мониторинг 5xx, latency и состояния upstream.

☐ Проверьте нагрузку на сам proxy.

☐ Для критичной системы устраните Single Point of Failure входного узла.

Итог: прокси или балансировщик нагрузки?

Reverse proxy и load balancer не являются прямыми конкурентами.

Reverse proxy нужен, когда между клиентом и приложением требуется промежуточный сервер: для HTTPS, маршрутизации, скрытия backend, работы с заголовками, кэширования или публикации нескольких сервисов через один адрес.

Load balancer становится необходим, когда один сервис представлен несколькими экземплярами и входящий трафик нужно распределять между ними.

Для небольшого проекта типичная архитектура выглядит так:

Internet

↓

Nginx Reverse Proxy

↓

Application

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

Internet

↓

Nginx / HAProxy

Reverse Proxy + Load Balancer

↓

Application 1

Application 2

Application 3

Трафик распределяется между несколькими экземплярами приложения

Для большинства сайтов и API подходит L7-балансировка. L4 полезна для TCP/UDP-сервисов и ситуаций, где анализ HTTP не требуется.

Nginx удобен как универсальный web server и reverse proxy, HAProxy — как специализированный инструмент для проксирования и балансировки, а Traefik особенно интересен для динамической контейнерной инфраструктуры.

Главное — не добавлять компоненты только ради усложнения схемы. Начните с reverse proxy на одном VPS, а полноценную балансировку внедряйте тогда, когда действительно появляются несколько backend, требования к масштабированию или отказоустойчивости.

Создайте инфраструктуру для proxy и балансировки в Serverspace

Архитектуру можно развивать постепенно: сначала развернуть приложение и Nginx на одной VPS, затем вынести reverse proxy на отдельную машину и добавить дополнительные backend-серверы по мере роста проекта.

С Serverspace вы можете использовать облачные серверы для разных ролей инфраструктуры — frontend, reverse proxy, балансировщика, backend-приложений, баз данных и вспомогательных сервисов. Такой подход позволяет самостоятельно выбирать программный стек и менять архитектуру вместе с требованиями проекта.

Например:

Serverspace VPS 1

Nginx / HAProxy

↓

VPS 2

Application

VPS 3

Application

VPS 4

Application

Распределение трафика между backend-серверами

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

Создайте VPS в Serverspace и разверните собственный reverse proxy или балансировщик нагрузки для сайта, API или другого серверного проекта.

FAQ о прокси и балансировщиках нагрузки

Чем reverse proxy отличается от балансировщика нагрузки?

Reverse proxy выступает посредником между пользователем и backend-сервером и может выполнять маршрутизацию, TLS termination, кэширование и другие функции. Балансировщик нагрузки в первую очередь распределяет запросы между несколькими backend. Один инструмент, например Nginx или HAProxy, может выполнять обе роли одновременно.

Нужен ли load balancer, если у меня только один сервер?

Обычно нет. Если приложение работает только в одном экземпляре, достаточно reverse proxy. Например, Nginx может принимать HTTPS-запросы и отправлять их приложению на локальном порту. Load balancer становится полезным после появления нескольких серверов или экземпляров приложения.

Что лучше использовать для балансировки — Nginx или HAProxy?

Nginx удобен, когда вместе с балансировкой нужен web server, reverse proxy, работа со статическими файлами, HTTPS и HTTP-маршрутизация. HAProxy специализируется на проксировании и балансировке HTTP/TCP-трафика и предоставляет развитые механизмы управления backend. Выбор зависит от архитектуры, а не от универсального рейтинга.

Что лучше — L4 или L7 load balancing?

Для сайтов и API чаще используется L7, потому что балансировщик может анализировать HTTP-запросы и маршрутизировать их по домену, URL, заголовкам или cookies. L4 полезна для TCP/UDP-сервисов и ситуаций, где анализ прикладного протокола не требуется.

Что произойдет, если один backend-сервер перестанет работать?

При правильно настроенных health checks балансировщик обнаружит проблему и перестанет направлять новые запросы на недоступный backend. Оставшиеся серверы продолжат обслуживать трафик. Однако нужно убедиться, что сам load balancer не остается единственной точкой отказа для критически важной системы.

Можно ли установить reverse proxy и приложение на одной VPS?

Да. Для небольших проектов это распространенная схема. Nginx может принимать соединения на портах 80 и 443, а приложение работать локально, например на порту 3000 или 8000. Когда нагрузка вырастет, proxy можно вынести на отдельный сервер и добавить несколько backend-узлов.

Разверните серверную инфраструктуру в Serverspace

Что такое прокси-сервер?

Forward proxy прокси со стороны клиента

Reverse proxy прокси перед сервером

Разверните прокси-сервер на VPS Serverspace

Что такое балансировщик нагрузки?

Прокси и балансировщик нагрузки — в чем разница?

Можно ли использовать reverse proxy без балансировки?

Можно ли использовать балансировщик как reverse proxy?

Балансировка L4 и L7 в чем разница?

L4 или L7 — что выбрать?

Какие алгоритмы балансировки существуют?

Что такое health check?

Active и passive health checks

Что такое sticky sessions?

Что такое TLS termination?

Зачем нужны X-Forwarded-For и другие proxy headers?

Как настроить простой reverse proxy в Nginx?

Как добавить балансировку нагрузки в Nginx?

Как включить Least Connections в Nginx?

Как использовать серверы разной мощности?

Как настроить отказоустойчивость backend в Nginx?

Как настроить балансировку через HAProxy?

Как добавить HTTP health check в HAProxy?

Nginx или HAProxy что выбрать?

Когда использовать Traefik?

Когда использовать Caddy?

Разделите proxy и backend на облачных серверах

Нужен ли отдельный сервер для балансировщика?

Почему один балансировщик остается точкой отказа?

Как убрать Single Point of Failure балансировщика?

Нужно ли ставить базу данных за load balancer?

Как proxy помогает разместить несколько сайтов на одной VPS?

Как proxy используется с Docker?

Как load balancer используется с Docker?

Что происходит при масштабировании приложения?

Что выбрать для одного небольшого сайта?

Что выбрать для нескольких экземпляров приложения?

Что выбрать для API?

Что выбрать для микросервисов?

Proxy, API Gateway и Load Balancer — это одно и то же?

Нужна ли CDN, если уже есть reverse proxy?

Как защитить backend от прямого доступа?

Какие порты открывать на proxy?

Нужно ли включать rate limiting?

Какие таймауты нужно настроить?

Как proxy работает с WebSocket и долгоживущими соединениями?

Что мониторить на reverse proxy и load balancer?

Какие логи нужны?

Что означает ошибка 502 Bad Gateway?

Что означает 504 Gateway Timeout?

Основные ошибки при настройке прокси и балансировщика

Как выбрать между proxy и load balancer?

Какой вариант выбрать для разных проектов?

Checklist перед запуском proxy или load balancer

Итог прокси или балансировщик нагрузки?

Создайте инфраструктуру для proxy и балансировки в Serverspace

FAQ о прокси и балансировщиках нагрузки