Прямой и обратный прокси: в чём разница и зачем нужен каждый

Коротко о главном

Оба вида прокси — посредники между клиентом и сервером. Разница в том, на чьей они стороне:

• Прямой прокси (forward proxy) работает на клиентов. Клиент знает о прокси и сознательно отправляет через него трафик. Сервер назначения видит прокси, а не клиента.
• Обратный прокси (reverse proxy) работает на серверы. Клиент обычно о нём не знает: он подключается к «сайту», а прокси решает, какой бэкенд на самом деле ответит.

Простое правило: прямой прокси прячет клиентов от серверов, обратный — серверы от клиентов.

Как идёт запрос

Прямой прокси:

[Ноутбук] --> [Прямой прокси] --> интернет --> [example.com]
  настроен       проверяет правила,          видит IP прокси
  на прокси      логирует, кэширует

Обратный прокси:

[Браузер] --> интернет --> [Обратный прокси] --> [app-сервер 1]
  думает, что              TLS, маршруты,  \-> [app-сервер 2]
  это example.com          кэш, лимиты      \-> [статика]

В первом случае прокси принадлежит организации пользователя. Во втором — владельцу сайта.

Зачем нужен прямой прокси

• Корпоративная фильтрация: блокировка категорий сайтов, соблюдение правил использования сети.
• Логирование и аудит исходящего трафика для службы безопасности.
• Контролируемый выход в интернет: серверы из закрытой сети ходят наружу через один известный адрес, который партнёру легко добавить в белый список.
• Кэширование часто скачиваемого, например зеркала пакетов в сборочной сети.
• Доступ «из другого места», похожий на VPN. Разница: прокси обычно обслуживает отдельные протоколы или приложения, а VPN туннелирует весь трафик устройства.

Классический пример — Squid. Многие корпоративные шлюзы безопасности и облачные secure web gateway тоже по сути прямые прокси.

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

• TLS termination: прокси хранит сертификаты и обрабатывает HTTPS, а бэкенды внутри закрытой сети общаются по обычному HTTP.
• Балансировка нагрузки между несколькими экземплярами приложения.
• Маршрутизация: /api — в один сервис, / — во фронтенд, /static — в файловое хранилище.
• Кэширование ответов и быстрая отдача статики.
• Защита: rate limiting, ограничение размера запроса, WAF, сокрытие внутренней схемы.
• Деплой без простоя: переключение трафика между старой и новой версией.

Типичные примеры: nginx, HAProxy, Traefik, Envoy, а также CDN вроде Cloudflare — по сути, глобально распределённый обратный прокси перед вашим сервером.

Минимальный обратный прокси на nginx:

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/ssl/example.crt;
    ssl_certificate_key /etc/ssl/example.key;

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

Сравнение

Частые ошибки

• Потеря реального IP клиента. За обратным прокси приложение видит адрес прокси. Передавайте X-Forwarded-For и доверяйте ему только со стороны прокси.
• Доверие заголовкам от кого угодно. Если бэкенд доступен напрямую, клиент подделает X-Forwarded-For. Держите бэкенды в закрытой сети.
• Неверная схема в редиректах. Когда TLS завершается на прокси, приложение думает, что запрос пришёл по HTTP, и строит ссылки http://. Передавайте X-Forwarded-Proto.
• Открытый прямой прокси. Прокси без аутентификации на публичном IP быстро начнут использовать посторонние.
• Кэширование личных страниц. Кэш обратного прокси должен учитывать cookies и Cache-Control, иначе один пользователь увидит данные другого.