Proxy inverse sur Docker: nginx-proxy face à Traefik

Un proxy inverse Docker constitue un point d’entrée unique devant vos conteneurs et achemine chaque requête entrante vers le service approprié en fonction du hostname. Ce guide compare les deux options les plus populaires pour cette tâche, nginx-proxy et Traefik, avec un docker-compose.yml fonctionnel pour chacune, du TLS automatique via Let’s Encrypt et une matrice de décision claire.

Le sujet est volontairement limité à l’exécution d’un proxy inverse Docker devant vos propres conteneurs auto-hébergés. Il ne s’agit pas d’acheminer le trafic sortant, qui relève d’un outil totalement différent et qui est abordé dans la note de transition vers la fin.

DataImpulse est un fournisseur éthique de proxies qui propose plus de 90 millions d’adresses IP résidentielles, mobiles et de datacenter dans 195 pays. Il utilise un modèle de paiement à l’usage à partir de 1 dollar par GB avec un trafic sans date d’expiration. Il est utilisé pour le web scraping, la vérification des publicités, la surveillance des prix, les études de marché et la gestion de comptes multiples.

Quel proxy inverse sur Docker devriez-vous utiliser?

Utilisez nginx-proxy pour un ensemble réduit et stable de conteneurs web, si vous souhaitez limiter au maximum les composants à gérer, et utilisez Traefik quand les conteneurs apparaissent et disparaissent souvent et que vous voulez un routage piloté par les labels. Les deux vous donnent un seul port public, la terminaison du TLS et le renouvellement automatique des certificats.

Si vos services sont pour la plupart statiques et que vous en ajoutez rarement de nouveaux, nginx-proxy avec son acme-companion est le moyen le plus simple d’obtenir HTTPS. Si vous déployez fréquemment, faites tourner de nombreux conteneurs de courte durée ou souhaitez un dashboard et des middlewares, Traefik justifie une courbe d’apprentissage plus exigeante. Caddy est la troisième option à connaître et se situe entre les deux.

Qu’est-ce qu’un proxy inverse sur Docker et pourquoi en utiliser un?

Un proxy inverse sur Docker est un conteneur qui accepte tout le trafic web entrant sur les ports 80 et 443, puis transmet chaque requête au conteneur backend approprié selon le hostname ou le chemin demandé. Sans lui, chaque conteneur nécessitant un accès public devrait publier son propre port hôte, et les certificats TLS seraient dispersés entre les services.

Pour analyser n’importe quelle configuration, il est utile d’identifier les principaux composants. Appelons cela la pile de proxy inverse pour conteneurs en 5 éléments: point d’entrée, router, découverte de services, TLS et conteneur. Le point d’entrée est le port public. Le router associe un hostname à une règle de routage. La découverte de services est la façon dont le proxy apprend quels conteneurs existent. Le TLS désigne l’endroit où les certificats sont émis et où les connexions sont terminées. Le conteneur est votre véritable application. Chaque outil ci-dessous met en oeuvre les mêmes cinq étapes; ils ne diffèrent que par la part de chacune qui est automatique.

• Routage: un hostname par app, le tout via un point d’entrée unique, de sorte que vous n’exposez que les ports 80 et 443 à Internet.
• Terminaison du TLS: les certificats sont demandés, stockés et renouvelés en un seul endroit plutôt qu’à l’intérieur de chaque application.
• Un point d’entrée unique: un point de contrôle unique pour la journalisation, les limites de débit et les règles d’accès.

Comment avons-nous comparé les options de proxy inverse?

Chaque outil a été évalué au regard des cinq étapes ci-dessus ainsi que l’effort de configuration, en utilisant uniquement le comportement documenté sur le site officiel de chaque projet. Le but était de juger le fonctionnement au quotidien, et non de mesurer les performances.

La comparaison pèse quatre facteurs pratiques: du degré d’automatisation de la découverte de services, comment le TLS est obtenu et renouvelé, à quel point la configuration reste lisible à mesure que les services grandissent, et des connaissances préalables nécessaires à un utilisateur débutant. Les descriptions de fonctionnalités proviennent de la documentation de Traefik (traefik.io, au 2026-07-22), des pages des projets nginx-proxy et acme-companion (github.com/nginx-proxy, au 2026-07-22) et de la documentation de Caddy (caddyserver.com, au 2026-07-22). Aucun chiffre de performance n’est inventé ici car ils dépendent fortement de votre matériel et de votre charge de travail.

Comment configurer un serveur de proxy inverse sur Docker?

Définissez le proxy sous la forme d’un service unique dans docker-compose.yml, donnez-lui les deux ports publics et montez le socket Docker en lecture seule pour qu’il puisse découvrir vos autres conteneurs. Voici une configuration Traefik minimale avec le TLS automatique activé.

services:
  traefik:
    image: traefik:v3.1
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.le.acme.tlschallenge=true"
      - "[email protected]"
      - "--certificatesresolvers.le.acme.storage=/letsencrypt/acme.json"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "./letsencrypt:/letsencrypt"

Un service backend est ensuite déclaré au moyen de labels. Traefik les lit depuis l’API Docker, crée un router et demande un certificat via le resolver appelé le. Le démarrage du conteneur ne nécessite aucun redémarrage du proxy.

  whoami:
    image: traefik/whoami
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.whoami.rule=Host(`app.example.com`)"
      - "traefik.http.routers.whoami.entrypoints=websecure"
      - "traefik.http.routers.whoami.tls.certresolver=le"

nginx-proxy surveille le socket Docker et reconstruit sa configuration nginx dès qu’un conteneur doté de une variable d’environnement VIRTUAL_HOST, tandis qu’un conteneur compagnon gère les certificats Let’s Encrypt. Vous déclarez l’intention via des variables d’environnement plutôt que des labels.

services:
  nginx-proxy:
    image: nginxproxy/nginx-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "/var/run/docker.sock:/tmp/docker.sock:ro"
      - "certs:/etc/nginx/certs"
      - "vhost:/etc/nginx/vhost.d"
      - "html:/usr/share/nginx/html"
  acme:
    image: nginxproxy/acme-companion
    volumes_from:
      - nginx-proxy
    volumes:
      - "/var/run/docker.sock:/var/run/docker.sock:ro"
      - "acme:/etc/acme.sh"
    environment:
      - "[email protected]"
  app:
    image: traefik/whoami
    environment:
      - "VIRTUAL_HOST=app.example.com"
      - "LETSENCRYPT_HOST=app.example.com"
volumes:
  certs:
  vhost:
  html:
  acme:

Caddy est une troisième option plus simple. Il obtient et renouvelle les certificats automatiquement par défaut, et son fichier de configuration reste court. Définissez le service dans Compose et montez un Caddyfile plus un volume de données pour les certificats.

services:
  caddy:
    image: caddy:2
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - "./Caddyfile:/etc/caddy/Caddyfile"
      - "caddy_data:/data"
volumes:
  caddy_data:

Le Caddyfile ne nécessite qu’une ligne de proxy, le TLS étant automatique.

app.example.com {
    reverse_proxy app:8080
}

Comment nginx-proxy, Traefik et Caddy se comparent-ils?

Tous trois terminent le TLS et assurent le routage par hostname; ils diffèrent surtout par le style de configuration et par le degré d’automatisation. Le tableau résume les compromis pratiques.

Quel proxy inverse choisir et quand?

Adaptez l’outil à la fréquence à laquelle vos conteneurs changent et au niveau de configuration que vous êtes prêt à gérer. Les règles ci-dessous transforment la comparaison en une décision directe.

• Utilisez nginx-proxy lorsque vous faites tourner un ensemble fixe d’apps web et voulez un HTTPS fonctionnel avec très peu de configuration.
• Utilisez Traefik lorsque les conteneurs sont créés et détruits souvent, ou que vous voulez un dashboard, du middleware et un routage piloté par les labels.
• Utilisez Caddy lorsque vous voulez la configuration la plus courte possible et que le TLS automatique est votre principale exigence.
• Évitez nginx-proxy lorsque vos services montent et descendent en charge en permanence, car la découverte par variables d’environnement devient peu pratique à ce rythme.
• Évitez Traefik lorsque votre équipe n’a jamais touché à sa syntaxe de labels et que vous devez seulement faire du proxy vers deux ou trois sites stables.

Quelles sont les limites et les mises en garde?

Un proxy inverse sur Docker gère le routage entrant et le TLS, mais il ne peut pas tout résoudre et comporte de vrais risques. Monter le socket Docker, même en lecture seule, donne au proxy une large visibilité sur votre hôte, traitez donc ce conteneur comme un composant sensible sur le plan de la sécurité et gardez-le à jour.

Autres pièges fréquents : les certificats automatiques échouent si le DNS ne pointe pas encore vers l’hôte ou si les ports 80 et 443 sont bloqués, vérifiez donc le DNS avant votre premier déploiement. Les conteneurs backend doivent partager un réseau Docker avec le proxy, sinon le routage échoue sans message explicite. Les limites de débit de Let’s Encrypt vous imposent de tester sur son environnement de staging avant de passer aux certificats de production. Enfin, un proxy inverse n’ajoute pas de capacité; si un backend est lent, le proxy ne fait que transmettre la lenteur.

Note de transition, direct versus inverse. Tout cet article porte sur un proxy inverse, qui gère le trafic entrant vers vos conteneurs. L’opération inverse, qui consiste à envoyer du trafic sortant depuis votre machine via une autre IP pour des tâches comme le web scraping ou les tests de géolocalisation, nécessite plutôt un proxy direct. Les deux sont souvent confondus; la différence est expliquée dans reverse proxy vs forward proxy. Pour ce côté sortant, DataImpulse propose des proxies résidentiels d’origine éthique à partir de 1 dollar par GB. Ce service n’est pas un proxy inverse et n’achemine pas de trafic vers vos conteneurs, Il faut donc bien distinguer ces deux rôles.

Foire aux questions

Guides connexes

• NGINX Reverse Proxy
• Cloudflare Reverse Proxy
• NGINX Forward Proxy

Besoin de proxies sortants, pas seulement de routage entrant?

Si votre projet doit aussi atteindre le web depuis de nombreux emplacements, DataImpulse fournit des IP résidentielles, mobiles et de datacenter d’origine éthique dans 195 pays, en paiement à l’usage à partir de 1 dollar par GB sans abonnement. Créez un compte gratuit pour l’essayer aux côtés de votre configuration de proxy inverse.