Skip to main content

Зворотний проксі (Nginx, Caddy, Traefik)(Зворотні проксі-сервери та термінація TLS)

Проміжний серверний архітектурний шар, який приймає зовнішній інтернет-трафік (порти 80/443), виконує термінацію SSL/TLS, стиснення (Brotli/Gzip), кешування статики та безпечно маршрутизує запити до внутрішніх додатків.

1. Огляд концепції та системна проблема

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

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

Reverse Proxy (зворотний проксі-сервер) виступає парадними захищеними дверима вашої інфраструктури. Він приймає зовнішній інтернет-трафік, розшифровує HTTPS-з'єднання, стискає дані, кешує статику і прозоро пересилає чистий внутрішній трафік на локальні порти ваших ізольованих додатків (127.0.0.1:3000).

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

Архітектурний ландшафт зворотних проксі класифікується за парадигмою конфігурації:

┌─────────────────────────────────────────────────────────────┐
│                 REVERSE PROXY COMPARISON MATRIX             │
├─────────────────────────────────────────────────────────────┤
│ 1. Nginx: Event-driven C architecture (epoll / kqueue)      │
│    • Максимальна сира продуктивність, мінімум пам'яті       │
│    • Вимагає зовнішнього Certbot для Let's Encrypt          │
├─────────────────────────────────────────────────────────────┤
│ 2. Caddy: Memory-safe Go Server with Auto-HTTPS (ACME)      │
│    • Нативне автоматичне отримання та ротація SSL           │
│    • Сучасний лаконічний синтаксис (Caddyfile)              │
│    • Нативна підтримка HTTP/3 (QUIC) з коробки              │
├─────────────────────────────────────────────────────────────┤
│ 3. Traefik: Cloud-Native Container Router                   │
│    • Динамічне підхоплення сервісів за мітками Docker Labels│
│    • Ідеально для автоматизації 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-маршрутів.
/ Часті запитанняSchema.org FAQPage

FAQ: Зворотний проксі (Nginx, Caddy, Traefik)

Прив'язка до привілейованих портів (80/443) вимагає запуску додатку під root (критичний ризик безпеки). Додатки на Node.js погано оптимізовані для повільних з'єднань (Slowloris атаки), роздача важкої статики через V8 блокує цикл подій, а падіння процесу повністю зупиняє доступ до сайту.
/ Внутрішня перелінковка
Всі терміни
VPS & DevOps

Coolify (Self-hosted PaaS)

Відкрита платформа керування інфраструктурою (Self-Hosted PaaS, відкрита альтернатива Vercel, Heroku та Render), що автоматизує деплой додатків із Git, генерацію SSL-сертифікатів, бази даних та резервне копіювання на власному VPS.

Читати термін
VPS & DevOps

Zero-Downtime Deployment (Безперервне розгортання)

Методологія та інженерні механізми оновлення продакшен-сервісів без зупинки обслуговування користувачів, обриву існуючих TCP-з'єднань та генерації HTTP помилок 502/503.

Читати термін
VPS & DevOps

Rate Limiting (Обмеження частоти запитів та захист API)

Системний механізм контролю інтенсивності вхідного та вихідного трафіку (Token Bucket, Sliding Window) для захисту бекенду від вичерпання ресурсів, брутфорсу, Layer 7 DDoS та фінансового овердрафту на AI-ендпоінтах.

Читати термін
VPS & DevOps

VPS Hosting (Віртуальний виділений сервер)

Модель надання ізольованих обчислювальних ресурсів за допомогою апаратного гіпервізора (KVM), що надає повний доступ рівня root до операційної системи Linux для розгортання автономних систем.

Читати термін