Обратный прокси (reverse proxy)

Обратный прокси (англ. reverse proxy) — сервер, который стоит перед одним или несколькими серверами приложений и принимает запросы клиентов вместо них. Клиент обращается к прокси, как к самому сайту, прокси пересылает запрос подходящему внутреннему серверу (бэкенду), получает ответ и возвращает его клиенту. Клиент ничего не знает о бэкендах: их количество, адреса и технологии скрыты.^[1]

Обычный (прямой) прокси работает на стороне клиента и выходит в интернет от его имени; обратный — на стороне сервера и представляет сервис перед интернетом. Почти любой сайт работает за обратным прокси — nginx, Caddy, HAProxy, облачным балансировщиком или CDN.

Зачем нужен

Сервер приложения на Python или Node.js обычно не стоит выставлять в интернет напрямую: он хуже справляется с тысячами медленных соединений, TLS, сжатием и атаками, чем специализированный прокси.

Пример: nginx

upstream app {
    server 127.0.0.1:8001;
    server 127.0.0.1:8002;          # два экземпляра приложения
}

server {
    listen 443 ssl;
    http2 on;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    location /static/ {
        root /var/www/example;      # статику отдаёт сам прокси
        expires 30d;
    }

    location / {
        proxy_pass http://app;
        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_pass пересылает запросы группе upstream, а заголовки передают бэкенду сведения о настоящем клиенте.^[2] В Caddy та же задача решается одной строкой reverse_proxy 127.0.0.1:8001 127.0.0.1:8002, а сертификат выпускается автоматически.

Адрес клиента и заголовки

Для бэкенда все запросы приходят с адреса прокси. Настоящий адрес клиента и исходный протокол передают заголовками X-Forwarded-For, X-Forwarded-Proto и X-Forwarded-Host или стандартным Forwarded (RFC 7239).^[3] Бэкенд должен доверять этим заголовкам только от своего прокси: иначе клиент подделает X-Forwarded-For и обойдёт ограничения по IP. Фреймворки для этого имеют настройки доверенных прокси (например, --forwarded-allow-ips в Uvicorn для FastAPI).

Если бэкенд не знает, что исходный запрос был по HTTPS, он может строить ссылки и редиректы на http:// — классическая ошибка «бесконечного редиректа», которую решает X-Forwarded-Proto.

Балансировка

Алгоритмы распределения запросов: по кругу (round robin), по наименьшему числу соединений, по хешу адреса клиента или ключа (чтобы клиент попадал на один и тот же бэкенд). Прокси проверяет здоровье бэкендов — пассивно по ошибкам или активно запросами к /health — и исключает неисправные. Балансировку на уровне TCP (L4) и HTTP (L7) различают по тому, читает ли прокси содержимое запросов (см. Модель OSI).

Популярные решения

В Kubernetes роль обратного прокси выполняют Ingress-контроллеры и реализации Gateway API (см. Service и Ingress), в облаке — управляемые балансировщики, а API-шлюзы добавляют аутентификацию, квоты и аналитику.

Типичные проблемы

• Ошибки 502 и 504 — прокси не смог получить ответ от бэкенда: приложение упало, недоступно или отвечает дольше тайм-аута (см. Коды состояния HTTP).
• WebSocket и потоковые ответы требуют настройки: передачи заголовков Upgrade и Connection, отключения буферизации для потоковой генерации.
• Ограничение размера тела (client_max_body_size в nginx) — загрузка больших файлов падает с кодом 413.
• Двойное сжатие или кэширование персональных ответов — кэш должен учитывать заголовки Cache-Control и Vary.

См. также

• nginx
• Caddy
• Балансировка нагрузки
• CDN
• Service и Ingress

Источники

1. Cloudflare Learning — What is a reverse proxy?
2. nginx — ngx_http_proxy_module
3. RFC 7239 — Forwarded HTTP Extension
4. HAProxy Documentation
5. Traefik Documentation
6. Envoy Proxy Documentation