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

Что такое обратный прокси?

Прокси-сервер выступает посредником между клиентом и сервером: он принимает запрос от клиента, запрашивает ресурс у внутреннего сервера и возвращает его клиенту. Обратный прокси выполняет ту же роль, но «с обратной стороны»: он принимает внешние запросы и пересылает их на один или несколько внутренних (бэкенд) серверов.

Коротко: обратный прокси скрывает внутреннюю инфраструктуру, балансирует нагрузку и даёт точку контроля для фильтрации и логирования.

Преимущества обратного прокси

• Запуск нескольких приложений на одном IP и портах: обратный прокси маршрутизирует запросы по разным портам или путям.
• Балансировка нагрузки: распределение трафика между несколькими бэкендами уменьшает задержки и повышает доступность.
• Безопасность и фильтрация: прокси скрывает реальные адреса приложений, может блокировать подозрительные IP и интегрироваться с веб-фаерволами.
• Централизованная логика и метрики: все входящие запросы проходят через единую точку, что упрощает мониторинг и аудит.

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

• Очень простые статические сайты без требований к масштабированию: прямой публичный доступ может быть проще.
• Когда требуется минимальная задержка и архитектура не допускает дополнительного уровня между клиентом и сервером (жёсткие RT-ограничения).
• Если инфраструктура уже использует специализированный балансировщик уровня 4 (TCP) с нужными функциями — в некоторых сценариях он предпочтительнее.

Настройка Nginx как обратного прокси

В Nginx для проксирования запросов используется директива proxy_pass в конфигурационных файлах.

Важно: подразумевается, что Nginx уже установлен и вы знакомы с базовой структурой конфигов (sites-available/sites-enabled или /etc/nginx/nginx.conf).

Обычно Nginx слушает порт 80 (HTTP) или 443 (HTTPS), а приложение работает на другом порту, например 8081. Пример минимальной конфигурации:

server {  
  listen 80;  
  listen [::]:80;  
  
  server_name myapp.com;  
  
  location /{  
      proxy_pass http://localhost:8081/;  
}  
}

В этом примере все входящие запросы на myapp.com:80 будут перенаправлены на локальный порт 8081.

Продвинутая конфигурация

Ниже — набор часто используемых директив и объяснение, зачем они нужны.

Заголовки прокси (proxy_set_header)

Чтобы бэкенд видел оригинальный хост, IP клиента и цепочку прокси, устанавливают заголовки:

proxy_set_header        Host            $host;  
proxy_set_header        X-Real-IP       $remote_addr;  
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;

Эти заголовки помогают приложению корректно логировать источники запросов и формировать абсолютные URL.

Таймауты

Нужно контролировать время на установление соединения и ожидание данных от бэкенда:

proxy_connect_timeout   90;  
proxy_send_timeout      90;  
proxy_read_timeout      90;

Значения подбираются под вашу нагрузку и задержки сети.

Буферизация ответа

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

proxy_buffers           32 4k;
# Отключить буферизацию, если передаётся большой поток данных (стриминг / загрузка файлов)
proxy_buffering         off;

Если приложение отдаёт большие файлы или использует WebSocket, подумайте о выключении буферизации и включении proxy_http_version 1.1 с корректными Connection заголовками.

Дополнительные полезные настройки

proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Upgrade $http_upgrade; # для WebSocket

Как это работает — мысленная модель

Представьте Nginx как «приёмную комиссию» для входящих заявок: он читает адрес и условия запроса, сопоставляет с правилами (server_name / location) и либо обслуживает запрос сам (статические файлы, кеш), либо передаёт на внутренние серверы. Это даёт одну контролируемую точку входа.

Альтернативные подходы

• HAProxy — мощный L4/L7 балансировщик с тонкой настройкой балансировки и health checks.
• Traefik — динамическая маршрутизация с интеграцией в контейнерные оркестраторы (Docker, Kubernetes).
• Apache mod_proxy — если инфраструктура уже на Apache, модуль предоставляет обратный прокси.
• Облачные балансировщики (AWS ELB/ALB, GCP Load Balancer) — упрощают управление в облаке и часто предоставляют встроенные SSL/ACL.

Выбор зависит от требований: автообнаружение сервисов, сложные health checks, интеграция с сервис-дискавери и т. п.

Чеклист для развёртывания

Для системного администратора:

• Проверить, что Nginx установлен и запускается как сервис.
• Настроить server_name и DNS (A/AAAA записи) для домена.
• Проверить права доступа к портам 80/443 и SELinux/AppArmor при необходимости.
• Настроить SSL (Let’s Encrypt / коммерческий сертификат) и редирект HTTP→HTTPS.

Для разработчика:

• Убедиться, что приложение слушает на другом порту (например, 8081) и корректно обрабатывает заголовки X-Forwarded-For.
• Добавить health endpoint для мониторинга.

Для инженера безопасности:

• Включить ограничение скорости, fail2ban или WAF.
• Ограничить административный доступ к панелям управления.
• Настроить логирование и ротацию логов.

Критерии приёмки

• Внешний домен отвечает через Nginx и отдаёт содержимое приложения.
• Заголовки X-Real-IP и X-Forwarded-For корректно доставляются в логи приложения.
• При падении одного бэкенда трафик продолжает обслуживаться другими (если настроен LB).
• Нет утечек реальных внутренних IP в публичные ответы.

Решение в виде простого дерева (Mermaid)

flowchart TD
  A[Внешний запрос] --> B{Соответствие server_name}
  B -- Да --> C{Совпадает location}
  C -- Статический файл --> D[Отдать файл]
  C -- Проксировать --> E[proxy_pass на бэкенд]
  E --> F{Бэкенд доступен?}
  F -- Да --> G[Возврат ответа клиенту]
  F -- Нет --> H[502/health check -> failover]
  B -- Нет --> I[404 или другой server]

Контрольные тесты и приёмочные сценарии

• Тест: запрос на корень сайта должен возвращать содержимое от бэкенда — проверяется curl и браузером.
• Тест: заголовок X-Real-IP показывает IP клиента в логах приложения.
• Тест отказа: вывести один из бэкендов из пула и убедиться, что запросы продолжают обслуживаться другими узлами.
• Тест производительности: провести нагрузочный тест, чтобы определить оптимальные proxy_buffers и таймауты.

Когда конфигурация не сработает (примеры)

• Неправильно указан proxy_pass (забыли слэш в конце в некоторых сценариях) — может изменить путь запроса.
• Бэкенд ожидает другой значения Host и формирует редиректы на внутренние хосты.
• Внутренние приложения не учитывают X-Forwarded-Proto и генерируют некорректные абсолютные URL.

Резюме

Nginx — надёжный и гибкий инструмент для реализации обратного прокси: простая базовая настройка, расширяемые опции для заголовков, таймаутов и буферизации. Для продакшна следует дополнительно настроить SSL, health checks, мониторинг и механизмы безопасности. При выборе решения учитывайте требования к автоматизации (Traefik), сложной балансировке (HAProxy) или облачным возможностям (облачные LBs).

Источник документации: модуль ngx_http_proxy_module в официальной документации Nginx.

Автор фото: Reverse Proxy, Reverse Proxy