Dès qu’on auto-héberge plus d’une application, la question du reverse proxy se pose. Comment exposer nextcloud.mondomaine.fr, vaultwarden.mondomaine.fr et jellyfin.mondomaine.fr sur la même machine, en HTTPS, sans ouvrir un port par service ni gérer ses certificats à la main ? Le reverse proxy reçoit toutes les requêtes sur les ports 80 et 443, regarde le nom de domaine demandé, et route chaque requête vers le bon conteneur. C’est l’aiguilleur de votre infrastructure.

En 2026, trois outils dominent ce créneau dans le monde du self-hosting, avec des philosophies radicalement différentes : Traefik, le reverse proxy cloud-native pensé pour Docker et l’automatisation ; Nginx Proxy Manager (NPM), l’interface web qui démocratise Nginx ; et Caddy, le serveur qui a fait du HTTPS automatique son argument central. Tous savent obtenir des certificats Let’s Encrypt gratuitement et router votre trafic — mais la façon d’y arriver change tout.

On les a déployés sur des homelabs réels et confrontés aux cas tordus (WebSocket, certificats wildcard, services hors Docker). Voici un comparatif tranché pour choisir l’aiguilleur qui colle à votre façon de travailler.

Tableau comparatif

Critère	Traefik	Nginx Proxy Manager	Caddy
Langage / techno	Go	Node.js + Nginx	Go
Philosophie	Cloud-native, automatique	UI sur Nginx, simplicité	HTTPS auto, config minimale
HTTPS automatique	Oui (Let’s Encrypt)	Oui (Let’s Encrypt)	Oui (par défaut, natif)
Découverte Docker	Oui (labels, cœur du produit)	Non (manuel via UI)	Via plugin (caddy-docker-proxy)
Configuration	Labels / fichiers YAML/TOML	Interface web	Caddyfile (très lisible)
Interface web	Dashboard (lecture)	Oui (gestion complète)	Non native
Certificats wildcard / DNS	Oui (nombreux providers)	Oui (providers DNS)	Oui (modules DNS)
Empreinte RAM	~50-100 Mo	~80-150 Mo	~20-40 Mo
Middlewares / auth	Riches (auth, rate limit, headers)	Limités (basic auth, ACL)	Modules + directives
Courbe d’apprentissage	Élevée	Très faible	Faible à moyenne
Licence	MIT	MIT	Apache 2.0
Idéal pour	Stacks Docker dynamiques	Débutants, gestion visuelle	Config simple et lisible

Traefik : le reverse proxy cloud-native

Traefik a été conçu dès le départ pour le monde des conteneurs. Son idée fondatrice est la découverte automatique : il se connecte au socket Docker, observe les conteneurs qui démarrent et s’arrêtent, et reconfigure son routage en temps réel grâce aux labels que vous posez sur chaque service. Vous ajoutez quelques lignes de labels à votre compose.yml, et Traefik crée la route, demande le certificat HTTPS et expose le service — sans que vous touchiez à un fichier de configuration central.

Sa force, c’est cette dynamique. Dans un environnement où les conteneurs vont et viennent, où l’on déploie de nouveaux services chaque semaine, Traefik brille : pas de rechargement manuel, pas de configuration à éditer à chaque ajout. Il gère aussi un système de middlewares très riche : authentification (basic, forward-auth vers Authelia ou Authentik), limitation de débit, manipulation d’en-têtes, redirections, listes blanches d’IP, le tout composable et réutilisable. Pour qui pense « infrastructure as code », Traefik est l’outil naturel.

Le revers, c’est une courbe d’apprentissage réputée raide. La distinction entre routers, services, middlewares et entrypoints, la coexistence de la configuration statique et dynamique, la syntaxe des labels Docker : tout cela demande un investissement initial. Pour exposer trois services une fois pour toutes, Traefik peut sembler surdimensionné. Mais dès que la stack devient vivante, il rend ce temps d’apprentissage avec intérêt.

Conseil : Traefik s’épanouit sur un serveur Docker bien rangé. Si vous montez une stack qui va grossir, choisissez un VPS avec assez de RAM et un réseau correct, comme Hetzner Cloud ou Scaleway, pour ne pas être limité quand les conteneurs s’accumulent.

Nginx Proxy Manager : Nginx pour les humains

Nginx Proxy Manager part d’un constat pragmatique : Nginx est un reverse proxy formidable, mais sa configuration en fichiers texte rebute beaucoup d’auto-hébergeurs débutants. NPM enrobe Nginx d’une interface web claire où l’on crée un « proxy host » en remplissant un formulaire : nom de domaine, adresse et port du service cible, et un clic pour activer le certificat Let’s Encrypt. En cinq minutes, sans ligne de commande, votre service est exposé en HTTPS.

C’est son immense atout : l’accessibilité. NPM est sans doute le moyen le plus rapide pour un débutant de comprendre et de mettre en place un reverse proxy. L’interface montre l’état des certificats, gère leur renouvellement automatique, propose des règles d’accès basiques (listes d’IP, authentification HTTP), des redirections et des hôtes de flux (stream) pour le TCP/UDP. Pour un homelab familial où l’on expose Jellyfin, Nextcloud et quelques services à un cercle restreint, NPM fait le travail sans douleur.

Ses limites apparaissent quand les besoins se sophistiquent. NPM ne fait pas de découverte Docker automatique : chaque service s’ajoute à la main, ce qui devient répétitif sur une stack qui bouge beaucoup. Les middlewares avancés (forward-auth, rate limiting fin, en-têtes complexes) ne sont pas natifs et demandent des configurations injectées à la main, ce qui casse un peu la promesse « tout en UI ». NPM reste excellent pour son public : ceux qui veulent du visuel et du simple.

Caddy : le HTTPS automatique par défaut

Caddy a popularisé une idée révolutionnaire pour l’époque : le HTTPS doit être automatique et activé par défaut, sans configuration. Vous écrivez le nom de domaine dans votre fichier de configuration, et Caddy obtient, installe et renouvelle le certificat tout seul, agrafe OCSP compris. Pas d’option à cocher, pas de bloc de configuration TLS à rédiger : c’est le comportement de base. Cette philosophie « sécurisé par défaut » a séduit une large communauté.

L’autre atout de Caddy, c’est la lisibilité du Caddyfile. Là où une configuration Nginx équivalente s’étale sur des dizaines de lignes, un reverse proxy Caddy tient en deux ou trois lignes : un domaine, une directive reverse_proxy pointant vers le conteneur, et c’est tout. Caddy est aussi le plus léger des trois (20 à 40 Mo de RAM), écrit en Go, sans dépendance externe, distribué en binaire unique. Il gère les modules DNS pour les certificats wildcard, le HTTP/3 et la compression.

Sa limite principale en environnement Docker dynamique : Caddy seul ne fait pas de découverte automatique des conteneurs. Il existe un excellent module communautaire, caddy-docker-proxy, qui apporte une logique de labels à la Traefik, mais il faut le compiler dans une image personnalisée. Ses middlewares natifs sont aussi moins nombreux que ceux de Traefik pour l’authentification d’entreprise, même si l’écosystème de modules comble une grande partie de l’écart. Caddy est le choix de l’équilibre : simple, léger, sûr.

Conseil : Caddy étant ultra-léger, il tourne parfaitement sur un micro-VPS. Pour un homelab modeste qui expose quelques services, un petit serveur chez OVHcloud ou Vultr suffit largement, et Caddy ne grignotera quasiment rien de votre RAM.

Cas d’usage : lequel pour vous ?

Vous débutez et voulez exposer vos services sans toucher au terminal. Nginx Proxy Manager. L’interface web, les formulaires guidés et l’activation HTTPS en un clic en font l’outil le plus accessible et le meilleur point de départ.

Vous gérez une stack Docker dynamique avec des déploiements fréquents. Traefik. La découverte automatique via labels élimine la configuration manuelle à chaque ajout de service. Plus votre infrastructure bouge, plus il prend l’avantage.

Vous voulez une configuration simple, lisible et un serveur ultra-léger. Caddy. Le Caddyfile minimaliste et le HTTPS automatique par défaut en font l’outil idéal pour exposer proprement un nombre raisonnable de services.

Vous avez besoin d’authentification avancée et de middlewares composables. Traefik. Son intégration avec Authelia/Authentik via forward-auth et ses middlewares de rate limiting en font le plus puissant pour les besoins de sécurité fins.

HTTPS et certificats : le terrain commun

Les trois outils savent obtenir des certificats Let’s Encrypt gratuitement, et c’est devenu la norme. La vraie différence se joue sur deux points.

D’abord, le mode de validation. Le challenge HTTP-01 (le plus simple) exige que le port 80 soit accessible depuis Internet. Le challenge DNS-01 permet d’obtenir des certificats wildcard (*.mondomaine.fr) et fonctionne même sans exposer le port 80, mais demande de configurer un fournisseur DNS supporté. Traefik et Caddy supportent une large gamme de fournisseurs DNS via modules ; NPM en gère un bon nombre via son interface. Vérifiez d’abord que votre registrar DNS est supporté si vous visez un wildcard.

Ensuite, l’automatisme du renouvellement. Les trois renouvellent automatiquement avant expiration. Caddy pousse le « par défaut » le plus loin (rien à configurer), Traefik et NPM demandent une configuration initiale du résolveur de certificats, puis gèrent le reste seuls.

Performances : ce qui compte vraiment

Pour un usage self-hosting, les trois sont largement assez performants : ils encaissent sans peine le trafic d’un homelab ou d’un petit service en production. Les différences de débit brut sur des benchmarks synthétiques existent, mais votre application backend ou votre bande passante sature bien avant le proxy.

Là où les écarts se voient, c’est sur l’empreinte mémoire. Caddy est le plus frugal (20 à 40 Mo), suivi de Traefik (50 à 100 Mo selon le nombre de routes), puis de NPM qui embarque Nginx plus une couche Node.js et une base de données (80 à 150 Mo). Sur un micro-VPS à 1 Go de RAM partagé, ces dizaines de mégaoctets comptent. Ne choisissez pas sur la performance brute : choisissez sur la façon de configurer.

Sécurité : les règles communes

Le reverse proxy est votre point d’entrée public : c’est lui qui reçoit tout le trafic Internet. À ce titre, quelques règles s’imposent quel que soit l’outil.

Forcez le HTTPS et la redirection depuis HTTP. Vérifiez que c’est bien actif, et activez HSTS pour interdire toute connexion en clair.
N’exposez que ce qui doit l’être. Gardez les interfaces d’administration (dashboard Traefik, UI de NPM) derrière une authentification ou un VPN.
Ajoutez une couche d’authentification devant les services sensibles. Coupler le proxy à un SSO comme Authelia ou Authentik protège vos applications même si l’une d’elles a une faille — très simple avec le forward-auth de Traefik.
Tenez l’outil à jour. Un reverse proxy exposé doit recevoir les correctifs de sécurité rapidement.

Un proxy bien configuré protège tout ce qu’il y a derrière ; mal configuré, il devient la porte d’entrée d’une compromission.

Verdict

Trois excellents outils, trois philosophies, aucun n’est universellement « le meilleur ».

Traefik est le choix de l’auto-hébergeur Docker qui veut de l’automatisation : découverte dynamique, middlewares riches, intégration SSO. Le plus puissant pour une stack vivante.
Nginx Proxy Manager est le meilleur point d’entrée pour les débutants et tous ceux qui préfèrent une interface visuelle à des fichiers de configuration. Le plus accessible, idéal pour un homelab familial.
Caddy est notre coup de cœur pour l’équilibre : HTTPS automatique par défaut, Caddyfile d’une lisibilité exemplaire, empreinte minuscule. Le plus simple à maintenir proprement.

Notre conseil : commencez par Caddy ou NPM si vous exposez quelques services et voulez du simple ; passez à Traefik dès que votre stack Docker devient dynamique et que l’automatisation devient prioritaire.

FAQ

Peut-on faire tourner deux reverse proxy sur la même machine ?

Pas sur les mêmes ports. Les ports 80 et 443 ne peuvent être détenus que par un seul processus. Si vous voulez tester un second proxy, faites-le sur d’autres ports ou dans un environnement isolé. En production, choisissez-en un seul comme point d’entrée unique, quitte à chaîner d’autres proxies internes derrière sur des ports différents.

Caddy ou Traefik pour découvrir automatiquement mes conteneurs Docker ?

Traefik fait la découverte Docker nativement, c’est son cœur de métier. Caddy en est capable via le module communautaire caddy-docker-proxy, mais il faut compiler une image Caddy personnalisée. Si la découverte automatique est votre priorité absolue, Traefik est le choix le plus direct ; si vous voulez surtout de la simplicité, Caddy avec une configuration explicite reste très agréable.

Nginx Proxy Manager peut-il gérer des certificats wildcard ?

Oui, via un challenge DNS-01 si votre fournisseur DNS est supporté dans son interface. Vous fournissez une clé d’API DNS, et NPM obtient un certificat couvrant tous vos sous-domaines. C’est un peu moins flexible que Traefik ou Caddy côté liste de fournisseurs, mais cela couvre les registrars les plus courants.

Lequel consomme le moins de ressources ?

Caddy, nettement, avec 20 à 40 Mo de RAM grâce à son binaire unique en Go. Traefik suit autour de 50 à 100 Mo. Nginx Proxy Manager est le plus lourd (80 à 150 Mo) car il combine Nginx, une couche Node.js et une base de données. Sur un micro-VPS, Caddy est le choix évident.

Faut-il connaître Nginx pour utiliser Nginx Proxy Manager ?

Non, c’est tout l’intérêt : NPM masque la configuration Nginx derrière des formulaires. Vous pouvez exposer vos services sans jamais écrire une ligne de configuration. En revanche, pour les cas avancés (en-têtes personnalisés, règles complexes), une injection de configuration Nginx manuelle est parfois nécessaire, et là, un minimum de connaissances aide.

Ces outils remplacent-ils un pare-feu ?

Non, ils sont complémentaires. Le reverse proxy gère le routage et le HTTPS au niveau applicatif (couche 7), mais ne remplace pas un pare-feu réseau qui filtre les ports. La bonne pratique consiste à n’ouvrir que les ports 80 et 443, à laisser le reverse proxy être le seul point d’entrée HTTP/HTTPS, et à protéger l’administration derrière un VPN.

Traefik vs Nginx Proxy Manager vs Caddy en 2026 : quel reverse proxy pour vos conteneurs ?