Reverse Proxy (Nginx, Caddy, Traefik)

1. Przegląd koncepcji i problem systemowy

Początkujący programiści często próbują wystawiać swoje serwery bezpośrednio do internetu, uruchamiając npm start lub uvicorn main:app na porcie 80. Taka konfiguracja stanowi rażące naruszenie standardów architektonicznych środowiska produkcyjnego:

• Bezpieczeństwo: Proces nasłuchujący na portach 80 i 443 musi posiadać uprawnienia superużytkownika (root). Każda podatność w zależnościach npm daje hakerowi pełną kontrolę nad systemem operacyjnym.
• Ataki typu Slowloris (wolne połączenia): Klient o słabym łączu, wysyłający pojedyncze bajty co 10 sekund, zablokuje wątek roboczy Node.js lub Pythona, paraliżując obsługę innych użytkowników.
• Nieefektywność dystrybucji statycznych plików: Serwowanie obrazków, fontów i plików JS przez procesy aplikacji zużywa zasoby CPU, które powinny być przeznaczone na logikę biznesową.
• Kruchość SSL: Konieczność konfigurowania szyfrowania wewnątrz kodu aplikacji wymusza restart usługi przy każdej aktualizacji certyfikatu.

Reverse Proxy (serwer proxy zwrotny) pełni rolę bezpiecznych drzwi wejściowych Twojej infrastruktury. Przyjmuje on zewnętrzny ruch internetowy, deszyfruje połączenia HTTPS, kompresuje dane, buforuje pliki statyczne i transparentnie przekazuje czysty ruch wewnętrzny na lokalne porty Twoich izolowanych aplikacji (127.0.0.1:3000).

2. Taksonomia architektoniczna i model mentalny

Pejzaż architektoniczny serwerów proxy zwrotnych klasyfikuje się według paradygmatu konfiguracji:

┌─────────────────────────────────────────────────────────────┐
│                 MATRIX PORÓWNAWCZY PROXY ODWRÓCONYCH        │
├─────────────────────────────────────────────────────────────┤
│ 1. Nginx: Architektura C sterowana zdarzeniami (epoll / kqueue) │
│    • Maksymalna wydajność surowa, minimalne zużycie pamięci │
│    • Wymaga zewnętrznego Certbot dla Let's Encrypt          │
├─────────────────────────────────────────────────────────────┤
│ 2. Caddy: Serwer Go bezpieczny pod względem pamięci z Auto-HTTPS (ACME) │
│    • Natywne automatyczne pozyskiwanie i rotacja SSL        │
│    • Nowoczesna, zwięzła składnia (Caddyfile)               │
│    • Natywne wsparcie HTTP/3 (QUIC) „out of the box”       │
├─────────────────────────────────────────────────────────────┤
│ 3. Traefik: Router kontenerowy Cloud-Native                 │
│    • Dynamiczne wykrywanie usług na podstawie etykiet Docker Labels │
│    • Idealny do automatyzacji PaaS (Coolify, Kubernetes)    │
└─────────────────────────────────────────────────────────────┘

1. Terminacja TLS/SSL (SSL Termination):
   • Proxy przejmuje na siebie zasobożerne operacje kryptograficzne związane z uzgadnianiem protokołu (TLS Handshake), odciążając backend.
2. Routing wirtualnych hostów (Virtual Hosting & Routing):
   • Pozwala na hostowanie dziesiątek różnych projektów na jednym serwerze z jedną adresem IP:
     • gotburnout.com ➔ lokalny kontener na porcie 3000 (Next.js).
     • api.gotburnout.com ➔ lokalny kontener na porcie 8000 (FastAPI).
     • n8n.gotburnout.com ➔ wewnętrzny port 5678 (n8n).
3. Proxy dla strumieni czasu rzeczywistego (WebSockets & SSE):
   • Specjalna obsługa nagłówka Upgrade oraz wyłączenie buforowania w celu utrzymania połączeń pełnoduplexowych i streamingu generowania tokenów z modeli LLM.
4. Kompresja w locie (Gzip & Brotli):
   • Kompresuje zasoby tekstowe, zmniejszając wolumen przesyłanego do klienta ruchu o 60–80%.

3. Pipeline techniczny i mechanika wewnętrzna

Cykl życia żądania klienta przechodzącego przez reverse proxy:

1. Nawiązanie bezpiecznego połączenia (TLS Handshake): Klient inicjuje połączenie na porcie 443. Caddy lub Nginx negocjują protokół TLS 1.3, wysyłają ważny certyfikat domeny i szyfrują kanał komunikacyjny.
2. Analiza nagłówków i SNI (Server Name Indication): Proxy odczytuje nagłówek Host: gotburnout.com oraz ścieżkę URL /api/v1/chat.
3. Normalizacja nagłówków proxy: Proxy dodaje nagłówki służbowe, aby aplikacja wewnętrzna znała prawdziwy adres IP klienta:

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

4. Przekazanie do upstreamu (Upstream Dispatch): Żądanie jest kierowane do lokalnego gniazda http://127.0.0.1:3000 poprzez wcześniej otwartą pulę połączeń (Connection Pooling).
5. Odbiór i przekazanie odpowiedzi klientowi:
   • Jeśli zwracany jest plik statyczny — proxy go buforuje.
   • Jeśli jest to streaming tokenów (SSE) — proxy natychmiast transmituje każdy chunk do klienta bez akumulacji w buforze.

4. Praktyczne scenariusze inżynierskie w środowisku produkcyjnym

01. Konfiguracja Caddy dla Next.js i streamingu AI w 10 liniach

Plik Caddyfile dla środowiska produkcyjnego z automatycznym HTTPS i wsparciem dla streamingu:

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. Konfiguracja Nginx dla Server-Sent Events (SSE)

Zapobieganie zawieszaniu się streamingu w 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. Routing wieloserwisowej platformy na jednym serwerze

Organizacja dostępu do narzędzi wewnętrznych:

• Caddy rozkłada ruch: żądania do ai.company.internal kieruje do kontenera Ollama, a metrics.company.internal – do panelu Grafana, zabezpieczając dostęp podstawową autoryzacją (basic_auth).

5. Pułapki, typowe błędy i bezpieczeństwo

• Zawieszenie streamingu przez buforowanie: Najczęstszy błąd w Nginx to domyślnie włączony proxy_buffering. Użytkownik widzi pusty ekran przez 30 sekund, po czym cała wygenerowana treść pojawia się nagle.
• Podmiana IP przez niezaufane nagłówki (IP Spoofing): Jeśli Twój backend naiwnie czyta req.headers['x-forwarded-for'] bez weryfikacji, że żądanie pochodzi właśnie od Twojego lokalnego proxy, atakujący może sfałszować dowolny adres IP, aby obejść limity zapytań (rate limits).
• Host Header Injection: Jeśli w konfiguracji Nginx ustawiony jest blok domyślny (default_server), który przekazuje ruch bez weryfikacji nazwy hosta, atakujący może manipulować linkami resetującymi hasło poprzez sfałszowany nagłówek Host.
• Zapomniane timeouty dla długich zapytań AI: Domyślny timeout oczekiwania na odpowiedź z backendu wynosi 60 sekund (proxy_read_timeout 60s). Jeśli złożony model rozumowania myśli przez 90 sekund, proxy zwróci klientowi błąd 504 Gateway Timeout. Zwiększaj timeouty dla tras związanych z AI.