[{"data":1,"prerenderedAt":212},["ShallowReactive",2],{"seo-verification":3,"blog-caddy-vs-nginx-ma-fr":6,"promo-bar-likely":211},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-caddy-vs-nginx-ma-fr",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":27,"featuredImage":29,"bgImage":30,"posterImage":31,"relatedSolution":32,"intro":35,"sections":36,"ctaTitle":149,"ctaBody":150,"ctaButton":151,"ctaUrl":152,"relatedPosts":153},103,"caddy-vs-nginx",{"fr":10,"en":12,"ar":13,"es":14},"caddy-vs-nginx-which-web-server-reverse-proxy-for-your-vps","caddy-مقابل-nginx-أي-خادم-ويب-ووكيل-عكسي-لـ-vps","caddy-vs-nginx-servidor-web-reverse-proxy-vps","Caddy vs Nginx : quel serveur web\u002Freverse proxy pour votre VPS ?","Caddy vs Nginx sur VPS : comparaison complète — HTTPS automatique, configuration, HTTP\u002F3, rate limiting, dépannage et quand choisir Traefik.",9,1,false,"2026-03-09T00:00:00+00:00","2026-11-08T01:13:13+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},5,"Comparatif","comparatif","bg-info\u002F10 text-info",[28],{"id":23,"name":24,"slug":25,"color":26,"icon":25},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fcaddy-vs-nginx-poster.svg",{"categorySlug":33,"appSlug":34},"deploiement","caddy","Sur un VPS qui sert du trafic HTTP, le reverse proxy n'est pas un détail de configuration : c'est la pièce qui gère TLS, distribue les requêtes vers vos conteneurs et décide des en-têtes de sécurité visibles par chaque visiteur. Caddy automatise intégralement l'émission et le renouvellement des certificats Let's Encrypt ; Nginx offre la finesse de réglage la plus éprouvée du marché. Ce guide compare les deux en profondeur — configuration avancée, dépannage, HTTP\u002F3 — et précise quand un troisième choix, Traefik, s'impose.",[37,41,52,55,83,86,89,137,139,142,146],{"type":38,"title":39,"body":40},"h2","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.",{"type":42,"title":43,"items":44},"ul","Ce qu'un bon frontal apporte à votre VPS",[45,46,47,48,49,50,51],"Terminaison TLS centralisée pour tous vos sous-domaines","Reverse proxy unique vers plusieurs conteneurs Docker","Service de fichiers statiques rapide et compression (gzip\u002Fbrotli)","En-têtes de sécurité (HSTS, CSP, X-Content-Type-Options) appliqués au même endroit","Avec Caddy : certificats Let's Encrypt obtenus et renouvelés automatiquement","Avec Nginx : cache, rate limiting et load balancing finement réglés","HTTP\u002F3 et QUIC pour réduire la latence sur connexions dégradées",{"type":38,"title":53,"body":54},"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\u002FAAAA), 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.",{"type":56,"title":57,"steps":58},"steps","Mettre en place Caddy (ou Nginx) en reverse proxy",[59,62,65,68,71,74,77,80],{"title":60,"body":61},"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 avec `dig app.votredomaine.com` ou un outil en ligne.",{"title":63,"body":64},"Ouvrir les ports 80 et 443","Autorisez uniquement 80 et 443 sur le pare-feu (`ufw allow 80\u002Ftcp && ufw allow 443\u002Ftcp`). Le port 80 reste indispensable pour le challenge HTTP de Let's Encrypt et pour rediriger automatiquement le trafic vers HTTPS.",{"title":66,"body":67},"Rédiger la configuration de base","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 : `certbot --nginx -d app.votredomaine.com`.",{"title":69,"body":70},"Configurer plusieurs sous-domaines","Avec Caddy, listez chaque bloc dans le même `Caddyfile` : `git.votredomaine.com { reverse_proxy 127.0.0.1:3001 }`. Avec Nginx, créez un fichier par sous-domaine dans `\u002Fetc\u002Fnginx\u002Fconf.d\u002F` ou `\u002Fetc\u002Fnginx\u002Fsites-available\u002F`, puis activez-le avec `ln -s`. Les deux approches permettent de gérer des dizaines de services sans se répéter.",{"title":72,"body":73},"Activer la compression","Caddy ne compresse pas par défaut : ajoutez `encode zstd gzip` dans le bloc du site (brotli n'est pas dans la version standard et exige un module tiers compilé via xcaddy). Sous Nginx, ajoutez dans `nginx.conf` : `gzip on; gzip_types text\u002Fplain text\u002Fcss application\u002Fjson application\u002Fjavascript; gzip_min_length 256;`. La compression réduit fortement le poids des réponses texte (HTML, CSS, JSON, JavaScript).",{"title":75,"body":76},"Lancer et recharger sans coupure","Démarrez le service (`docker compose up -d` ou `systemctl start caddy`). Après chaque modification, validez la config (`nginx -t` ou `caddy validate`) puis rechargez à chaud (`nginx -s reload` \u002F `caddy reload`) pour ne jamais interrompre le trafic.",{"title":78,"body":79},"Vérifier les certificats","Avec Caddy, exécutez `caddy validate --config \u002Fetc\u002Fcaddy\u002FCaddyfile` pour détecter les erreurs avant rechargement, et consultez les logs (`journalctl -u caddy -f`) pour confirmer l'émission du certificat. Avec Nginx + Certbot, `certbot certificates` liste les dates d'expiration et `certbot renew --dry-run` simule le renouvellement.",{"title":81,"body":82},"Durcir la sécurité et mettre en place les logs","Activez HSTS, masquez la version du serveur (`server_tokens off` sous Nginx, automatique sous Caddy), forcez TLS 1.2+ et ajoutez un rate limiting basique. Activez les logs d'accès et d'erreur, et surveillez les codes 502\u002F504 qui révèlent un conteneur en aval injoignable.",{"type":84,"body":85},"p","Une fois le proxy opérationnel et les certificats émis, deux étapes complémentaires renforcent la sécurité et les performances : la configuration avancée des en-têtes et du rate limiting, et la mise en place du monitoring. L'ordre importe : validez d'abord que le routage de base fonctionne (`curl -I https:\u002F\u002Fapp.votredomaine.com`) avant d'empiler les couches de configuration.",{"type":38,"title":87,"body":88},"Configuration avancée : sécurité, compression et HTTP\u002F3","Une fois la base en place, trois axes améliorent concrètement la posture de votre reverse proxy.\n\n**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.\n\n**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\u002Fm;` 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.\n\n**HTTP\u002F3 et QUIC.** Caddy active HTTP\u002F3 par défaut dès que le port UDP 443 est ouvert. Nginx supporte QUIC et HTTP\u002F3 depuis la version 1.25.0 (paramètre `quic` dans le bloc `listen`, module `ngx_http_v3_module` inclus dans les paquets Linux de nginx.org) ; vérifiez la version installée et ses modules avec `nginx -V` avant d'activer la directive. HTTP\u002F3 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.",{"type":90,"title":91,"headers":92,"rows":96},"comparison","Caddy vs Nginx — tableau comparatif",[93,94,95],"Critère","Caddy","Nginx",[97,101,105,109,113,117,121,125,129,133],[98,99,100],"HTTPS \u002F certificats","Automatique, zéro config","Manuel ou via Certbot",[102,103,104],"Syntaxe de configuration","Caddyfile, très concis","Plus verbeuse, très expressive",[106,107,108],"Courbe d'apprentissage","Faible","Modérée à élevée",[110,111,112],"Contrôle fin (cache, rewrite, LB)","Bon, parfois via plugins","Très complet et éprouvé",[114,115,116],"HTTP\u002F3 \u002F QUIC","Activé par défaut","Supporté depuis 1.25.0",[118,119,120],"Rate limiting natif","Via module xcaddy","Intégré (`limit_req`)",[122,123,124],"Modules dynamiques","Compilation via xcaddy","Modules dynamiques (.so)",[126,127,128],"Empreinte RAM au repos","Faible (binaire Go unique)","Faible (workers légers)",[130,131,132],"Format des logs","JSON structuré par défaut","Texte, configurable",[134,135,136],"Idéal pour","Mise en HTTPS rapide, multi-sous-domaines","Réglages avancés, fort trafic",{"type":84,"body":138},"Les étapes de déploiement couvrent la configuration idéale. En pratique, plusieurs types d'erreurs reviennent régulièrement : un certificat bloqué par un réseau intermédiaire, un service en aval qui ne répond pas encore, ou un conteneur Docker inaccessible depuis le proxy parce que les deux sont sur des réseaux distincts. Le tableau de bord le plus utile dans ces situations est le journal du proxy (`journalctl -u caddy -f` ou `tail -f \u002Fvar\u002Flog\u002Fnginx\u002Ferror.log`), combiné à `curl` en local pour isoler le problème.",{"type":38,"title":140,"body":141},"Dépannage : les erreurs les plus fréquentes","Même un proxy bien configuré produit des erreurs au démarrage ou sous charge. Voici les cinq cas qui reviennent le plus souvent.\n\n**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:\u002F\u002F` interne.\n\n**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:\u002F\u002F127.0.0.1:\u003Cport>` 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`.\n\n**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`.\n\n**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 `LimitNOFILE=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`.\n\n**Caddy — renouvellement silencieusement bloqué.** Caddy renouvelle en tâche de fond, mais si le port 80 ou le port TCP 443 est fermé par le pare-feu, les challenges HTTP-01 et TLS-ALPN-01 échouent et seuls les logs le signalent. Surveillez `journalctl -u caddy -f` autour des dates de renouvellement (quand il reste environ un tiers de la validité, soit vers 60 jours pour un certificat de 90 jours) et testez le challenge avec `caddy run --config \u002Fetc\u002Fcaddy\u002FCaddyfile --watch` en avant-plan pour voir les erreurs en temps réel.",{"type":143,"title":144,"body":145},"tip","Caddy, Nginx ou Traefik : le troisième choix","Pour une infrastructure à **nombreux microservices Docker** avec découverte automatique des conteneurs, Traefik s'impose comme troisième option : il lit les labels Docker (`traefik.http.routers.monapp.rule=Host(\"app.votredomaine.com\")`) et configure les routes à la volée sans recharger manuellement. L'inconvénient est sa configuration plus complexe et sa documentation plus dense. Caddy et Nginx restent les choix naturels pour un VPS de taille raisonnable (1 à 20 services) ; Traefik prend le relais au-delà, notamment dans un contexte Kubernetes ou Docker Swarm. Pour une comparaison complète des trois, consultez l'article \u003Ca href=\"\u002Fblog\u002Fchoisir-reverse-proxy-vps-caddy-traefik-nginx\">choisir son reverse proxy VPS : Caddy, Traefik ou Nginx\u003C\u002Fa>.",{"type":143,"title":147,"body":148},"Combiner les deux plutôt que choisir","Si vous hésitez encore, sachez que Caddy et Nginx 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.","Un frontal HTTPS prêt en quelques lignes","Le VPS Cloud ServOrbit avec template Docker vous permet de déployer Caddy ou Nginx en reverse proxy, avec SSL automatique pour tous vos sous-domaines et services.","Configurer mon reverse proxy","\u002Fvps-cloud",[154,173,191],{"id":155,"slug":156,"slugs":157,"title":161,"excerpt":162,"readTime":163,"views":164,"isPinned":19,"noindex":19,"publishedAt":165,"updatedAt":166,"category":167,"categories":168,"featuredImage":29,"bgImage":30,"posterImage":170,"relatedSolution":171},4,"coolify-vs-dokploy",{"fr":156,"en":158,"ar":159,"es":160},"coolify-vs-dokploy-which-tool-to-deploy-on-a-vps","coolify-مقابل-dokploy-أي-أداة-للنشر-على-vps","coolify-vs-dokploy-que-herramienta-elegir-para-su-vps","Coolify vs Dokploy : quel outil pour déployer sur un VPS ?","Coolify ou Dokploy pour votre VPS ? Comparatif sur la RAM au repos, la licence, les templates et le support multi-nœud pour choisir définitivement.",7,3,"2026-06-07T00:00:00+00:00","2026-09-18T02:05:20+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[169],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fcoolify-vs-dokploy-poster.svg",{"categorySlug":33,"appSlug":172},"coolify",{"id":174,"slug":175,"slugs":176,"title":180,"excerpt":181,"readTime":17,"views":164,"isPinned":19,"noindex":19,"publishedAt":182,"updatedAt":183,"category":184,"categories":185,"featuredImage":29,"bgImage":30,"posterImage":187,"relatedSolution":188},93,"n8n-vs-node-red",{"fr":175,"en":177,"ar":178,"es":179},"n8n-vs-node-red-which-self-hosted-automation-tool-to-choose","n8n-مقابل-node-red-أي-أداة-أتمتة-مستضافة-ذاتيا-تختار","n8n-vs-node-red-que-automatizacion-self-hosted-elegir","n8n vs Node-RED : quelle automatisation self-hosted choisir ?","n8n ou Node-RED pour automatiser vos workflows sur VPS ? Comparatif technique complet : licence, ressources, cas d'usage IoT vs SaaS, migration et déploiement Docker.","2026-03-19T00:00:00+00:00","2026-11-08T01:13:15+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[186],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fn8n-vs-node-red-poster.svg",{"categorySlug":189,"appSlug":190},"automatisation","n8n",{"id":192,"slug":193,"slugs":194,"title":198,"excerpt":199,"readTime":200,"views":201,"isPinned":19,"noindex":19,"publishedAt":202,"updatedAt":203,"category":204,"categories":205,"featuredImage":29,"bgImage":30,"posterImage":207,"relatedSolution":208},94,"supabase-vs-appwrite",{"fr":193,"en":195,"ar":196,"es":197},"supabase-vs-appwrite-which-self-hosted-backend-for-your-vps","supabase-مقابل-appwrite-أي-خلفية-مستضافة-ذاتيا-لـ-vps","supabase-vs-appwrite-que-backend-self-hosted-para-vps","Supabase vs Appwrite : quel BaaS open source pour votre VPS ?","Comparatif complet Supabase vs Appwrite : déploiement Docker, RAM requise, auth, fonctions serverless, temps réel et guide de choix pour votre VPS.",14,0,"2026-03-18T00:00:00+00:00","2026-11-08T01:13:16+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":25},[206],{"id":23,"name":24,"slug":25,"color":26,"icon":25},"\u002Fblog\u002Fcovers\u002Fsupabase-vs-appwrite-poster.svg",{"categorySlug":209,"appSlug":210},"bases-de-donnees","supabase",true,1794270675167]