Обратный прокси (Nginx, Caddy, Traefik)

1. Обзор концепции и системная проблема

Разработчики-начинающие часто пытаются поднять свой сервер прямо в интернете: запускают npm start или uvicorn main:app на 80-м порту. Такая конфигурация является грубым нарушением архитектурных стандартов продакшена:

• Безопасность: для прослушивания портов 80 и 443 процесс должен обладать привилегиями суперпользователя (root). Любая уязвимость в зависимости npm дает хакеру полный контроль над операционной системой.
• Атаки медленных соединений (Slowloris): клиент с плохим соединением, который отправляет по одному байту каждые 10 секунд, заблокирует рабочий поток Node.js или Python, парализуя обслуживание других пользователей.
• Неэффективность раздачи статики: отправка изображений, шрифтов и JS-файлов через процессорные потоки приложения сжигает ресурсы, которые должны тратиться на бизнес-логику.
• Хрупкость SSL: необходимость настраивать шифрование внутри кода приложения заставляет перезапускать сервис при каждом обновлении сертификата.

Обратный прокси выступает парадными защищенными дверями вашей инфраструктуры. Он принимает внешний интернет-трафик, расшифровывает HTTPS-соединение, сжимает данные, кэширует статику и прозрачно пересылает чистый внутренний трафик на локальные порты ваших изолированных приложений (127.0.0.1:3000).

2. Архитектурная таксономия и ментальная модель

Архитектурный ландшафт обратных прокси классифицируется по парадигме конфигурации:

┌─────────────────────────────────────────────────────────────┐
│                 СРАВНЕНИЕ ОБРАТНЫХ ПРОКСИ                  │
├─────────────────────────────────────────────────────────────┤
│ 1. Nginx: Архитектура на основе событий (epoll / kqueue)    │
│    • Максимальная сырая производительность, минимум памяти   │
│    • Требует внешнего Certbot для Let's Encrypt              │
├─────────────────────────────────────────────────────────────┤
│ 2. Caddy: Безопасный Go-сервер с Auto-HTTPS (ACME)         │
│    • Нативное автоматическое получение и ротация SSL        │
│    • Современный лаконичный синтаксис (Caddyfile)           │
│    • Нативная поддержка HTTP/3 (QUIC) из коробки            │
├─────────────────────────────────────────────────────────────┤
│ 3. Traefik: Облачный маршрутизатор контейнеров              │
│    • Динамическое подхватывание сервисов по меткам Docker   │
│    • Идеально для автоматизации PaaS (Coolify, Kubernetes)  │
└─────────────────────────────────────────────────────────────┘

1. Терминация TLS/SSL (SSL Termination):
   • Прокси берет на себя ресурсоемкие криптографические операции рукостискания (TLS Handshake), освобождая бэкенд от нагрузки.
2. Маршрутизация виртуальных хостов (Virtual Hosting & Routing):
   • Позволяет на одном сервере с одной IP-адресой хостить десятки различных проектов:
     • gotburnout.com ➔ локальный контейнер порта 3000 (Next.js).
     • api.gotburnout.com ➔ локальный контейнер порта 8000 (FastAPI).
     • n8n.gotburnout.com ➔ внутренний порт 5678 (n8n).
3. Проксирование потоков реального времени (WebSockets & SSE):
   • Специальная обработка заголовков Upgrade и отключение буферизации для поддержки полудуплексных соединений и стриминга генерации токенов от LLM.
4. Сжатие на лету (Gzip & Brotli):
   • Сжимает текстовые ресурсы, уменьшая объем переданного клиенту трафика на 60–80%.

3. Технический пайплайн и внутренняя механика

Жизненный цикл прохождения клиентского запроса через обратный прокси:

1. Установление защищенного соединения (TLS Handshake): Клиент инициирует соединение на порт 443. Caddy или Nginx согласовывает протокол TLS 1.3, отправляет действительный сертификат домена и шифрует канал.
2. Анализ заголовков и SNI (Server Name Indication): Прокси считывает заголовок Host: gotburnout.com и URL-путь /api/v1/chat.
3. Нормализация заголовков прокси: Прокси добавляет служебные заголовки, чтобы внутреннее приложение знало реальный IP-адрес клиента:

   X-Real-IP: 203.0.113.195
   X-Forwarded-For: 203.0.113.195, 10.0.0.1
   X-Forwarded-Proto: https
   

4. Передача на апстрим (Upstream Dispatch): Запрос перенаправляется на локальный сокет http://127.0.0.1:3000 через предварительно открытый пул соединений (Connection Pooling).
5. Получение и передача ответа клиенту:
   • Если возвращается статический файл — прокси кэширует его.
   • Если это стриминг токенов (SSE) — прокси мгновенно транслирует каждый чанк клиенту без накопления в буфере.

4. Практические инженерные сценарии в продакшене

01. Настройка Caddy для Next.js и стриминга AI за 10 строк

Файл Caddyfile для продакшена с автоматическим HTTPS и поддержкой стриминга:

gotburnout.com {
    encode zstd gzip

    # Проксирование приложения
    reverse_proxy 127.0.0.1:3000 {
        # Отключение буферизации для мгновенного стриминга LLM токенов
        flush_interval -1
    }

    # Кэширование статических файлов Next.js на 1 год
    @static path /_next/static/*
    header @static Cache-Control "public, max-age=31536000, immutable"
}

02. Конфигурация Nginx для Server-Sent Events (SSE)

Предотвращение зависания стриминга в Nginx:

location /api/generate {
    proxy_pass http://127.0.0.1:8000;
    proxy_http_version 1.1;
    proxy_set_header Connection '';
    
    # Критически важные директивы для стриминга AI:
    proxy_buffering off;
    proxy_cache off;
    chunked_transfer_encoding on;
    proxy_read_timeout 600s;
}

03. Маршрутизация мультисервисной платформы на одном сервере

Организация доступа к внутренним инструментам:

• Caddy распределяет трафик: запросы к ai.company.internal направляет на контейнер Ollama, а metrics.company.internal — на панель Grafana, закрывая доступ базовой авторизацией (basic_auth).

5. Подводные камни, типовые ошибки и безопасность

• Зависание стриминга из-за буферизации: Наиболее распространенная ошибка в Nginx — включенная по умолчанию proxy_buffering. Пользователь видит пустой экран в течение 30 секунд, после чего вся сгенерированная статья появляется одновременно.
• Подмена IP через ненадежные заголовки (IP Spoofing): Если ваш бэкенд наивно читает req.headers['x-forwarded-for'] без проверки того, что запрос поступил именно от вашего локального прокси, злоумышленник может подделать любой IP-адрес для обхода рейт-лимитов.
• Host Header Injection: Если в конфигурации Nginx установлен блок по умолчанию (default_server), который пересылает трафик без проверки имени хоста, злоумышленник может манипулировать ссылками сброса пароля через поддельный заголовок Host.
• Забытые таймауты для долгих AI-запросов: Стандартный таймаут ожидания ответа от бэкенда составляет 60 секунд (proxy_read_timeout 60s). Если сложная модель размышляет 90 секунд, прокси вернет клиенту 504 Gateway Timeout. Увеличивайте таймаут для AI-маршрутов.