Caddy vs Nginx sur un VPS : la comparaison des fichiers de configuration

example.com {
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Les lignes TLS du bloc Nginx supposent que Certbot a déjà été exécuté. Pour un upstream HTTP comme celui ci-dessus, Caddy transmet l'en-tête Host entrant et définit X-Forwarded-For, X-Forwarded-Proto, et X-Forwarded-Host par défaut. Avec Nginx, vous ajoutez normalement les en-têtes de proxy explicitement lorsque l'upstream a besoin de l'hôte, du schéma et de la chaîne d'adresses client d'origine. C'est le compromis en miniature : Caddy fournit des valeurs de proxy par défaut pratiques, tandis que Nginx rend une plus grande partie de ce comportement explicite.

Service de fichiers statiques :

Caddyfile

example.com {
    root * /var/www
    file_server
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    root /var/www;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

Authentification basique, protégeant tout derrière un nom d'utilisateur et un mot de passe :

Caddyfile

example.com {
    basic_auth {
        Bob $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
    }
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    auth_basic           "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Les deux outils hachent le mot de passe hors bande. Caddy utilise caddy hash-password ; Nginx utilise htpasswd pour construire le fichier .htpasswd. La directive est basic_auth dans les versions actuelles de Caddy, d'ailleurs. C'était basicauth jusqu'à ce que la v2.8.0 la renomme, comme le note la documentation basic_auth de Caddy, et les vieux tutoriels y font encore trébucher.

Astuce de pro : Ce hash dans le Caddyfile n'est pas le mot de passe. C'est la sortie bcrypt de caddy hash-password. Exécutez la commande, collez ce qu'elle affiche. Caddy refuse les mots de passe en clair dans la configuration, ce qui est le bon comportement par défaut et une petite surprise la première fois.

Les configurations plaident d'elles-mêmes. Caddy condense le TLS, des en-têtes de proxy raisonnables et une redirection en quelques lignes ; Nginx est explicite et verbeux et vous met chaque bouton entre les mains. Si vous avez passé des années dans Nginx, la verbosité est un réflexe et le contrôle est tout l'intérêt. Sinon, le Caddyfile est une configuration que vous pouvez garder en tête. Le point pratique est simple : la configuration de Caddy est plus facile à lire d'un coup d'œil, tandis que Nginx vous offre un contrôle plus explicite.

Performance et mémoire : lire les benchmarks avec attention

Les tests publiés vont dans la même direction générale : Nginx utilise habituellement moins de mémoire et mène souvent sur le débit brut, mais l'ampleur de cet avantage dépend fortement de l'environnement.

In un test tiers sur une VM à quatre cœurs, Nginx a atteint environ 48 000 requêtes par seconde, contre environ 42 000 pour Caddy. Le même test a rapporté une latence HTTPS p99 de 2,1 ms pour Nginx et de 2,4 ms pour Caddy. Considérez cela comme les résultats d'une seule configuration plutôt que comme une marge de performance universelle.

Les plages de mémoire du tableau comparatif proviennent d'un test VPS distinct. Un autre test synthétique à 50 000 connexions simultanées a rapporté 145 MB pour Nginx et 520 MB pour Caddy, mais ce test utilisait des conditions de matériel et de charge de travail sensiblement différentes. Ses chiffres absolus ne doivent pas être comparés directement aux chiffres VPS ci-dessus.

La conclusion fiable est plus étroite : Nginx a généralement la plus petite empreinte mémoire et tend à mener sous les charges de travail à haut débit ou à forte concurrence. Pour un reverse proxy VPS ordinaire de petite à moyenne taille, les deux sont habituellement assez rapides, si bien que la simplicité opérationnelle est souvent le critère de décision le plus utile.

À retenir de cette section : choisissez en fonction de l'exploitation, sauf si votre serveur est limité en mémoire ou si vos propres tests de charge montrent que le débit du proxy est le goulot d'étranglement.

Le piège des certificats wildcard (Caddy n'est pas toujours sans configuration)

Caddy peut automatiser les certificats wildcard, mais pas avec ses challenges HTTP-01 ou TLS-ALPN-01 par défaut. Un certificat pour *.example.com nécessite une validation DNS-01, que Let's Encrypt impose pour les certificats wildcard. Cela implique un plugin de fournisseur DNS (intégré à votre binaire Caddy via xcaddy) plus un token API pour votre hôte DNS, configuré dans le bloc tls. Ce n'est pas le scénario « tapez une ligne et partez » que Caddy met en avant.

Cela piège les utilisateurs de homelab qui placent de nombreux services sous un vrai domaine qu'ils contrôlent, comme *.home.example.com, et présument que l'émission des wildcards est aussi automatique que app.example.com. Pour des noms purement internes comme *.homelab.internal, considérez cela comme relevant d'une PKI locale/interne, pas d'un wildcard public Let's Encrypt. Pour être précis : Caddy gère bien les wildcards, il ne les gère simplement pas avec les challenges par défaut, et la configuration est un cran au-dessus du cas d'un domaine unique. Nginx est logé à la même enseigne ici, puisque l'exigence DNS-01 vient de Let's Encrypt, pas du serveur.

Si vous voulez une interface graphique : Nginx Proxy Manager (une brève parenthèse)

Nginx Proxy Manager est d'une tout autre nature que les deux outils ci-dessus, et il mérite un paragraphe car son nom prête à confusion. NPM est une surcouche à interface graphique par-dessus Nginx : il gère les règles de reverse proxy et les certificats Let's Encrypt via une interface web sur le port 81. Ce n'est pas le cœur de Nginx, et il ne se configure pas de la même manière que le cœur de Nginx.

Le compromis est le classique clic contre configuration. NPM est le bouton facile jusqu'à ce que vous sortiez du chemin balisé. Sa configuration est gérée via une base de données applicative plutôt qu'un unique fichier de configuration édité à la main. La configuration Docker par défaut utilise SQLite, tandis que MySQL/MariaDB et PostgreSQL sont des options de base de données externe prises en charge. Cette différence affecte aussi la portabilité : une configuration Caddy peut souvent être déplacée en copiant un unique Caddyfile, tandis qu'un déploiement Nginx Proxy Manager nécessite que ses données applicatives et sa base de données soient préservées. NPM est un bon choix si vous préférez réellement cliquer plutôt qu'éditer et que votre configuration reste simple. C'est le mauvais choix pour un workflow d'infrastructure-as-code.

Migrer de Nginx vers Caddy (ce qui se transpose et ce qui ne se transpose pas)

Si vous êtes déjà sur Nginx et que vous pesez le changement, commencez par revoir à la baisse vos attentes en matière d'automatisation : il existe un adaptateur de configuration NGINX pour Caddy, mais il est incomplet et ne doit pas être considéré comme une voie de migration fiable en une seule fois. Une migration de Nginx vers Caddy est essentiellement une réécriture manuelle, et l'essentiel s'en trouve raccourci.

Ce qui se transpose et se simplifie, selon le guide de conversion de la communauté Caddy:

• Pour les upstreams HTTP, reverse_proxy transmet l'en-tête Host entrant et définit les en-têtes X-Forwarded-* standard par défaut, si bien que la plupart de ces proxy_set_header lignes disparaissent.
• PHP se réduit d'un bloc location avec try_files plus fastcgi_pass plus un tas de paramètres à une seule php_fastcgi directive.
• La gestion des WebSocket est automatique dans Caddy v2. Si un tutoriel vous dit d'ajouter une directive websocket distincte, c'est un vestige de Caddy v1. Ignorez-le.

Ce qui ne se transpose pas automatiquement : tout ce qui est lié à un module Nginx spécifique que Caddy n'a pas, la logique complexe de réécriture et de location que vous devrez repenser plutôt que porter, et les configurations de certificats wildcard, qui vous ramènent à la configuration du challenge DNS de la section ci-dessus. Prévoyez du temps pour les modules et les réécritures ; le reste se traduit généralement par une réduction nette du nombre de lignes.

Lequel installer ? (La décision)

Vous avez vu les configurations, les chiffres, le piège des wildcards et le coût de la migration, voici donc où cela aboutit. Installez Caddy si vous êtes un développeur solo ou une petite équipe, s'il s'agit d'un déploiement sur VPS tout neuf, si vous voulez un TLS que l'on configure et oublie, si vous faites tourner Docker avec un routage simple, ou si vous voulez simplement une configuration qui tient dans la mémoire musculaire. C'est le cas de la plupart des lecteurs de cet article.

Installez Nginx si vous avez besoin d'un contrôle fin ou d'un module spécifique de son écosystème mature, si vous tirez le maximum de performance d'un serveur limité en mémoire, si vous faites du service de fichiers statiques à forte concurrence, ou si votre équipe possède déjà une expertise Nginx approfondie et une pile de configurations qui fonctionnent. Ce sont de solides raisons, et si l'une d'elles est la vôtre, Nginx est le bon choix. Ce n'est pas un cas où l'outil le plus ancien est le mauvais outil.

Quel que soit votre choix, l'étape suivante consiste à le mettre sur la machine. Les deux Caddy et Nginx sont disponibles en déploiements en un clic dans notre marketplace, ce qui vous permet de sauter le travail d'installation et de passer directement au Caddyfile ou au bloc de serveur. Un VPS de 1 GB est un point de départ raisonnable pour un déploiement mono-site à faible trafic, mais dimensionnez le serveur pour l'application et le trafic derrière le proxy plutôt que pour le proxy seul. Si vous utilisez Caddy comme porte d'entrée de services auto-hébergés, il peut se placer devant une pile de supervision Prometheus et Grafana ou un déploiement Uptime Kuma sans nécessiter d'outillage TLS distinct.

À retenir de cette section : choisissez Caddy sauf si vous avez une raison précise qui penche pour Nginx.

Foire aux questions