Reverse Proxy (Nginx, Caddy, Traefik)

1. Vue d'ensemble du concept et problème systémique

Les développeurs débutants tentent souvent d'exposer directement leur serveur sur Internet : ils lancent npm start ou uvicorn main:app sur le port 80. Cette configuration constitue une violation flagrante des standards architecturaux de production :

• Sécurité : L'écoute des ports 80 et 443 nécessite les privilèges superutilisateur (root). Toute vulnérabilité dans une dépendance npm offre à un attaquant un contrôle total sur le système d'exploitation.
• Attaques par connexions lentes (Slowloris) : Un client avec une mauvaise connexion, envoyant un octet toutes les 10 secondes, bloquera le thread de travail Node.js ou Python, paralysant ainsi le service pour les autres utilisateurs.
• Inefficacité de la distribution statique : La transmission d'images, de polices et de fichiers JS via les threads CPU de l'application gaspille des ressources qui devraient être dédiées à la logique métier.
• Fragilité SSL : La nécessité de configurer le chiffrement au sein même du code de l'application oblige à redémarrer le service à chaque renouvellement de certificat.

Le Reverse Proxy agit comme la porte d'entrée sécurisée de votre infrastructure. Il reçoit le trafic Internet externe, déchiffre les connexions HTTPS, compresse les données, met en cache les éléments statiques et transparaît le trafic interne pur vers les ports locaux de vos applications isolées (127.0.0.1:3000).

2. Taxonomie architecturale et modèle mental

Le paysage architectural des reverse proxies est classé selon la paradigme de configuration :

┌─────────────────────────────────────────────────────────────┐
│                 MATRICE COMPARATIVE DES PROXIES INVERSÉS    │
├─────────────────────────────────────────────────────────────┤
│ 1. Nginx : Architecture C pilotée par les événements        │
│    (epoll / kqueue)                                         │
│    • Performance brute maximale, empreinte mémoire minimale │
│    • Nécessite Certbot externe pour Let's Encrypt           │
├─────────────────────────────────────────────────────────────┤
│ 2. Caddy : Serveur Go sûr en mémoire avec HTTPS automatique │
│    (ACME)                                                   │
│    • Obtention et rotation SSL natives automatiques         │
│    • Syntaxe moderne et concise (Caddyfile)                 │
│    • Prise en charge native HTTP/3 (QUIC) prête à l'emploi  │
├─────────────────────────────────────────────────────────────┤
│ 3. Traefik : Routeur de conteneurs natif cloud              │
│    • Découverte dynamique des services via les étiquettes   │
│      Docker Labels                                          │
│    • Idéal pour l'automatisation PaaS (Coolify, Kubernetes) │
└─────────────────────────────────────────────────────────────┘

1. Terminaison TLS/SSL (SSL Termination) :
   • Le proxy prend en charge les opérations cryptographiques coûteuses du handshake (TLS Handshake), libérant le backend de cette charge.
2. Routage des hôtes virtuels (Virtual Hosting & Routing) :
   • Permet d'héberger des dizaines de projets différents sur un seul serveur avec une seule adresse IP :
     • gotburnout.com ➔ conteneur local sur le port 3000 (Next.js).
     • api.gotburnout.com ➔ conteneur local sur le port 8000 (FastAPI).
     • n8n.gotburnout.com ➔ port interne 5678 (n8n).
3. Proxyfication des flux temps réel (WebSockets & SSE) :
   • Traitement spécifique des en-têtes Upgrade et désactivation de la mise en tampon pour soutenir les connexions full-duplex et le streaming de génération de tokens depuis les LLM.
4. Compression à la volée (Gzip & Brotli) :
   • Compresse les ressources textuelles, réduisant le volume de trafic transmis au client de 60 à 80 %.

3. Pipeline technique et mécanique interne

Cycle de vie d'une requête client traversant le reverse proxy :

1. Établissement de la connexion sécurisée (TLS Handshake) : Le client initie la connexion sur le port 443. Caddy ou Nginx négocie le protocole TLS 1.3, présente un certificat de domaine valide et chiffre le canal.
2. Analyse des en-têtes et SNI (Server Name Indication) : Le proxy lit l'en-tête Host: gotburnout.com et le chemin URL /api/v1/chat.
3. Normalisation des en-têtes de proxy : Le proxy ajoute des en-têtes de service afin que l'application interne connaisse la véritable adresse IP du client :

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

4. Transmission vers l'amont (Upstream Dispatch) : La requête est redirigée vers le socket local http://127.0.0.1:3000 via un pool de connexions pré-ouvert (Connection Pooling).
5. Réception et transmission de la réponse au client :
   • Si un fichier statique est retourné — le proxy le met en cache.
   • S'il s'agit d'un streaming de tokens (SSE) — le proxy diffuse instantanément chaque chunk au client sans accumulation dans le buffer.

4. Scénarios d'ingénierie pratiques en production

01. Configuration de Caddy pour Next.js et le streaming AI en 10 lignes

Fichier Caddyfile pour la production avec HTTPS automatique et support du streaming :

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. Configuration de Nginx pour Server-Sent Events (SSE)

Prévention du blocage du streaming dans 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. Routage d'une plateforme multi-services sur un seul serveur

Organisation de l'accès aux outils internes :

• Caddy répartit le trafic : les requêtes vers ai.company.internal sont dirigées vers le conteneur Ollama, tandis que celles vers metrics.company.internal pointent vers le tableau de bord Grafana, en verrouillant l'accès par une authentification basique (basic_auth).

5. Pièges courants, erreurs typiques et sécurité

• Blocage du streaming dû à la mise en tampon : L'erreur la plus fréquente dans Nginx est l'activation par défaut de proxy_buffering. L'utilisateur voit un écran vide pendant 30 secondes, puis tout l'article généré apparaît simultanément.
• Usurpation d'IP via des en-têtes non fiables (IP Spoofing) : Si votre backend lit naïvement req.headers['x-forwarded-for'] sans vérifier que la requête provient bien de votre proxy local, un attaquant peut falsifier n'importe quelle adresse IP pour contourner les rate-limits.
• Injection d'en-tête Host (Host Header Injection) : Si la configuration Nginx inclut un bloc par défaut (default_server) qui relaie le trafic sans vérifier le nom d'hôte, un attaquant peut manipuler les liens de réinitialisation de mot de passe via un en-tête Host falsifié.
• Timeouts oubliés pour les longues requêtes AI : Le timeout standard d'attente de réponse du backend est de 60 secondes (proxy_read_timeout 60s). Si un modèle de raisonnement complexe prend 90 secondes, le proxy retournera au client une erreur 504 Gateway Timeout. Augmentez les timeouts pour les routes AI.