Как связать frontend и backend в Nginx

Связь фронтенда и бэкенда через Nginx: полное руководство

Nginx выступает в качестве единой точки входа (API Gateway) и обратного прокси (reverse proxy), который принимает запросы от клиентов, маршрутизирует их к соответствующим сервисам (фронтенд или бэкенд) и возвращает результаты. Это фундаментальная архитектура современных веб-приложений.

Базовая архитектура и принципы

• Фронтенд (статический контент): Это собранные файлы (HTML, CSS, JS, изображения) вашего SPA (React, Vue, Angular) или статический сайт. Они доставляются клиенту как есть.
• Бэкенд (API/приложение): Это динамический сервер (Node.js, Django, Spring Boot, Go и т.д.), обрабатывающий бизнес-логику, работающий с БД и предоставляющий API.
• Роль Nginx:

    1.  Обслуживает статические файлы фронтенда напрямую (быстро и эффективно).
    2.  Перенаправляет (`proxy_pass`) API-запросы или запросы к динамическому контенту на бэкенд-сервер(ы).
    3.  Выполняет балансировку нагрузки между инстансами бэкенда.
    4.  Управляет SSL/TLS (HTTPS), сжатием, кэшированием и безопасностью.

Пример конфигурации Nginx (nginx.conf или sites-available/your-app)

Представим, что фронтенд доступен по https://app.example.com, а его API живёт на том же домене по пути /api/.

server {
    listen 80;
    server_name app.example.com;
    # Редирект всего HTTP-трафика на HTTPS
    return 301 https://$server_name$request_uri;
}

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

    # SSL конфигурация (указывайте свои пути)
    ssl_certificate /etc/ssl/certs/app.example.com.crt;
    ssl_certificate_key /etc/ssl/private/app.example.com.key;

    # Корневая директория для статических файлов фронтенда
    root /var/www/app.example.com/frontend/dist;
    index index.html;

    # 1. Обслуживание статических файлов фронтенда
    location / {
        try_files $uri $uri/ /index.html;
        # Кэширование статики для повышения производительности
        expires 1y;
        add_header Cache-Control "public, immutable";
    }

    # 2. Проксирование всех запросов к API на бэкенд
    location /api/ {
        # Удаляем префикс /api при передаче на бэкенд (опционально, зависит от API)
        # rewrite ^/api/(.*) /$1 break;

        # Адрес и порт бэкенд-сервера (например, Node.js на 3000 порту)
        proxy_pass http://localhost:3000/;
        # Или на кластер бэкендов:
        # proxy_pass http://backend_upstream/;

        # Критически важные заголовки для корректной работы прокси
        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_connect_timeout 60s;
        proxy_send_timeout 60s;
        proxy_read_timeout 60s;
        proxy_buffering off; # Важно для Server-Sent Events или WebSockets
    }

    # 3. Дополнительно: проксирование WebSocket (если требуется)
    location /ws/ {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_set_header Host $host;
    }

    # 4. Обслуживание статики самого бэкенда (если есть, например, загруженные файлы)
    location /uploads/ {
        alias /var/www/app.example.com/backend/uploads/;
        expires 7d;
        add_header Cache-Control "public";
    }

    # Безопасность: запрет доступа к скрытым файлам
    location ~ /\. {
        deny all;
    }
}

# Блок upstream для балансировки нагрузки между несколькими бэкендами
upstream backend_upstream {
    # least_conn; # Алгоритм балансировки (можно использовать ip_hash, least_conn)
    server 127.0.0.1:3000 weight=3; # Основной инстанс, вес 3
    server 127.0.0.1:3001 backup;   # Бэкапный инстанс
    keepalive 32; # Повышает производительность, сохраняя соединения
}

Ключевые директивы и их объяснение

• location /:

    *   `try_files $uri $uri/ /index.html;` — **ключевая строка для SPA**. Nginx ищет запрашиваемый файл, если не находит — пробует директорию, и если и это неудача — отдаёт `index.html`, позволяя фронтенд-роутеру (React Router, Vue Router) обработать путь на клиенте.
    *   Заголовки `Cache-Control` и `expires` значительно ускоряют повторные загрузки статики.

• location /api/:

    *   `proxy_pass` — основа связи. Указывает, куда перенаправлять запросы, попадающие в этот блок `location`.
    *   `proxy_set_header` — передаёт оригинальную информацию о клиенте (IP, протокол) на бэкенд. Без этого бэкенд видит все запросы как пришедшие от Nginx (например, с IP `127.0.0.1`), что ломает логирование и логику, зависящую от IP.
    *   `proxy_buffering off` часто требуется для long-polling запросов, Server-Sent Events или WebSockets, чтобы данные передавались в реальном времени.

• upstream:

    *   Определяет группу бэкенд-серверов для **балансировки нагрузки (load balancing)** и повышения отказоустойчивости. Nginx будет распределять запросы между ними.

Деплой и типичный workflow

1. Сборка: Фронтенд (npm run build, yarn build) собирается в папку (например, dist/).
2. Размещение: Артефакты фронтенда копируются в директорию, указанную в root (например, /var/www/app/frontend).
3. Запуск бэкенда: Бэкенд-приложение запускается как служба (через systemd, pm2, docker) на определённом порту (например, :3000).
4. Конфигурация Nginx: Прописываются пути, upstream и правила, аналогичные примеру выше.
5. Проверка и рестарт:

   # Проверить конфигурацию на ошибки
   sudo nginx -t
   
   # Применить конфигурацию (мягкая перезагрузка без обрыва соединений)
   sudo nginx -s reload
   

Преимущества такого подхода

• Производительность: Nginx оптимизирован для статики и работы с сетевыми соединениями, разгружая бэкенд.
• Безопасность: Бэкенд скрыт за прокси, можно централизованно настраивать WAF-правила, ограничивать запросы.
• Гибкость: Легко менять бэкенд-сервисы, добавлять новые версии API (/api/v2/), переносить сервисы на другие машины.
• Единая точка входа: Упрощает настройку SSL, доменов, политик CORS.

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