12 oct. 2025·8 min
Nginx vs Caddy : quel serveur web choisir en 2025 ?
Comparez Nginx et Caddy pour reverse proxy et hébergement web : installation, HTTPS, configurations, performance, plugins et quand choisir l’un ou l’autre.
Comparez Nginx et Caddy pour reverse proxy et hébergement web : installation, HTTPS, configurations, performance, plugins et quand choisir l’un ou l’autre.
Nginx et Caddy sont deux serveurs web que vous exécutez sur votre propre machine (VM, serveur bare‑metal ou conteneur) pour mettre un site ou une application en ligne.
À un niveau élevé, ils sont couramment utilisés pour :
La plupart des comparaisons se réduisent à un compromis : à quelle vitesse vous obtenez une configuration sûre et fonctionnelle versus combien de contrôle vous voulez sur chaque détail.
Caddy est souvent choisi quand vous voulez des valeurs par défaut modernes et une mise en route simple — surtout pour le HTTPS — sans passer beaucoup de temps sur la configuration.
Nginx est souvent choisi quand vous voulez un serveur mature et très répandu, avec un style de configuration qui peut être extrêmement flexible une fois maîtrisé.
Ce guide s’adresse à ceux qui exécutent tout, d’un petit site personnel à des apps en production — développeurs, fondateurs et équipes orientées ops qui veulent une décision pratique, pas de la théorie.
Nous nous concentrerons sur des préoccupations réelles de déploiement : ergonomie de configuration, HTTPS et certificats, comportement de reverse proxy, bases de performance, valeurs par défaut de sécurité et opérations.
Nous ne ferons pas de promesses spécifiques à un fournisseur ni de benchmarks dépendant fortement d’un cloud, CDN ou environnement d’hébergement particulier. À la place, vous obtiendrez des critères décisionnels applicables à votre propre configuration.
Nginx est largement disponible partout (repos Linux, conteneurs, hôtes managés). Après l’installation, vous obtenez typiquement une page “Welcome to nginx!” servie depuis un répertoire propre à la distribution. Mettre votre premier vrai site en ligne implique généralement de créer un fichier de bloc serveur, l’activer, tester la config, puis recharger.
Caddy est aussi facile à installer (paquets, binaire unique, Docker), mais l’expérience de premier lancement est plus « batteries incluses ». Un Caddyfile minimal peut vous permettre de servir un site ou de faire du reverse proxy en quelques minutes, et les valeurs par défaut sont orientées vers un HTTPS moderne et sécurisé.
La configuration Nginx est puissante, mais les débutants butent souvent sur :
includelocation)nginx -t avant un reloadLa Caddyfile se lit plus comme une expression d’intention (« proxy ceci vers cela »), ce qui réduit les tirs amis pour les configurations courantes. Le compromis est que, lorsque vous avez besoin d’un comportement très spécifique, vous devrez peut‑être apprendre la config JSON sous‑jacente de Caddy ou ses concepts de modules.
Avec Caddy, le HTTPS pour un domaine public se fait souvent en une ligne : définissez l’adresse du site, pointez le DNS, démarrez Caddy — les certificats sont demandés et renouvelés automatiquement.
Avec Nginx, HTTPS nécessite généralement de choisir une méthode de certificat (par ex. Certbot), de relier les chemins de fichiers et de configurer les renouvellements. Ce n’est pas difficile, mais il y a plus d’étapes et plus d’endroits où se tromper.
Pour le développement local, Caddy peut créer et faire confiance aux certificats locaux avec caddy trust, ce qui rend https://localhost plus proche de la production.
Avec Nginx, l’HTTPS local est typiquement manuel (générer un certificat auto‑signé, le configurer, puis accepter les avertissements du navigateur ou installer une CA locale). Beaucoup d’équipes sautent l’HTTPS local, ce qui peut cacher des problèmes de cookie, redirection et contenu mixte jusqu’à plus tard.
C’est dans la configuration que Nginx et Caddy se distinguent le plus. Nginx favorise une structure explicite et imbriquée et un grand vocabulaire de directives. Caddy favorise une syntaxe « intention‑first » plus petite et lisible, facile à survoler — surtout quand vous gérez quelques sites.
La config Nginx est construite autour de contextes. La plupart des apps web ont un ou plusieurs blocs server {} (hôtes virtuels), et à l’intérieur, plusieurs blocs location {} qui correspondent à des chemins.
Cette structure est puissante, mais la lisibilité peut souffrir quand les règles s’accumulent (locations regex, multiples if, longues listes d’en‑têtes). L’outil principal de maintenabilité est include : découper les grosses configs en fichiers plus petits et garder une organisation cohérente.
Plusieurs sites sur un même serveur signifie généralement plusieurs server {} (souvent un fichier par site), plus des snippets partagés :
# /etc/nginx/conf.d/example.conf
server {
listen 80;
server_name example.com www.example.com;
include /etc/nginx/snippets/security-headers.conf;
location / {
proxy_pass http://app_upstream;
include /etc/nginx/snippets/proxy.conf;
}
}
Une règle pratique : traitez nginx.conf comme le « câblage racine » et conservez les spécificités app/site dans /etc/nginx/conf.d/ (ou sites-available/sites-enabled, selon la distro).
La Caddyfile de Caddy ressemble davantage à une checklist de ce que vous voulez faire. Vous déclarez un bloc site (généralement le domaine), puis ajoutez des directives comme reverse_proxy, file_server ou encode.
Pour beaucoup d’équipes, le principal avantage est que le « chemin heureux » reste court et lisible — même quand vous ajoutez des fonctionnalités communes :
example.com {
reverse_proxy localhost:3000
encode zstd gzip
header {
Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
}
}
Plusieurs sites sur un même serveur se résument souvent à plusieurs blocs site dans le même fichier (ou des fichiers importés), ce qui est facile à parcourir lors de revues.
import.location le plus malin est souvent le plus dur à débugger après coup. Caddy encourage des patterns plus simples ; si vous les dépassez, documentez votre intention en commentaires.Si votre priorité est la clarté avec un minimum de cérémonial, la Caddyfile est difficile à battre. Si vous avez besoin d’un contrôle fin et acceptez un style plus structuré et verbeux, Nginx reste un bon choix.
Le différentiel le plus important au quotidien entre Nginx et Caddy tient au HTTPS. Les deux peuvent offrir un excellent TLS ; la différence est la quantité de travail à faire — et le nombre d’endroits où la dérive de configuration peut apparaître.
La fonctionnalité phare de Caddy est l’HTTPS automatique. Si Caddy peut déterminer le nom d’hôte et qu’il est publiquement joignable, il va généralement :
En pratique, vous configurez un site, démarrez Caddy, et le HTTPS « se produit » pour des domaines publics courants. Caddy gère aussi automatiquement la redirection HTTP → HTTPS dans la plupart des setups, ce qui élimine une source fréquente d’erreurs.
Nginx attend que vous câbliez TLS vous‑même. Vous devrez :
ssl_certificate et ssl_certificate_keyC’est très flexible, mais il est plus facile d’oublier une étape — surtout autour de l’automatisation et des reloads.
Un piège classique est la mauvaise gestion des redirections :
Caddy réduit ces erreurs grâce à des valeurs par défaut sensées. Avec Nginx, il faut être explicite et vérifier le comportement de bout en bout.
Pour des certificats personnalisés (commerciaux, wildcard, CA privée), les deux serveurs fonctionnent bien.
La plupart des équipes ne choisissent pas un serveur web pour un « Hello World ». Elles le choisissent pour les tâches quotidiennes du proxy : restituer correctement les informations client, supporter les connexions longues et garder les apps stables sous trafic imparfait.
Nginx et Caddy peuvent tous deux se placer devant votre app et transmettre correctement les requêtes, mais les détails comptent.
Un bon setup de reverse proxy assure :
Host, X-Forwarded-Proto et X-Forwarded-For, pour que l’app construise des redirections et des logs appropriés.Upgrade/Connection; avec Caddy, c’est généralement automatique lors d’un proxy.Si vous avez plusieurs instances d’app, les deux serveurs peuvent répartir le trafic. Nginx propose depuis longtemps des patterns pour le balancing pondéré et un contrôle plus granulaire, tandis que le load balancing de Caddy est simple et adapté aux cas courants.
Les health checks font toute la différence opérationnelle : vous voulez que les instances malsaines soient retirées rapidement, et des timeouts bien réglés pour que les utilisateurs n’attendent pas des backends morts.
Les apps réelles rencontrent des cas limites : clients lents, appels API longs, server‑sent events et gros uploads.
Portez attention à :
Aucun des deux n’est un WAF complet par défaut, mais les deux aident avec des garde‑fous pratiques : limites de requêtes par IP, plafonds de connexion et contrôles de sanity sur les en‑têtes. Si vous comparez posture de sécurité, associez cela à votre checklist globale dans /blog/nginx-vs-caddy-security.
La performance n’est pas seulement des « requêtes par seconde ». C’est aussi la rapidité perçue par l’utilisateur, l’efficacité pour servir les assets statiques, et à quel point votre pile protocolaire est moderne par défaut.
Pour l’hébergement statique (CSS, JS, images), Nginx et Caddy peuvent être très rapides si bien configurés.
Nginx donne un contrôle granulaire sur les headers de cache (par ex. cache longue durée pour les assets hachés et cache plus court pour le HTML). Caddy peut faire la même chose, mais vous utiliserez peut‑être des snippets ou des matchers pour exprimer la même intention.
La compression est un compromis :
Pour les petits sites, activer Brotli fait rarement de mal et peut accélérer la page. Pour les sites à fort trafic, mesurez la charge CPU et envisagez des assets pré‑compressés ou déporter la compression vers le CDN/edge.
HTTP/2 est la baseline pour les navigateurs modernes et améliore le chargement de nombreux petits assets sur une même connexion. Les deux serveurs le supportent.
HTTP/3 (sur QUIC) peut améliorer les performances sur réseaux mobiles instables en réduisant l’impact des pertes de paquets et des handshakes. Caddy facilite l’essai d’HTTP/3, tandis que le support Nginx varie selon la build et peut nécessiter des paquets spécifiques.
Pour une single‑page app, il faut souvent « essayer le fichier, sinon servir /index.html ». Les deux savent le faire proprement, mais vérifiez que les routes API ne tombent pas par erreur sur le fallback SPA et masquent de vrais 404.
Les deux peuvent être durcis correctement, mais leurs valeurs par défaut diffèrent.
Caddy est « secure‑by‑default » pour de nombreux déploiements courants : TLS moderne activé automatiquement, renouvellement de certificats, et encouragement au HTTPS‑only. Nginx est flexible et largement déployé, mais il faut généralement faire des choix explicites pour TLS, les en‑têtes et le contrôle d’accès.
Protégez les outils internes (métriques, panels admin, previews) par authentification et/ou allowlists IP.
Exemple (Caddy) :
admin.example.com {
basicauth {
admin $2a$10$..............................................
}
reverse_proxy 127.0.0.1:9000
}
Pour Nginx, appliquez auth_basic ou allow/deny aux blocs location exposant des routes sensibles.
Commencez par des en‑têtes qui réduisent les risques courants :
Strict-Transport-Security: max-age=31536000; includeSubDomainsX-Frame-Options: DENY (ou SAMEORIGIN si nécessaire)X-Content-Type-Options: nosniffLe durcissement, ce n’est pas une « config parfaite » unique, mais l’application cohérente de ces contrôles sur chaque application et endpoint.
L’expérience long terme est souvent déterminée moins par le cœur et plus par l’écosystème : modules, exemples réutilisables et la facilité d’extension quand les besoins évoluent.
Nginx a un écosystème profond bâti sur de nombreuses années. Il existe de nombreux modules officiels et tiers, et une énorme quantité d’exemples communautaires (blogs, gists GitHub, docs des vendeurs). C’est un avantage réel quand vous avez besoin d’une capacité spécifique — cache avancé, load balancing pointu ou intégrations pour des apps populaires — car quelqu’un a souvent déjà résolu le problème.
Le compromis : tous les exemples trouvés ne sont pas forcément à jour ni sécurisés. Vérifiez toujours avec la doc officielle et les recommandations TLS modernes.
Le cœur de Caddy couvre beaucoup (notamment HTTPS et reverse proxy), mais vous aurez recours aux extensions quand il vous faudra des méthodes d’auth non standards, une découverte d’upstream particulière ou un traitement de requête personnalisé.
Comment évaluer une extension :
Dépendre de plugins rares augmente le risque lors des upgrades : une rupture d’API ou un abandon peut vous bloquer sur une ancienne version. Pour rester flexible, préférez les fonctionnalités du cœur, rendez la config portable (documentez l’intention, pas seulement la syntaxe) et isolez la « sauce spéciale » derrière des interfaces bien définies (par ex. externaliser l’auth dans un service dédié). En cas de doute, prototypez les deux serveurs avec votre app réelle avant de vous engager.
Faire tourner un serveur web n’est pas « configure et oublier ». Le travail du jour deux — logs, métriques et changements sûrs — est où Nginx et Caddy se distinguent.
Nginx écrit typiquement des logs access et error séparés, avec des formats hautement personnalisables :
Vous pouvez tuner log_format pour coller à votre workflow incident (par ex. ajouter des timings upstream), et le dépannage se fait souvent en corrélant un pic sur access log avec des messages dans error log.
Caddy produit par défaut des logs structurés (souvent JSON), ce qui facilite leur ingestion par des outils d’agrégation car les champs sont constants et lisibles par machine. Si vous préférez du texte, vous pouvez le configurer, mais la plupart des équipes exploitent les logs structurés pour filtrer plus vite.
Nginx utilise souvent des endpoints status intégrés (ou des fonctionnalités commerciales selon l’édition) plus des exporters/agents pour Prometheus et des dashboards.
Caddy expose des signaux opérationnels via son API admin et s’intègre aux stacks d’observabilité courantes ; les équipes ajoutent souvent un module/exporter pour du scraping Prometheus si besoin.
Quel que soit le serveur, visez un workflow cohérent : validez, puis rechargez.
Nginx a un processus bien connu :
nginx -tnginx -s reload (ou systemctl reload nginx)Caddy supporte des mises à jour sûres via ses mécanismes de reload et des workflows d’adaptation/validation (surtout si vous générez du JSON). L’important est la pratique : valider les entrées et rendre les changements réversibles.
Pour les deux, traitez la configuration comme du code :
Les setups de production convergent souvent vers quelques patterns, que vous choisissiez Nginx ou Caddy. Les plus grandes différences sont les valeurs par défaut (HTTPS automatique de Caddy) et votre préférence pour une configuration explicite versus « lancez‑le et ça marche ».
Sur VM ou bare‑metal, les deux sont généralement gérés par systemd. L’essentiel est le moindre privilège : exécuter le serveur sous un utilisateur dédié non privilégié, garder les fichiers de config détenus par root et restreindre l’écriture à ce qui est strictement nécessaire.
Pour Nginx, cela signifie souvent un processus master root qui bind les ports 80/443 et des workers sous www-data (ou équivalent). Pour Caddy, vous aurez souvent un compte service unique avec les capacités minimales pour binder les ports bas. Dans les deux cas, traitez les clés privées TLS et les fichiers d’environnement comme des secrets avec permissions strictes.
Dans les conteneurs, le « service » est le conteneur lui‑même. Vous allez typiquement :
Pensez aussi au réseautage : le reverse proxy doit être sur le même réseau Docker que vos apps, en utilisant les noms de service plutôt que des IPs figées.
Conservez des configs séparées (ou des variables templatisées) pour dev/stage/prod afin de ne pas « éditer en place ». Pour des déploiements sans downtime, les patterns courants sont :
Les deux serveurs supportent les reloads sûrs ; combinez‑les à des health checks pour n’envoyer du trafic qu’aux backends sains.
Le choix entre Nginx et Caddy dépend moins de « lequel est meilleur » que de ce que vous voulez délivrer — et qui l’exploitera.
Si vous voulez un blog, portfolio ou docs en ligne rapidement, Caddy est généralement la victoire la plus simple. Un Caddyfile minimal peut servir un répertoire et activer automatiquement HTTPS pour un domaine réel avec très peu de cérémonie.
Les deux conviennent ; le facteur décisif est souvent qui doit le maintenir.
Pour un déploiement typique « frontend + API », les deux peuvent terminer TLS et faire du proxy vers des serveurs d’app.
C’est là que les compromis deviennent plus visibles :
Si vous hésitez, par défaut Caddy pour la vitesse et la simplicité, Nginx pour la prévisibilité maximale en environnements établis.
Si votre défi principal est de faire sortir un produit (pas seulement choisir un proxy), resserrez la boucle entre développement et déploiement. Par exemple, Koder.ai vous permet de créer des apps web, backend et mobiles depuis une interface chat (React côté web, Go + PostgreSQL côté backend, Flutter pour le mobile), puis d’exporter le code source et de déployer derrière Caddy ou Nginx. En pratique, cela vous permet d’itérer rapidement et de garder une couche edge conventionnelle et auditable en production.
Migrer entre Nginx et Caddy consiste souvent moins à tout réécrire qu’à traduire quelques comportements clés : routage, en‑têtes, TLS et comment votre app voit les détails client.
Choisissez Caddy si vous voulez des configs plus simples, l’HTTPS automatique (et ses renouvellements), et moins d’éléments à gérer au quotidien. C’est un bon choix pour les petites équipes, de nombreux petits sites et des projets où vous préférez exprimer l’intention ("proxy ceci", "servir cela") plutôt que de maintenir un grand ensemble de directives.
Restez sur Nginx si vous dépendez d’un setup fortement personnalisé (cache avancé, réécritures complexes, modules sur mesure), si vous êtes standardisé sur Nginx à l’échelle d’une flotte, ou si vous avez un comportement affiné au fil des ans et largement documenté par votre équipe.
Commencez par un inventaire : listez tous les blocs serveur/sites, upstreams, points de terminaison TLS, redirections, en‑têtes personnalisés, limites de débit et les locations spéciales (ex. /api, /assets). Puis :
Surveillez les différences d’en‑têtes (Host, X-Forwarded-For, X-Forwarded-Proto), le proxying WebSocket, la sémantique des redirections (slashes finaux et 301 vs 302), et le comportement de gestion de chemin (matching location de Nginx vs matchers de Caddy). Confirmez aussi que votre app fait confiance correctement aux en‑têtes du proxy pour éviter une mauvaise génération d’URL/schéma.
Choisir entre Nginx et Caddy dépend surtout de ce que vous valorisez au jour 1 versus ce que vous voulez contrôler sur le long terme. Les deux servent bien des sites et proxy des apps ; le « meilleur » choix est généralement celui qui correspond aux compétences et au confort opérationnel de votre équipe.
Utilisez cette checklist rapide :
Caddy tend à offrir : configuration plus simple, flux HTTPS automatiques et une expérience conviviale dès le premier jour.
Nginx tend à offrir : une longue présence en production, une large base de connaissances communautaire et de nombreux réglages pour des setups spécialisés.
Si vous hésitez encore, choisissez celui que vous pourrez exploiter sereinement à 2h du matin — et réévaluez une fois que vos besoins (trafic, équipes, conformité) seront plus clairs.
Choisissez Caddy si vous voulez un HTTPS automatique, une configuration courte et lisible, et un délai de mise en ligne rapide pour un déploiement petit/moyen.
Choisissez Nginx si vous avez besoin d’une flexibilité maximale, si votre organisation/hébergeur utilise déjà des standards Nginx, ou si vous prévoyez d’utiliser des modèles matures pour des routages/caches/optimisations complexes.
Pour un domaine public, Caddy peut souvent le faire avec juste l’adresse du site et une directive reverse_proxy/file_server. Après avoir pointé le DNS vers votre serveur, Caddy obtient et renouvelle en général les certificats automatiquement.
Avec Nginx, prévoyez un client ACME (comme Certbot), la configuration ssl_certificate/ssl_certificate_key, et l’automatisation des renouvellements avec un reload assuré.
Les erreurs classiques avec Nginx incluent :
location (surtout les regex et règles qui se chevauchent)includeLa simplicité de la Caddyfile devient limitante quand vous avez besoin d’un comportement très spécifique. À ce stade, vous pourriez devoir :
location Nginx complexe)Si votre setup est inhabituel, prototypez tôt pour ne pas découvrir ces limites en plein migration.
Caddy propose un bon support du HTTPS local. Vous pouvez générer et faire confiance aux certificats locaux (par exemple avec caddy trust), ce qui vous permet de détecter tôt les problèmes liés à HTTPS (cookies, redirections, contenu mixte).
Avec Nginx, l’HTTPS local est généralement manuel (certificats auto-signés + avertissements navigateur ou installation d’une CA locale), donc beaucoup d’équipes l’omettent et découvrent ensuite des problèmes.
Les deux peuvent proxyfier correctement, mais vérifiez ces éléments :
Host, X-Forwarded-Proto, X-Forwarded-ForLes deux peuvent faire du load balancing, mais opérationnellement concentrez-vous sur :
Pour des recettes très granulaires ou établies, Nginx dispose souvent de modèles plus connus ; pour un proxy multi-upstream simple, Caddy se met en place rapidement.
Surveillez ces réglages quel que soit le serveur :
Avant la production, faites un test réaliste : téléversez un gros fichier, gardez une requête longue, et confirmez que les timeouts du proxy et de l’application correspondent.
Les deux peuvent être sécurisés, mais leurs valeurs par défaut diffèrent.
Basique pratique :
Pour une checklist plus complète, voir /blog/nginx-vs-caddy-security.
Utilisez un flux « valider → recharger » et traitez la config comme du code.
nginx -t puis systemctl reload nginx (ou nginx -s reload)Dans les deux cas, stockez les configs dans Git, déployez via CI/CD avec une étape de dry-run et prévoyez un rollback rapide.
nginx -t)/ mais pas tous les chemins) ou des boucles de redirection derrière un autre proxy/CDNUpgrade/Connection; Caddy le gère généralement automatiquement)Après modifications, testez les flux d’authentification et les redirections absolues pour confirmer que l’application voit le bon schéma et le bon hôte.