Reverse Proxy: архитектура и принцип работы

Архитектура Reverse Proxy: как она работает

Пользователь открывает example.com, но приложение, которое фактически формирует ответ, может работать на другом порту, другом сервере или на одном из нескольких backend-серверов. Пользователю об этом знать не нужно. Reverse proxy находится между клиентом и этими backend-сервисами: он принимает публичный запрос, определяет, куда его направить, пересылает его и возвращает клиенту ответ backend-сервера.

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

Краткий ответ

Reverse proxy — это сервер, который принимает запросы от имени одного или нескольких backend-серверов. Для клиента reverse proxy выглядит как конечный сервер. Внутри инфраструктуры он передаёт запрос подходящему upstream-сервису и возвращает полученный ответ клиенту.

В терминологии HTTP определение немного точнее: RFC 9110 описывает reverse proxy как разновидность gateway — посредника, который со стороны клиента выглядит как origin server, но пересылает запросы другим серверам. (rfc-editor.org)

Типичный путь запроса выглядит так:

Browser
   ↓
Reverse Proxy
   ↓
Application Server
   ↓
Database

При использовании нескольких приложений или серверов:

                    ┌── App Server 1
Client → Reverse Proxy ── App Server 2
                    └── API Server

Ключевые возможности

Функция	Что может делать reverse proxy
Маршрутизация	Направлять запросы в разные приложения или сервисы
Балансировка нагрузки	Распределять трафик между несколькими backend-серверами
TLS termination	Обрабатывать HTTPS перед передачей трафика во внутреннюю инфраструктуру
Кэширование	Повторно использовать подходящие ответы, не обращаясь каждый раз к origin server
Работа с заголовками	Сохранять или добавлять информацию об исходном запросе
Изоляция	Не допускать прямого публичного доступа к backend-серверам
Наблюдаемость	Централизовать access-логи, данные о времени обработки и метаданные запросов

Не каждый reverse proxy выполняет все эти функции. Его поведение зависит от конфигурации и архитектуры системы.

Что такое Reverse Proxy?

Рассмотрим сайт с публичным адресом:

https://example.com

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

http://10.0.1.12:8080

Вместо того чтобы напрямую открывать пользователям доступ к 10.0.1.12:8080, reverse proxy принимает соединения на публичной точке входа. Когда приходит запрос к example.com, proxy пересылает его внутреннему приложению.

NGINX описывает этот процесс как получение запроса, его отправку настроенному proxied server, получение ответа и возврат этого ответа клиенту. (docs.nginx.com)

Так возникает важный уровень абстракции:

Public architecture:
User → example.com

Actual architecture:
User → Reverse Proxy → Internal Service

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

Reverse Proxy и Forward Proxy

Эти два термина легко перепутать.

Forward proxy представляет клиента. Клиент намеренно отправляет через него трафик к внешним серверам.

Client → Forward Proxy → Internet

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

Internet → Reverse Proxy → Backend

RFC 9110 различает эти роли посредников и относит reverse proxy к gateway. (rfc-editor.org)

INTERNAL LINK: Forward Proxy и Reverse Proxy

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

Предположим, браузер отправляет запрос:

GET /api/products HTTP/1.1
Host: example.com

Первым запрос получает reverse proxy. После этого он может:

завершить TLS-соединение;
проверить hostname или URL-путь;
выбрать upstream-сервер;
изменить или добавить заголовки запроса;
открыть новое или повторно использовать существующее соединение с upstream;
переслать запрос;
получить ответ от upstream;
при необходимости буферизовать или закэшировать его;
вернуть ответ клиенту.

Таким образом, reverse proxy — это не просто перенаправление браузера. При HTTP redirect клиенту сообщается, что он должен самостоятельно отправить новый запрос по другому адресу. При proxying взаимодействие с backend происходит за proxy и обычно остаётся невидимым для клиента.

Маршрутизация и балансировка нагрузки

Один reverse proxy может предоставлять доступ сразу к нескольким внутренним приложениям.

Например:

example.com/        → frontend
example.com/api/    → API service
example.com/admin/  → admin application

Он также может распределять запросы между несколькими экземплярами одного приложения:

              ┌→ app-1
Client → Proxy ├→ app-2
              └→ app-3

Для этого NGINX поддерживает группы серверов. Если другой метод не настроен, по умолчанию для HTTP-балансировки нагрузки используется round-robin. Другие стратегии могут учитывать такие факторы, как количество активных соединений или настроенные веса серверов. (nginx.org)

Поэтому load balancing и reverse proxying связаны между собой, но это не одно и то же. Reverse proxy может направлять весь трафик только на один backend, а reverse proxy с балансировкой нагрузки выбирает между несколькими серверами.

INTERNAL LINK: Как работает балансировка нагрузки

TLS Termination

Распространённая архитектура выглядит так:

Browser
   │ HTTPS
   ↓
Reverse Proxy
   │ HTTP or HTTPS
   ↓
Application

Публичное TLS-соединение может завершаться на reverse proxy. Proxy хранит сертификат, выполняет TLS handshake, а затем создаёт отдельное соединение с backend.

Например, NGINX может принимать HTTPS-соединения с использованием настроенных сертификата и приватного ключа. В современной документации NGINX TLS 1.2 и TLS 1.3 указаны как протоколы, включённые по умолчанию. (nginx.org)

Нужно ли также использовать TLS между proxy и backend, зависит от границ доверия, топологии сети и требований безопасности. TLS termination на proxy не означает автоматически, что внутренний трафик всегда должен быть незашифрованным.

Сохранение информации о запросе

Backend, напрямую подключённый к reverse proxy, видит сам proxy как своего сетевого peer. Без дополнительных метаданных приложение может не получить информацию об исходном IP-адресе клиента или протоколе запроса.

RFC 7239 определяет стандартный HTTP-заголовок Forwarded, который позволяет передавать через proxy информацию об исходном клиенте, host и протоколе. В RFC также отмечается широкое использование нестандартных заголовков, включая X-Forwarded-For и X-Forwarded-Proto. (rfc-editor.org)

Например, конфигурация NGINX может выглядеть так:

upstream app_backend {
    server app1:8080;
    server app2:8080;
}

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/nginx/example.com.crt;
    ssl_certificate_key /etc/nginx/example.com.key;

    location / {
        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 http://app_backend;
    }
}

Документация NGINX описывает proxy_set_header как директиву для управления заголовками запросов, передаваемыми upstream-серверам. (docs.nginx.com)

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

Кэширование в Reverse Proxy

В некоторых случаях reverse proxy может ответить на запрос из кэша, не обращаясь к приложению.

First request:
Client → Proxy → Application

Later cache hit:
Client → Proxy

RFC 9111 определяет поведение общих HTTP-кэшей и объясняет, что повторное использование сохранённых ответов может снижать время ответа и сетевой трафик. При этом возможность кэширования всё равно определяется правилами HTTP-кэширования и директивами ответа: proxy не должен просто кэшировать каждый ответ. (rfc-editor.org)

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

INTERNAL LINK: Как работает HTTP-кэширование

Диагностика ошибок Proxy

Две распространённые ошибки reverse proxy помогают понять, где искать проблему.

502 Bad Gateway означает, что gateway или proxy получил некорректный ответ от upstream-сервера. 504 Gateway Timeout означает, что gateway не получил необходимый ответ от upstream в течение допустимого времени. (developer.mozilla.org)

Полезная схема диагностики:

SYMPTOM
502 / 504

↓ MEASURE
Proxy logs and upstream timing

↓ POSSIBLE CAUSE
Application failure
Wrong upstream address
Connection refused
DNS failure
Timeout
Firewall/network problem

↓ CONFIRM
Connect to the upstream directly from the proxy host

↓ FIX
Correct the failing layer

↓ RE-MEASURE
Repeat the request and inspect logs

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

Распространённые ошибки

Одна из ошибок — воспринимать reverse proxy как невидимый компонент, который не требует мониторинга. Если через него проходит весь трафик, проблема с proxy может затронуть каждый backend за ним.

Другая ошибка — доверять forwarded IP-заголовкам без определения границ доверенных proxy. Приложение должно понимать, какой посредник действительно имеет право передавать информацию о клиенте.

Кэширование персонализированных ответов без понимания Cache-Control, аутентификации и cache keys — ещё один серьёзный риск конфигурации. RFC 9111 устанавливает явные ограничения на то, когда shared cache может сохранять и повторно использовать ответы. (rfc-editor.org)

Наконец, само наличие reverse proxy не делает приложение автоматически быстрее. Он добавляет ещё один сетевой переход и ещё один компонент, который нужно обслуживать. Рост производительности обеспечивают такие возможности, как управление соединениями, кэширование, сжатие или распределение нагрузки, а не сам термин «reverse proxy».

FAQ

Скрывает ли reverse proxy backend-сервер?

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

Всегда ли NGINX является reverse proxy?

Нет. В зависимости от конфигурации NGINX может работать как веб-сервер, reverse proxy, cache, load balancer и выполнять другие функции. (nginx.org)

Является ли CDN reverse proxy?

Многие CDN-архитектуры работают как reverse proxy, поскольку пользователи подключаются к инфраструктуре CDN, а она получает или отдаёт контент от имени origin. Однако архитектура CDN включает дополнительные концепции распределённого кэширования и доставки контента, которые заслуживают отдельного рассмотрения.

INTERNAL LINK: Как работает CDN

Заменяет ли reverse proxy load balancer?

Не обязательно. Reverse proxying описывает роль посредника, а load balancing — способ распределения трафика. Одна и та же система может выполнять обе функции.

Может ли reverse proxy работать с WebSocket?

Да, если proxy поддерживает WebSocket и правильно настроен. Например, NGINX документирует специальные требования к конфигурации для WebSocket proxying. (nginx.org)

Итог

Reverse proxy создаёт контролируемую границу между публичными клиентами и backend-инфраструктурой.

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

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

Источники

IETF — RFC 9110: HTTP Semantics, June 2022. Определение HTTP intermediaries, gateways и reverse proxies. RFC 9110 — HTTP Semantics
IETF — RFC 7239: Forwarded HTTP Extension, June 2014. Стандартизированная передача информации о клиенте, host и протоколе через proxy. RFC 7239 — Forwarded HTTP Extension
IETF — RFC 9111: HTTP Caching, June 2022. Поведение HTTP-кэшей и требования к shared cache. RFC 9111 — HTTP Caching
NGINX Documentation — NGINX Reverse Proxy. Пересылка запросов, заголовки и буферизация ответов. NGINX Reverse Proxy documentation
NGINX Documentation — Using nginx as HTTP Load Balancer. Группы upstream-серверов и поведение балансировки нагрузки. NGINX HTTP Load Balancing documentation
NGINX Documentation — Configuring HTTPS Servers. TLS-сертификаты и настройка HTTPS-серверов. NGINX HTTPS documentation
MDN Web Docs — 502 Bad Gateway / 504 Gateway Timeout. Семантика ошибок gateway и различия с upstream timeout. MDN — 502 Bad Gateway · MDN — 504 Gateway Timeout