Caddy vs Nginx : quel serveur web/reverse proxy pour votre 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.

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.

Une fois la base en place, trois axes améliorent concrètement la posture de votre reverse proxy.

En-têtes de sécurité. Appliquez au niveau du proxy les en-têtes que chaque service en aval oubliera : Strict-Transport-Security: max-age=31536000; includeSubDomains (HSTS), X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN et une Content-Security-Policy adaptée à votre application. Centraliser ces en-têtes au proxy garantit qu'ils couvrent tous vos sous-domaines d'un seul geste.

Rate limiting. Sous Caddy, le module rate_limit (disponible via xcaddy build) permet de borner le nombre de requêtes par IP. Sous Nginx, la directive limit_req_zone $binary_remote_addr zone=api:10m rate=30r/m; dans http {} puis limit_req zone=api burst=10 nodelay; dans le location concerné suffisent à protéger une API contre les abus sans dépendance externe.

HTTP/3 et QUIC. Caddy active HTTP/3 par défaut dès que le port UDP 443 est ouvert. Nginx supporte QUIC depuis la branche mainline (paramètre quic dans le bloc listen) ; vérifiez la version installée avec nginx -v avant d'activer la directive. HTTP/3 réduit la latence perçue sur les connexions mobiles et les réseaux à forte perte de paquets, sans rien changer au comportement des clients qui ne le supportent pas.

Même un proxy bien configuré produit des erreurs au démarrage ou sous charge. Voici les cinq cas qui reviennent le plus souvent.

Caddy — « no certificate » derrière un load-balancer. Lorsque Caddy est placé derrière un load-balancer qui termine déjà le TLS, il ne peut pas recevoir le challenge HTTP-01 de Let's Encrypt et échoue à émettre le certificat. Solution : utiliser le challenge DNS-01 via le plugin de votre registrar (ex. tls { dns cloudflare {env.CF_API_TOKEN} }), ou déléguer entièrement la gestion TLS au load-balancer et forcer Caddy en http:// interne.

Nginx — 502 Bad Gateway (upstream timeout). Un 502 persistant après démarrage indique que le service en aval n'écoute pas encore ou est planté. Vérifiez avec curl -v http://127.0.0.1:<port> depuis le serveur. Si le service démarre lentement, augmentez proxy_read_timeout et proxy_connect_timeout. Un 502 intermittent sous charge pointe vers un manque de connexions keepalive : ajoutez keepalive 32; dans le bloc upstream.

Caddy avec Docker — conteneur non joignable. Quand Caddy et le service cible tournent dans des réseaux Docker distincts, reverse_proxy 127.0.0.1:3000 ne fonctionne pas : 127.0.0.1 est l'adresse de la boucle locale du conteneur Caddy, pas de l'hôte. Solution : branchez les deux conteneurs sur le même réseau Docker bridge nommé et utilisez le nom du service comme adresse cible : reverse_proxy nom-du-service:3000.

Nginx — « too many open files » sous charge. L'erreur worker_connections are not enough ou open() failed (24: Too many open files) apparaît quand le VPS reçoit un pic de trafic. Augmentez la limite système (ulimit -n 65535 ou DefaultLimitNOFILE=65535 dans la unit systemd) et alignez worker_connections 4096; dans nginx.conf. Le nombre de connexions simultanées max est worker_processes * worker_connections.

Caddy — renouvellement silencieusement bloqué. Caddy renouvelle en tâche de fond, mais si le port UDP 443 est fermé par le pare-feu, HTTP/3 échoue et les logs peuvent masquer la vraie cause. Surveillez journalctl -u caddy -f autour des dates de renouvellement (60 jours après émission) et testez le challenge avec caddy run --config /etc/caddy/Caddyfile --watch en avant-plan pour voir les erreurs en temps réel.