Что такое обратный прокси и зачем ставить его перед сайтом

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

Обратный прокси, или reverse proxy, принимает запросы пользователей вместо внутренних серверов, выбирает нужное приложение, передает ему запрос и возвращает ответ клиенту. Браузер общается с прокси, а не напрямую с Node.js, PHP, Python, Java или другим приложением. Я обычно называю обратный прокси диспетчером на входе в инфраструктуру.

Слово «обратный» появилось из-за направления работы. Обычный, или прямой, прокси действует от имени пользователя и помогает клиенту обращаться к внешним сайтам. Обратный прокси действует от имени сайта и скрывает внутренние серверы от пользователей. Такое разделение приводит MDN.

Как запрос проходит через обратный прокси

Допустим, приложение запущено на локальном адресе 127.0.0.1:3000. Напрямую такой адрес из интернета недоступен. На внешних портах 80 и 443 работает Nginx.

1. Пользователь открывает example.com.
2. DNS направляет домен на публичный IP-адрес сервера.
3. Nginx принимает HTTP- или HTTPS-запрос.
4. Nginx проверяет домен, путь, заголовки и правила маршрутизации.
5. Nginx передает запрос приложению на 127.0.0.1:3000.
6. Приложение формирует ответ.
7. Nginx возвращает ответ браузеру.

Минимальная конфигурация выглядит так.

server {
     listen 80;
     server_name example.com;
 
     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;
     }
 }

Директива proxy_pass задает адрес внутреннего приложения. Остальные строки передают исходный домен, IP-адрес клиента и протокол. Без таких заголовков приложение может считать, что все посетители приходят с адреса прокси, а HTTPS-запросы выглядят как обычные HTTP-запросы. Полный список правил и параметров содержит документация Nginx.

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

sudo nginx -t
 sudo systemctl reload nginx

Проверить маршрут можно через curl.

curl -I http://example.com

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

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

Какие задачи решает обратный прокси

Самая понятная задача заключается в публикации внутреннего приложения. Разработчик запускает сервис на порту 3000, 8000 или 8080, а Nginx открывает его через привычный домен и стандартный HTTPS-порт 443. Пользователю не нужно вводить номер порта или знать внутреннюю структуру системы.

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

server {
     listen 80;
     server_name example.com;
 
     location / {
         proxy_pass http://127.0.0.1:3000;
     }
 
     location /api/ {
         proxy_pass http://127.0.0.1:8000;
     }
 
     location /admin/ {
         proxy_pass http://127.0.0.1:9000;
     }
 }

Запросы к главной странице получит фронтенд, адреса с /api/ уйдут серверной части, а /admin/ откроет административную панель. Аналогичным способом можно распределять разные домены между сервисами.

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

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

upstream backend {
     server 10.0.0.11:3000;
     server 10.0.0.12:3000;
     server 10.0.0.13:3000;
 }
 
 server {
     listen 80;
     server_name example.com;
 
     location / {
         proxy_pass http://backend;
     }
 }

Балансировка помогает распределить нагрузку и пережить отказ отдельного сервера. Однако один Nginx на одной виртуальной машине сам превращается в единую точку отказа. Для высокой доступности нужны как минимум два прокси, проверка состояния узлов, резервный адрес или внешний балансировщик.

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

Но я бы не называл reverse proxy полноценной системой защиты. Nginx не исправит SQL-инъекцию в приложении, слабый пароль администратора, утечку ключей или опасную бизнес-логику. Прокси уменьшает поверхность атаки и дает удобную точку контроля, но не заменяет безопасный код, обновления, резервное копирование, WAF и мониторинг.

Где настройка ломается и почему

Самая частая ошибка возникает при передаче адреса клиента. Внутренний сервер видит IP-адрес Nginx, поэтому журналы, ограничения частоты и аудит перестают различать пользователей. Заголовок X-Forwarded-For решает проблему только при правильной модели доверия. Приложение не должно слепо принимать такой заголовок от любого посетителя, иначе злоумышленник подставит произвольный адрес.

Вторая типичная ошибка связана с HTTPS. Прокси принимает защищенный запрос, а приложение получает обычное соединение и начинает создавать ссылки с http://, зацикливать перенаправления или помечать защищенные cookie неверно. Приложение должно доверять заголовку X-Forwarded-Proto только от известного прокси.

Третья проблема появляется при работе WebSocket, потоковых ответов и длительных запросов. Обычный HTTP-запрос быстро заканчивается, а WebSocket оставляет соединение открытым. Для некоторых приложений приходится передавать заголовки обновления соединения и корректировать тайм-ауты.

location /socket/ {
     proxy_pass http://127.0.0.1:3000;
     proxy_http_version 1.1;
     proxy_set_header Upgrade $http_upgrade;
     proxy_set_header Connection "upgrade";
 }

Четвертая ошибка скрывается в путях. Адреса в location и proxy_pass по-разному обрабатываются в зависимости от завершающего слеша. Небольшое отличие может изменить путь, который получит приложение. После каждого правила я проверяю несколько реальных URL через curl, а не ограничиваюсь успешным запуском Nginx.

Пятая проблема связана с размером тела запроса и тайм-аутами. Загрузка большого файла может завершиться ошибкой 413 Request Entity Too Large. Медленное приложение может привести к 504 Gateway Timeout. Код 502 Bad Gateway часто означает, что Nginx не смог подключиться к внутреннему сервису, получил некорректный ответ или использовал неправильный адрес.

Маркетинговое обещание «поставьте обратный прокси, и сайт станет быстрым и защищенным» слишком упрощает картину. Прокси ускоряет сайт только при полезном кешировании, сжатии, балансировке или разгрузке TLS. Лишний посредник без грамотной настройки добавляет задержку, усложняет диагностику и создает новую точку отказа.

Ответы на частые вопросы

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