Pourquoi soigner son reverse proxy sur VPS
Sur un VPS, le serveur web frontal est la piece 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-tetes de securite. 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, reference du marche, offre un controle extremement fin (cache, regles de reecriture, equilibrage de charge, rate limiting) mais exige une gestion manuelle ou via Certbot des certificats. Le choix oppose l'automatisme moderne a la maitrise totale eprouvee.
Ce qu'un bon frontal apporte a votre VPS
- Terminaison TLS centralisee pour tous vos sous-domaines
- Reverse proxy unique vers plusieurs conteneurs Docker
- Service de fichiers statiques rapide et compression (gzip/brotli)
- En-tetes de securite (HSTS, CSP) appliques au meme endroit
- Avec Caddy : certificats Let's Encrypt obtenus et renouveles tout seuls
- Avec Nginx : cache, rate limiting et load balancing finement regles
Prerequis : un frontal frugal
Un reverse proxy est tres leger : Caddy comme Nginx tournent confortablement sur 1 vCPU et 512 Mo a 1 Go de RAM, meme en frontal de plusieurs services. La ressource a surveiller est plutot la bande passante et le nombre de connexions simultanees. Il vous faut un domaine et ses sous-domaines pointes 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 difference, pas la puissance brute.
Mettre en place Caddy (ou Nginx) en reverse proxy
Pointer les DNS
Creez les enregistrements A (et AAAA si IPv6) pour chaque sous-domaine (app, git, media) vers l'IP du VPS. La validation Let's Encrypt echouera tant que la resolution DNS n'est pas effective, alors verifiez-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.
Rediger la configuration
Avec Caddy, un bloc suffit : app.votredomaine.ma { reverse_proxy 127.0.0.1:3000 } et le HTTPS est automatique. Avec Nginx, ecrivez un server par sous-domaine avec proxy_pass et les en-tetes X-Forwarded-*, puis obtenez le certificat via Certbot.
Lancer et recharger sans coupure
Demarrez le service (docker compose up -d ou systemd). Apres chaque modification, validez la config (nginx -t ou caddy validate) puis rechargez a chaud (nginx -s reload / caddy reload) pour ne jamais interrompre le trafic.
Durcir la securite
Activez HSTS, masquez la version du serveur, forcez TLS 1.2+ et ajoutez un rate limiting basique. Centralisez ces en-tetes au niveau du proxy pour qu'ils s'appliquent a tous les services en aval.
Mettre en place les logs et le monitoring
Activez les logs d'acces et d'erreur, et surveillez les codes 502/504 qui revelent un conteneur en aval injoignable. Un frontal sain mais des erreurs 502 pointent toujours vers le service proxifie, pas vers le proxy.
| Critere | Caddy | Nginx |
|---|---|---|
| HTTPS / certificats | Automatique, zero config | Manuel ou via Certbot |
| Syntaxe de configuration | Caddyfile, tres concis | Plus verbeuse, tres expressive |
| Courbe d'apprentissage | Faible | Moderee a elevee |
| Controle fin (cache, rewrite, LB) | Bon, parfois via plugins | Tres complet et eprouve |
| Performances statiques | Excellentes | Excellentes, reference |
| HTTP/3 / QUIC | Active par defaut | Supporte selon version |
| Ecosysteme / documentation | Recent, en croissance | Vaste, tres mature |
| Ideal pour | Mise en HTTPS rapide, multi-sous-domaines | Reglages avances, fort trafic |
Si vous hesitez, sachez qu'ils ne s'excluent pas : un pattern courant place Caddy en tout premier frontal pour gerer automatiquement le TLS de tous vos sous-domaines, puis laisse Nginx en aval pour le cache fin et les regles de reecriture d'un service precis. Vous combinez ainsi l'automatisme des certificats et la maitrise du tuning, sans choisir un camp definitif.
