Pourquoi soigner son reverse proxy sur VPS
Sur un VPS, le serveur web frontal est la pièce qui orchestre tout : il termine le TLS, distribue le trafic vers vos conteneurs (app, forge, media-server, LLM), sert les fichiers statiques et applique les en-têtes de sécurité. Bien choisi, il simplifie radicalement la mise en HTTPS de tous vos sous-domaines. Caddy obtient et renouvelle les certificats Let's Encrypt automatiquement, sans configuration, avec un fichier Caddyfile lisible de quelques lignes. Nginx, référence du marché, offre un contrôle extrêmement fin (cache, règles de réécriture, équilibrage de charge, rate limiting) mais exige une gestion manuelle ou via Certbot des certificats. Le choix oppose l'automatisme moderne à la maîtrise totale éprouvée.
Ce qu'un bon frontal apporte à votre VPS
- Terminaison TLS centralisée pour tous vos sous-domaines
- Reverse proxy unique vers plusieurs conteneurs Docker
- Service de fichiers statiques rapide et compression (gzip/brotli)
- En-têtes de sécurité (HSTS, CSP) appliqués au même endroit
- Avec Caddy : certificats Let's Encrypt obtenus et renouvelés tout seuls
- Avec Nginx : cache, rate limiting et load balancing finement réglés
Prérequis : un frontal frugal
Un reverse proxy est très léger : Caddy comme Nginx tournent confortablement sur 1 vCPU et 512 Mo à 1 Go de RAM, même en frontal de plusieurs services. La ressource à surveiller est plutôt la bande passante et le nombre de connexions simultanées. Il vous faut un domaine et ses sous-domaines pointés vers l'IP du VPS (enregistrements A/AAAA), les ports 80 et 443 ouverts sur le pare-feu (le port 80 est requis pour la validation des certificats), et Docker si vous conteneurisez le proxy. Aucun GPU ni gros stockage : ici, c'est la configuration qui fait la différence, pas la puissance brute.
Mettre en place Caddy (ou Nginx) en reverse proxy
Pointer les DNS
Créez les enregistrements A (et AAAA si IPv6) pour chaque sous-domaine (app, git, media) vers l'IP du VPS. La validation Let's Encrypt échouera tant que la résolution DNS n'est pas effective, alors vérifiez-la avant tout.
Ouvrir les ports 80 et 443
Autorisez uniquement 80 et 443 sur le pare-feu. Le port 80 reste indispensable pour le challenge HTTP de Let's Encrypt et pour rediriger automatiquement le trafic vers HTTPS.
Rédiger la configuration
Avec Caddy, un bloc suffit : app.votredomaine.com { reverse_proxy 127.0.0.1:3000 } et le HTTPS est automatique. Avec Nginx, écrivez un server par sous-domaine avec proxy_pass et les en-têtes X-Forwarded-*, puis obtenez le certificat via Certbot.
Lancer et recharger sans coupure
Démarrez le service (docker compose up -d ou systemd). Après chaque modification, validez la config (nginx -t ou caddy validate) puis rechargez à chaud (nginx -s reload / caddy reload) pour ne jamais interrompre le trafic.
Durcir la sécurité
Activez HSTS, masquez la version du serveur, forcez TLS 1.2+ et ajoutez un rate limiting basique. Centralisez ces en-têtes au niveau du proxy pour qu'ils s'appliquent à tous les services en aval.
Mettre en place les logs et le monitoring
Activez les logs d'accès et d'erreur, et surveillez les codes 502/504 qui révèlent un conteneur en aval injoignable. Un frontal sain mais des erreurs 502 pointent toujours vers le service proxifié, pas vers le proxy.
| Critère | Caddy | Nginx |
|---|---|---|
| HTTPS / certificats | Automatique, zéro config | Manuel ou via Certbot |
| Syntaxe de configuration | Caddyfile, très concis | Plus verbeuse, très expressive |
| Courbe d'apprentissage | Faible | Modérée à élevée |
| Contrôle fin (cache, rewrite, LB) | Bon, parfois via plugins | Très complet et éprouvé |
| Performances statiques | Excellentes | Excellentes, référence |
| HTTP/3 / QUIC | Active par défaut | Supporte selon version |
| Écosystème / documentation | Récent, en croissance | Vaste, très mature |
| Idéal pour | Mise en HTTPS rapide, multi-sous-domaines | Réglages avancés, fort trafic |
Si vous hésitez, sachez qu'ils ne s'excluent pas : un pattern courant place Caddy en tout premier frontal pour gérer automatiquement le TLS de tous vos sous-domaines, puis laisse Nginx en aval pour le cache fin et les règles de réécriture d'un service précis. Vous combinez ainsi l'automatisme des certificats et la maîtrise du tuning, sans choisir un camp définitif.
