Modes réseau Docker : bridge/host/none/container — performance et choix de scénarios

Dans le terminal, la ligne verte « Container started » s’affiche, le service tourne pourtant curl reste en timeout. J’ai relu docker logs trois fois sans erreur, le mapping de ports -p 8080:80 est configuré, le routage est bon, le pare-feu est désactivé. Où est le problème ?

J’ai fini par découvrir que c’était le mode réseau qui était mal choisi. Je pensais qu’un simple docker run -p suffisait, sans savoir que Docker propose quatre modes réseau : bridge, host, none et container.

Si vous aussi vous avez vécu « le conteneur démarre mais reste inaccessible », ou si la configuration réseau Docker vous échappe, cet article explique en langage simple les différences, principes et cas d’usage de ces quatre modes. Pas de théorie complexe sur les espaces de noms réseau Linux — seulement ce qu’il faut vraiment savoir en pratique.

D’abord, les fondations du réseau Docker — le pont docker0

Qu’est-ce que docker0 ? La « passerelle du quartier » de vos conteneurs

Une fois Docker installé, une interface virtuelle nommée docker0 apparaît automatiquement. Imaginez-la comme la passerelle du quartier : tous les conteneurs (résidents) qui veulent accéder à Internet passent par elle.

Ouvrez un terminal et essayez :

ip addr show docker0

Vous verrez une sortie du type :

docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0

Vous voyez ce 172.17.0.1 ? C’est l’adresse IP de docker0. Docker attribue à chaque nouveau conteneur une IP du segment 172.17.0.0/16, par exemple 172.17.0.2, 172.17.0.3, etc.

Regardez aussi la liste des réseaux Docker :

docker network ls

NETWORK ID     NAME      DRIVER    SCOPE
7f8a2b3c9d4e   bridge    bridge    local

Ce réseau bridge par défaut repose sur le pont docker0.

veth pair : le « talkie-walkie » qui connecte les conteneurs

docker0 seul ne suffit pas. Les conteneurs vivent dans leur « chambre indépendante » (terme pro : espace de noms réseau). Comment communiquer avec docker0 ?

La réponse : veth pair. C’est comme une paire de talkie-walkies : une extrémité dans le conteneur s’appelle eth0, l’autre sur l’hôte s’appelle vethXXX (par exemple veth9a7b4c), les deux se « parlent » directement.

Démarrez un conteneur pour tester :

docker run -d --name test-nginx nginx

Sur l’hôte, regardez les interfaces :

ip addr | grep veth

Un nouveau périphérique veth apparaît. Entrez dans le conteneur :

docker exec test-nginx ip addr

Le conteneur a une interface eth0 avec l’IP 172.17.0.2. Ce eth0 et le vethXXX sur l’hôte forment une paire : un paquet sort de eth0, arrive instantanément sur vethXXX, passe par docker0, puis par l’interface hôte (eth0 ou ens33) pour sortir vers Internet.

La chaîne complète :

Intérieur du conteneur (172.17.0.2)
  ↓ eth0
  ↓ (veth pair)
  ↓ vethXXX
  ↓
Pont docker0 (172.17.0.1)
  ↓ NAT
  ↓
Interface hôte (ex. 192.168.1.100)
  ↓
Internet

Ça paraît un peu tortueux, mais en pratique c’est très rapide. Un ping vers l’IP du conteneur donne une latence de quelques dixièmes de milliseconde.

Franchement, la première fois que j’ai vu le concept de veth pair, j’étais perdu un moment. Puis j’ai compris : c’est un câble virtuel, une extrémité dans le conteneur, l’autre sur docker0, c’est tout.

Mode Bridge — l’« option par défaut » de Docker

Pourquoi bridge par défaut ?

Sans mode réseau spécifié, Docker utilise automatiquement le mode bridge. La raison est simple : un bon équilibre entre isolation et simplicité.

🔥 Ne perdez plus des mois sur des produits sans demande ! Validez vos promesses SaaS avec Adsterra à petit budget →

Tester l'MVP →Pub

Le mode bridge donne à chaque conteneur une IP indépendante, évite les conflits de ports, et permet d’exposer facilement les services sur l’hôte via -p. Pour la plupart des scénarios, c’est suffisant.

Par exemple, lancez deux conteneurs Nginx :

docker run -d -p 8080:80 --name web1 nginx
docker run -d -p 8081:80 --name web2 nginx

Les deux écoutent le port 80, mais dans des espaces réseau séparés, donc pas de conflit. L’hôte accède via 8080 et 8081, Docker fait le NAT en arrière-plan.

Avec docker inspect web1, regardez la config réseau :

"Networks": {
    "bridge": {
        "IPAddress": "172.17.0.2",
        "Gateway": "172.17.0.1"
    }
}

Le conteneur obtient l’IP privée 172.17.0.2, la passerelle est docker0 à 172.17.0.1.

Bridge par défaut vs bridge personnalisé : une différence clé

Attention à ce piège. Sur le réseau bridge par défaut (docker0), les conteneurs ne communiquent que par IP, sans résolution par nom.

Essayez :

docker run -d --name db mysql
docker run -it --name app alpine ping db

Le ping échoue. Il faut utiliser ping 172.17.0.2 avec l’IP explicite.

Mais si vous créez un réseau bridge personnalisé :

docker network create mynet
docker run -d --name db --network mynet mysql
docker run -it --name app --network mynet alpine ping db

Là, ça fonctionne. Le réseau bridge personnalisé inclut la résolution DNS : le nom du conteneur sert de nom d’hôte.

C’est aussi pourquoi la production recommande un réseau personnalisé plutôt que docker0 par défaut — la découverte de services est bien plus simple, sans IP figées.

Le secret derrière -p : le NAT

Avec -p 8080:80, Docker ajoute une règle NAT dans iptables de l’hôte :

iptables -t nat -L -n | grep 8080

Vous verrez une sortie du type :

DNAT  tcp  --  0.0.0.0/0  0.0.0.0/0  tcp dpt:8080 to:172.17.0.2:80

Tout le trafic vers le port 8080 de l’hôte est redirigé vers 172.17.0.2:80 du conteneur.

C’est pourquoi http://IP_hôte:8080 accède au service dans le conteneur — Docker fait la conversion d’adresse.

Cas d’usage du mode Bridge

En résumé, le mode bridge convient à :

• Architecture microservices : plusieurs conteneurs qui collaborent, isolation et communication (avec un réseau bridge personnalisé)
• Environnement de développement : démarrer rapidement des services, le bridge par défaut suffit
• Applications Web avec mapping de ports : blog, API, etc.

Côté performance, le mode bridge a une surcharge NAT et veth pair, mais honnêtement, pour la plupart des applications c’est négligeable. Les vrais goulots d’étranglement sont rares — ne vous inquiétez pas trop au départ.

Mode Host — le choix « performance avant tout »

Qu’est-ce que le mode Host ? Directement « à nu »

Le mode host est le plus direct : le conteneur n’a plus de réseau indépendant, il utilise la pile réseau de l’hôte.

Ajoutez --net=host au lancement :

docker run -d --net=host --name web nginx

Le conteneur n’a plus d’IP indépendante, plus d’interface eth0 — il partage les interfaces de l’hôte. La config réseau dans le conteneur est identique à ip addr sur l’hôte.

Point clé : plus besoin de -p pour le mapping. Un service qui écoute le port 80 dans le conteneur est accessible directement via IP_hôte:80.

Où est l’avantage performance ?

Le mode host évite docker0, veth pair et le NAT. Les paquets entrent et sortent directement par l’interface hôte, comme un processus natif sur l’hôte.

Des benchmarks montrent qu’en haute concurrence, le mode host est 5 à 10 % plus rapide que bridge. Peu en apparence, mais pour des applications sensibles à la latence (trading haute fréquence, serveurs de jeu temps réel), la différence compte.

J’ai eu un cas : Nginx en reverse proxy, dizaines de milliers de requêtes par seconde. En passant en mode host, la latence P99 est passée de 12 ms à 9 ms. Seulement 3 ms de gagnées, mais pour ce projet, ça valait des milliers d’euros.

Les pièges et le prix du mode Host

Meilleures performances, mais plusieurs pièges :

Piège 1 : conflits de ports

Avec les ports de l’hôte directement, plusieurs conteneurs sur le même port échouent :

docker run -d --net=host nginx  # écoute 80
docker run -d --net=host nginx  # écoute encore 80, erreur : Address already in use

Comme lancer deux Nginx directement sur l’hôte. Pour plusieurs instances, changez le port d’écoute dans le conteneur ou évitez host.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Piège 2 : le service doit écouter sur 0.0.0.0

Si le service n’écoute que sur 127.0.0.1, l’extérieur ne peut pas y accéder. Il faut écouter sur 0.0.0.0.

Une fois, j’ai lancé un service Node.js en mode host avec app.listen(3000, 'localhost') — inaccessible de l’extérieur. Corrigé avec app.listen(3000, '0.0.0.0').

Piège 3 : perte d’isolation réseau

Le conteneur accède directement à toutes les ressources réseau de l’hôte — risque de sécurité élevé. Du code tiers non fiable en mode host, c’est se creuser un piège.

Quand utiliser le mode Host ?

Honnêtement, n’envisagez host que face à un vrai goulot de performance. Pour la plupart des cas, la surcharge du mode bridge n’est pas un problème.

Le mode host convient à :

• Outils de monitoring : Prometheus, Grafana, ELK — accès direct aux ressources réseau de l’hôte
• Proxy haute performance : Nginx, HAProxy pour l’équilibrage de charge, latence minimale
• Bases de données : MySQL, Redis sensibles aux performances réseau (attention à la sécurité)

Si votre application traite quelques milliers de requêtes par seconde, ne vous embêtez pas avec host — bridge suffit.

Modes None et Container — « réservés aux cas particuliers »

Mode None : bac à sable totalement déconnecté

Le mode none, c’est littéralement : aucun réseau pour le conteneur.

docker run -it --net=none alpine sh

Dans le conteneur, ip addr ne montre qu’une interface loopback (lo) — pas d’Internet, les autres conteneurs ne peuvent pas l’atteindre.

Quand utiliser le mode None ?

Franchement, je l’ai presque jamais utilisé en production. Les cas sont très étroits :

• Tests de sécurité : exécuter du code non fiable, isolation totale pour éviter les fuites
• Traitement de données offline : calcul local sans communication réseau
• Configuration réseau manuelle : cas rares nécessitant une config réseau entièrement custom (outils comme pipework pour configurer veth manuellement)

Sans recherche en sécurité ou besoin réseau très spécifique, vous n’en aurez probablement pas besoin.

Mode Container : deux conteneurs « partagent le réseau »

Le mode container fait qu’un conteneur utilise l’espace de noms réseau d’un autre. Ça semble abstrait, un exemple clarifie :

# D'abord lancer un conteneur
docker run -d --name web nginx

# Le second partage le réseau de web
docker run -it --net=container:web alpine sh

Les deux conteneurs partagent la même config réseau : même IP, mêmes ports, mêmes interfaces. Dans le second conteneur, localhost:80 accède à nginx.

Application typique du mode Container : le Pod Kubernetes

Le Pod Kubernetes repose sur le mode container. Un Pod contient plusieurs conteneurs qui partagent le réseau d’un conteneur « pause ».

Par exemple, un Pod avec l’application et un sidecar de collecte de logs — ils communiquent via localhost, sans exposer de ports à l’extérieur.

Mais avec Docker seul (sans Kubernetes), le mode container est peu utilisé. Un réseau bridge personnalisé permet aussi la communication inter-conteneurs, avec plus de flexibilité.

Positionnement de ces deux modes

En résumé, none et container sont plutôt des « capacités de bas niveau » que des solutions quotidiennes. Ils offrent de la flexibilité pour des cas spéciaux, mais dans 80 % des situations vous n’en avez pas besoin.

Retenez :

• Mode none : isolation réseau totale (très rare)
• Mode container : courant dans Kubernetes et outils d’orchestration, rare en Docker seul

Décision pratique : choisir le bon mode réseau

Un diagramme de décision

Face à un projet concret, quel mode choisir ? Voici un flux simple :

Isolation réseau nécessaire ?
│
├─ Non → Goulot de performance ?
│       │
│       ├─ Oui → Mode Host (attention aux risques sécurité)
│       └─ Non → Mode Bridge (plus sécurisé)
│
└─ Oui → Communication par nom entre conteneurs ?
        │
        ├─ Oui → Réseau Bridge personnalisé
        └─ Non → Réseau Bridge par défaut

Cas spéciaux :

• Aucun réseau nécessaire → Mode None
• Conteneurs dans un Pod Kubernetes → Mode Container

Tableau de recommandations par scénario

Trois idées reçues courantes

Idée reçue 1 : « Le mode host est toujours le meilleur »

Faux. Le mode host sacrifie isolation et flexibilité ; le gain de performance est souvent négligeable.

J’ai vu des gens lancer tous leurs conteneurs en host — conflits de ports, problèmes de sécurité. Les perfs étaient un peu meilleures, mais la maintenance coûtait 10 fois plus.

La réalité : 80 % des applications suffisent avec bridge. Ne vous laissez pas séduire par « plus performant ».

Idée reçue 2 : « Le bridge par défaut suffit »

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Pas en production. Le bridge par défaut ne résout pas les noms — plusieurs services doivent utiliser des IP figées ou des variables d’environnement, fragile.

Créer un réseau bridge personnalisé est simple :

docker network create mynet
# Spécifier le réseau dans docker-compose.yml

La réalité : 2 minutes de config réseau personnalisé économisent des heures de débogage.

Idée reçue 3 : « Tous les problèmes réseau viennent du mauvais mode »

Pas forcément. Souvent c’est le pare-feu, iptables ou le DNS.

Étapes de diagnostic :

1. Depuis le conteneur, pingez la passerelle (IP de docker0)
2. Puis pingez l’IP externe de l’hôte
3. Vérifiez les règles iptables (DROP)
4. Vérifiez la config du daemon Docker (/etc/docker/daemon.json)

La réalité : le mode n’est qu’une première étape — le dépannage réseau demande une approche systématique.

Astuces avancées

Astuce 1 : un conteneur sur plusieurs réseaux

Parfois un conteneur doit rejoindre deux réseaux (frontend et backend) :

docker network create frontend
docker network create backend

docker run -d --name web --network frontend nginx
docker network connect backend web

Le conteneur web est maintenant sur frontend et backend.

Astuce 2 : contrôle précis de l’attribution d’IP

Avec un réseau personnalisé, spécifiez sous-réseau et passerelle :

docker network create \
  --driver bridge \
  --subnet 192.168.10.0/24 \
  --gateway 192.168.10.1 \
  mynet

docker run -d --network mynet --ip 192.168.10.100 nginx

Utile quand une IP fixe est requise (liste blanche pare-feu, par exemple).

Astuce 3 : outils pour diagnostiquer les problèmes réseau

Dans le conteneur, ces outils aident :

# Installer les outils réseau
docker exec -it <container> apk add curl netcat-openbsd

# Tester la connectivité
docker exec <container> nc -zv <host> <port>

# Voir la table de routage
docker exec <container> ip route

# Capture de paquets (nécessite des droits sur l'hôte)
docker exec <container> tcpdump -i eth0

Conclusion

Récapitulons rapidement les quatre modes réseau :

• Mode Bridge : option par défaut, convient à la plupart des cas ; en production, préférez un bridge personnalisé
• Mode Host : performance prioritaire, mais isolation sacrifiée — seulement en cas de vrai goulot
• Mode None : déconnexion totale, usage très rare
• Mode Container : réseau partagé, surtout dans Kubernetes

Retenez : il n’y a pas de meilleur mode, seulement le plus adapté.

Si vous débutez avec Docker, commencez par le bridge par défaut. Ajustez selon les problèmes concrets : découverte de services difficile → bridge personnalisé ; performances insuffisantes → host. Ne cherchez pas dès le départ le mode « optimal ».

Essayez par vous-même : créez un réseau personnalisé, lancez quelques conteneurs, testez s’ils s’accèdent par nom. Une pratique vaut dix articles.

Si vous rencontrez des problèmes réseau Docker en projet, n’hésitez pas à en discuter en commentaire. Le sujet est profond, mais avec ces bases, vous résoudrez 80 % des problèmes seul.