← Back to blog

Proxy, Reverse Proxy и Load Balancer: роли и границы ответственности

Feb, 21, 2026

#networking#proxy#load-balancing#http

⚙️ Теория

1) Forward Proxy

Forward proxy действует от имени клиента:

  • клиент явно отправляет трафик через proxy;
  • proxy применяет policy (доступ, аудит, фильтрация);
  • часто используется в корпоративных сетях и egress-контуре.

Для HTTPS-проксирования важен метод CONNECT (HTTP Semantics, RFC 9110).

2) Reverse Proxy

Reverse proxy стоит перед backend-сервисами:

  • принимает клиентский трафик;
  • терминирует TLS (часто);
  • маршрутизирует запросы к upstream;
  • добавляет кросс-функции: rate limiting, WAF, caching, auth integration.

Клиент обычно "не видит" backend напрямую.

3) Load Balancer (L4/L7)

Load balancer распределяет нагрузку между инстансами:

  • L4: балансировка по транспортным признакам (IP/port/protocol);
  • L7: балансировка на уровне HTTP/URI/headers/cookies.

Типовые алгоритмы:

  • round robin;
  • least connections;
  • hash/sticky-варианты.

🔍 Критичная граница: клиентский IP и доверие к заголовкам

Если есть reverse proxy/LB, backend может видеть IP прокси вместо реального клиента.
Решение:

  • корректно передавать и валидировать Forwarded (RFC 7239) или X-Forwarded-* с trusted proxy model;
  • не доверять таким заголовкам от недоверенных источников.

❓ Что нужно уметь объяснить

Почему reverse proxy это не всегда load balancer?

Reverse proxy может обслуживать один backend и выполнять security/route/TLS-задачи.
Load balancing это отдельная функция, которая может быть, а может не быть включена.

Когда нужен L4, а когда L7 балансировщик?

  • L4 подходит для простого и быстрого распределения TCP/UDP;
  • L7 нужен, когда маршрутизация зависит от HTTP-контекста (host/path/header/cookie).

Где чаще всего ломается production?

  • неверные таймауты между proxy и upstream;
  • отсутствие health checks;
  • неправильная передача client IP;
  • sticky sessions при stateful backend без корректной стратегии.

🧪 Практика

1. Reverse proxy + upstream в NGINX

upstream app_backend {
    server 10.0.0.11:8080;
    server 10.0.0.12:8080;
}

server {
    listen 443 ssl;
    server_name example.com;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://app_backend;
    }
}

2. Чеклист таймаутов и ретраев

  • согласовать connect/read/send timeout между proxy и backend;
  • ограничить retries для неидемпотентных операций;
  • отслеживать 502/504 и saturation upstream pool.

3. Базовые health checks

  • активные/пассивные проверки доступности upstream;
  • отдельные readiness endpoint'ы;
  • автоматическое исключение деградировавших инстансов.

4. Наблюдаемость для proxy/LB

Минимум метрик:

  • requests/sec;
  • p95/p99 latency;
  • upstream connect/response time;
  • 4xx/5xx по upstream;
  • queue depth/active connections.

🧾 Вывод

Forward proxy, reverse proxy и load balancer решают разные задачи и часто комбинируются.
Устойчивая схема в production строится на:

  • явном разделении ролей,
  • правильной передаче client context,
  • надежных health checks/таймаутах,
  • наблюдаемости по каждому hop.

📚 Ссылки

✅ Проверка источников

Proxy, Reverse Proxy и Load Balancer: роли и границы ответственности | Aleksandr Suprun