Обратный прокси и балансировщик: когда что использовать

Вы наверняка слышали, как термины «обратный прокси» и «балансировщик нагрузки» используют как взаимозаменяемые. Но когда вы настраиваете Nginx, понимание разницы имеет значение — это влияет на архитектуру инфраструктуры, работу с SSL и масштабирование приложения.

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

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

Обратный прокси находится между клиентами и вашими бэкенд-серверами. Он принимает запросы клиентов, перенаправляет их на соответствующий бэкенд и возвращает ответ. Клиент никогда не общается с бэкендом напрямую.

Типичные применения:

• Терминация SSL: обработка HTTPS на прокси, чтобы бэкенды работали только с HTTP.
• Кэширование: хранение статических ресурсов или ответов API для снижения нагрузки на бэкенд.
• Безопасность: сокрытие деталей бэкенда, фильтрация запросов и защита от DDoS.
• Сжатие: gzip или Brotli ответов перед отправкой клиентам.

Nginx часто используется как обратный прокси перед серверами приложений, такими как Node.js, Python (Gunicorn/uWSGI) или Java (Tomcat).

Что такое балансировщик нагрузки?

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

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

• Распределение трафика: распределение запросов с помощью алгоритмов, таких как round-robin, least connections или IP hash.
• Проверки работоспособности: автоматическое прекращение отправки трафика на неработоспособные серверы.
• Сохранение сессии: удержание пользователя на одном и том же бэкенде при необходимости.

Балансировщики нагрузки могут быть аппаратными (F5, Citrix) или программными (Nginx, HAProxy, облачный LB). Модуль upstream в Nginx делает его полноценным программным балансировщиком нагрузки.

Обратный прокси vs балансировщик нагрузки: ключевые различия

На практике балансировщик нагрузки — это специализированный обратный прокси. Многие инструменты, включая Nginx, могут выполнять обе функции одновременно.

Когда использовать обратный прокси

Используйте обратный прокси, когда вам нужно:

• Обслуживать один бэкенд-сервер, но при этом нужны SSL, кэширование или сжатие.
• Разместить несколько приложений на разных путях или поддоменах за одним IP.
• Добавить дополнительный уровень безопасности, не раскрывая бэкенд напрямую.

Пример: API на Node.js, работающий на порту 3000, с Nginx, обрабатывающим HTTPS и отдающим статические файлы.

server {
    listen 443 ssl;
    server_name api.example.com;

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

    location / {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Когда использовать балансировщик нагрузки

Используйте балансировщик нагрузки, когда у вас есть:

• Несколько бэкенд-серверов для обработки высокого трафика.
• Потребность в высокой доступности — если один сервер выходит из строя, другие берут на себя нагрузку.
• Поэтапные развёртывания или blue-green развёртывания.

Пример: Три экземпляра Node.js за Nginx с использованием round-robin.

upstream backend {
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
    server 10.0.0.3:3000;
}

server {
    listen 80;
    server_name api.example.com;

    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

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

Совмещение обеих ролей в Nginx

В большинстве реальных конфигураций Nginx используется и как обратный прокси, и как балансировщик нагрузки. Например:

upstream app_servers {
    least_conn;
    server 10.0.0.1:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.2:3000 max_fails=3 fail_timeout=30s;
    server 10.0.0.3:3000 backup;
}

server {
    listen 443 ssl;
    server_name app.example.com;

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

    location /static/ {
        root /var/www/static;
        expires 30d;
    }

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

Здесь Nginx завершает SSL, отдаёт статические файлы и балансирует нагрузку между тремя серверами приложений с проверками работоспособности.

Лучшие практики для Nginx как обратного прокси / балансировщика нагрузки

• Устанавливайте правильные заголовки: всегда передавайте Host, X-Real-IP и X-Forwarded-For, чтобы бэкенд знал исходного клиента.
• Включите HTTP/2: добавьте http2 в директиву listen для лучшей производительности.
• Настройте буферы и таймауты: настройте proxy_buffer_size, proxy_read_timeout в зависимости от поведения вашего приложения.
• Используйте проверки работоспособности: в Nginx Open Source есть пассивные проверки; Nginx Plus предлагает активные проверки.
• Логируйте с умом: используйте пользовательский формат логов для записи времени ответа upstream для отладки.

Анализ логов Nginx критически важен для выявления узких мест. Инструменты вроде Nginx Log Analyzer помогут быстро разобрать логи доступа и выявить медленные upstream или ошибки.

FAQ

Может ли Nginx быть одновременно обратным прокси и балансировщиком нагрузки?

Да. Nginx может завершать SSL, кэшировать контент и распределять запросы между несколькими бэкендами одновременно. Блок upstream определяет пул бэкендов, а директива proxy_pass перенаправляет запросы.

Нужен ли мне балансировщик нагрузки, если у меня только один бэкенд-сервер?

Не обязательно. Обратный прокси сам по себе может обрабатывать SSL, кэширование и безопасность. Но добавление балансировщика с несколькими бэкендами повышает доступность — если один сервер выходит из строя, другие могут обслуживать трафик.

Как Nginx выбирает, на какой бэкенд отправить запрос?

По умолчанию Nginx использует round-robin. Вы можете изменить это с помощью директив, таких как least_conn (наименьшее количество соединений), ip_hash (привязка сессий на основе IP клиента) или hash (пользовательский ключ).

Готовы оптимизировать вашу конфигурацию Nginx? Начните с анализа логов с помощью нашего бесплатного парсера логов Nginx, чтобы выявить проблемы производительности и донастроить конфигурацию.