Proxy dans Docker : configuration via conteneur, réseau et variables d'environnement — guide pas à pas

Docker est depuis longtemps devenu le standard pour lancer des parseurs, des bots, des automatisations publicitaires et de petits services. Mais les conteneurs ont une particularité : ils vivent dans un environnement isolé et ignorent tout des proxys que vous avez configurés sur votre ordinateur. Résultat : le script à l'intérieur du conteneur sort sur Internet avec votre vraie IP, alors que vous croyez travailler via un proxy mobile. Ce guide comble cette lacune une bonne fois pour toutes.

Introduction : ce que vous allez obtenir et à qui ce guide s'adresse

Après avoir suivi ces instructions, vous saurez configurer un proxy dans Docker aux trois niveaux où c'est possible : pour un conteneur individuel via les variables d'environnement, pour tout le client et le démon Docker via des fichiers de configuration, et au niveau du réseau via un conteneur-passerelle dédié. Vous comprendrez en quoi ces niveaux diffèrent, quand utiliser lequel, et comment vérifier que le trafic passe réellement par le proxy plutôt qu'à côté.

À qui s'adresse ce guide pas à pas

• Les marketeurs et spécialistes SMM qui lancent dans Docker des services d'autopublication, d'analyse ou de monitoring et veulent que chaque outil travaille avec sa propre IP mobile.
• Les arbitragistes qui ont des dizaines de conteneurs avec trackers, parseurs d'offres et services de spy, et dont chacun a besoin d'un géo différent.
• Les développeurs qui doivent tester une application depuis une autre région ou faire tourner des tests d'intégration via un proxy.
• Les chefs d'entreprise dont les employés ou les prestataires déploient une infrastructure en conteneurs, et qui doivent comprendre comment fonctionne le proxy dans ce contexte.

Ce qu'il faut savoir au préalable

Nous ne supposons aucune connaissance approfondie. Il suffit de savoir ouvrir un terminal, copier une commande et lire ce qu'elle affiche. Si vous n'avez jamais travaillé avec Docker, ne vous inquiétez pas : dans la section des notions de base, nous expliquerons tous les termes dans un langage simple. Kubernetes, l'orchestration de clusters et les plateformes cloud ne sont volontairement pas abordés : c'est un sujet à part, et ici nous restons strictement au niveau de Docker.

Combien de temps cela prendra

Un parcours complet avec les vérifications prendra entre 60 et 120 minutes. Si vous n'avez besoin que d'un seul scénario, par exemple un proxy pour un conteneur, 15 minutes suffiront. Si Docker n'est pas encore installé, ajoutez 20 à 30 minutes pour l'installation.

Préparation : outils, accès et prérequis système

Avant de configurer un proxy dans Docker, rassemblez tout le nécessaire. Vous éviterez ainsi de vous interrompre pour chercher un identifiant ou installer un utilitaire en pleine procédure.

Ce dont vous aurez besoin

1. Un ordinateur ou un serveur avec Docker. Linux (Ubuntu 22.04 ou 24.04, Debian 12), macOS avec Docker Desktop ou Windows 10/11 avec Docker Desktop et WSL2 feront l'affaire. En 2026, les versions actuelles sont Docker Engine 27 et supérieures, et Docker Compose v2, qui s'appelle avec la commande docker compose (avec un espace, sans tiret).
2. Les données du proxy mobile. Vous avez besoin de quatre choses : l'adresse de l'hôte (IP ou nom de domaine), le port, l'identifiant et le mot de passe. Vous les trouverez dans votre espace client chez le fournisseur. Renseignez-vous aussi sur le protocole disponible : HTTP ou SOCKS5. La plupart des fournisseurs de proxys mobiles, dont mobileproxy.space, proposent les deux sur des ports différents.
3. Un terminal. Sur Linux et macOS, il est intégré. Sur Windows, utilisez PowerShell ou le terminal WSL2 (la seconde option est plus pratique, car les commandes sont identiques à celles de Linux).
4. Un éditeur de texte. N'importe lequel : nano, vim, VS Code, Notepad++. Utile pour modifier les fichiers de configuration.
5. L'utilitaire curl. Généralement déjà installé. Il vous aidera à vérifier par quelle IP sort le trafic.

Prérequis système

• Au minimum 2 Go de RAM et 10 Go d'espace disque libre pour Docker et les images.
• Des droits administrateur : sur Linux, l'accès à sudo ; sur Windows et macOS, un compte administrateur pour installer Docker Desktop.
• Une connexion Internet stable pour télécharger les images.

Sauvegardes

Au cours de la procédure, nous allons modifier des fichiers de configuration Docker. Une erreur dedans peut empêcher Docker de démarrer. Avant de modifier un fichier, faites donc une copie. Sur Linux, c'est une seule commande :

sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak

Pareil pour le fichier ~/.docker/config.json. Si le fichier n'existe pas encore, inutile de faire une sauvegarde, mais notez que vous l'avez créé de zéro : dans ce cas, il suffit de le supprimer pour revenir en arrière.

Conseil : Créez un fichier texte avec un modèle de vos données proxy au format protocol://login:password@host:port. Vous collerez cette chaîne de nombreuses fois, et un modèle prêt à l'emploi vous évitera les fautes de frappe.

Notions de base : comment fonctionne Docker et où se niche le proxy

Pour que la configuration d'un proxy dans Docker ne relève pas de la magie, clarifions les termes. Si vous maîtrisez déjà les conteneurs, parcourez cette section rapidement, mais prêtez attention au passage sur les trois niveaux de proxy : c'est là que se cachent la plupart des erreurs.

Les termes clés expliqués simplement

• Image — un modèle, un ensemble « figé » de fichiers et de programmes. Par exemple, une image avec Python ou une image avec un navigateur.
• Conteneur — une copie lancée d'une image. On peut lancer autant de conteneurs que l'on veut à partir d'une même image, et chacun sera isolé des autres.
• Démon Docker (daemon, dockerd) — le service en arrière-plan qui crée les conteneurs, télécharge les images et gère les réseaux. C'est le démon qui va sur Internet chercher les images quand vous tapez docker pull.
• Client Docker (docker CLI) — la commande docker dans le terminal. Elle envoie vos ordres au démon.
• Variables d'environnement — des valeurs nommées, accessibles aux programmes à l'intérieur du conteneur. Par exemple, HTTP_PROXY=http://user:pass@host:port. De nombreux programmes lisent automatiquement ces variables et se mettent à passer par le proxy indiqué.
• Réseau Docker — un réseau virtuel qui relie les conteneurs. Les conteneurs d'un même réseau utilisateur se voient entre eux par leurs noms.
• Docker Compose — un outil qui décrit plusieurs conteneurs, leurs variables et leurs réseaux dans un seul fichier YAML et les lance en une commande.

Les trois niveaux de proxy dans Docker

C'est la partie théorique la plus importante. Quand on parle de « proxy dans Docker », on peut désigner trois choses totalement différentes, et elles se configurent différemment.

1. Proxy pour le démon. Nécessaire pour que Docker lui-même télécharge les images via un proxy. Cela concerne les commandes docker pull et docker build quand elles récupèrent des images de base. Ce niveau n'a aucun impact sur le trafic de vos applications à l'intérieur des conteneurs.
2. Proxy pour les conteneurs via les variables d'environnement. On transmet HTTP_PROXY, HTTPS_PROXY et NO_PROXY à l'intérieur du conteneur, et l'application décide elle-même de les utiliser ou non. C'est la méthode la plus répandue et la plus simple, mais elle ne fonctionne qu'avec les programmes qui respectent ces variables.
3. Proxy au niveau du réseau. Le trafic du conteneur est dirigé via un autre conteneur-passerelle ou via un réseau spécialement configuré. L'application à l'intérieur peut totalement ignorer l'existence du proxy. C'est plus fiable, mais demande plus de configuration.

Ce qu'il faut comprendre avant de commencer

Les variables d'environnement avec proxy ne sont qu'une recommandation pour le programme. L'utilitaire curl, le gestionnaire de paquets pip, la bibliothèque requests en Python, Node.js avec le paquet global-agent, wget, apt — tous lisent HTTP_PROXY. En revanche, les navigateurs en mode headless, certaines applications Go et de nombreux utilitaires binaires peuvent ignorer ces variables. C'est pourquoi, après la configuration, vérifiez toujours l'IP externe réelle au lieu de vous fier au fait que la variable est définie.

Autre subtilité : la casse. Historiquement, certains programmes lisent http_proxy en minuscules, d'autres HTTP_PROXY en majuscules. La bonne pratique est de définir les deux variantes en même temps. La variable NO_PROXY liste les adresses pour lesquelles il ne faut pas utiliser le proxy : localhost, 127.0.0.1, les domaines internes, les noms des conteneurs voisins.

Enfin, le format de l'adresse proxy. Pour un proxy HTTP, la chaîne ressemble à http://login:password@host:port. Pour SOCKS5 — socks5://login:password@host:port ou socks5h://login:password@host:port. Le h à la fin signifie que les requêtes DNS passent aussi par le proxy, ce qui est généralement préférable pour les proxys mobiles : le site cible ne verra ainsi pas le résolveur DNS de votre fournisseur d'accès.

Étape 1 : vérifier Docker et préparer les données du proxy

Objectif de l'étape : s'assurer que Docker fonctionne et que vos données proxy sont correctes et accessibles depuis cet ordinateur. Sans cette vérification, vous risquez de chercher une erreur dans la configuration pendant une demi-heure alors que le problème était une faute de frappe dans le mot de passe.

Vérification de Docker

1. Ouvrez le terminal.
2. Tapez docker --version et appuyez sur Entrée. Vous devez voir une ligne du type Docker version 27.x.x. Si le terminal indique que la commande est introuvable, Docker n'est pas installé : installez Docker Desktop (Windows, macOS) ou Docker Engine (Linux) selon la documentation officielle, puis revenez ici.
3. Tapez docker compose version. Sortie attendue : Docker Compose version v2.x.x.
4. Tapez docker run --rm hello-world. Docker téléchargera une minuscule image de test et affichera un message contenant Hello from Docker. Cela signifie que le démon fonctionne et que vous avez les droits pour lancer des conteneurs.

Conseil : Si sur Linux la commande docker demande sudo, ajoutez-vous au groupe docker : sudo usermod -aG docker $USER, puis déconnectez-vous et reconnectez-vous. Ensuite, toutes les commandes de ce guide fonctionneront sans sudo.

Vérification du proxy depuis l'hôte

Avant d'aller porter le proxy dans le conteneur, vérifions qu'il répond bien. Remplacez les données d'exemple par les vôtres. Dans les exemples, nous utiliserons l'adresse 185.10.10.10, le port 1050 pour HTTP et 1051 pour SOCKS5, l'identifiant user123 et le mot de passe secret. Vous aurez évidemment vos propres valeurs.

1. D'abord, découvrez votre IP habituelle sans proxy : curl -s ifconfig.me. Notez ou mémorisez le résultat.
2. Maintenant, une requête via le proxy HTTP : curl -s -x http://user123:secret@185.10.10.10:1050 ifconfig.me
3. Si vous avez SOCKS5 : curl -s -x socks5h://user123:secret@185.10.10.10:1051 ifconfig.me
4. Comparez le résultat avec celui de l'étape 1. L'IP doit être différente et appartenir à un opérateur mobile.

Caractères spéciaux dans le mot de passe

Si l'identifiant ou le mot de passe contient les caractères @, :, /, #, ? ou un espace, il faut les encoder au format URL, sinon la chaîne proxy sera cassée. Le caractère @ devient %40, : devient %3A, / devient %2F, # devient %23, ? devient %3F, l'espace devient %20. Par exemple, le mot de passe pa@ss s'écrit dans la chaîne proxy pa%40ss.

✅ Vérification : La commande curl via le proxy a renvoyé une IP différente de votre IP domestique, et la réponse est arrivée en une à trois secondes. Si vous obtenez une erreur 407, vérifiez l'identifiant et le mot de passe. Si c'est Connection refused ou un timeout — vérifiez l'hôte, le port et si votre IP actuelle est bien ajoutée à la liste blanche dans l'espace client du fournisseur (sur certains forfaits, l'authentification par IP est activée par défaut).

Étape 2 : configurer le proxy pour un conteneur via les variables d'environnement

Objectif de l'étape : lancer un conteneur dont tout le trafic HTTP passe par le proxy mobile, et le vérifier par l'IP externe. C'est le scénario de base par lequel il faut commencer : il ne touche pas aux réglages système et s'annule facilement.

Lancement avec le flag -e

Le flag -e (ou --env) de la commande docker run transmet une variable d'environnement à l'intérieur du conteneur. Nous allons en transmettre quatre d'un coup : le proxy pour HTTP, celui pour HTTPS et les exceptions, chacune dans deux casses.

1. Copiez la commande ci-dessous dans un éditeur et remplacez les données proxy par les vôtres.
2. Exécutez la commande dans le terminal. Elle lancera un conteneur temporaire avec curl, qui fera une requête puis se terminera.

docker run --rm -e HTTP_PROXY=http://user123:secret@185.10.10.10:1050 -e HTTPS_PROXY=http://user123:secret@185.10.10.10:1050 -e http_proxy=http://user123:secret@185.10.10.10:1050 -e https_proxy=http://user123:secret@185.10.10.10:1050 -e NO_PROXY=localhost,127.0.0.1 -e no_proxy=localhost,127.0.0.1 curlimages/curl -s ifconfig.me

Remarquez que pour HTTPS_PROXY nous indiquons aussi http:// au début. Ce n'est pas une erreur. Cela définit le proxy par lequel passeront les requêtes HTTPS, tandis que la connexion au serveur proxy elle-même reste classique. Le schéma https:// dans la valeur de HTTPS_PROXY signifierait qu'il faut se connecter au proxy lui-même en TLS, ce que la plupart des fournisseurs ne prennent pas en charge.

Un fichier de variables au lieu d'une commande interminable

La commande est devenue volumineuse. Docker sait lire les variables depuis un fichier via le flag --env-file. C'est plus pratique et plus sûr : le mot de passe ne reste pas dans l'historique du terminal.

1. Créez un fichier proxy.env dans votre dossier de travail : nano proxy.env
2. Écrivez-y les lignes, une variable par ligne, sans guillemets et sans espaces autour du signe égal :

HTTP_PROXY=http://user123:secret@185.10.10.10:1050 HTTPS_PROXY=http://user123:secret@185.10.10.10:1050 http_proxy=http://user123:secret@185.10.10.10:1050 https_proxy=http://user123:secret@185.10.10.10:1050 NO_PROXY=localhost,127.0.0.1 no_proxy=localhost,127.0.0.1

Dans le vrai fichier, chaque variable doit être sur sa propre ligne. Enregistrez le fichier (dans nano, c'est Ctrl+O, Entrée, puis Ctrl+X) et lancez le conteneur :

docker run --rm --env-file proxy.env curlimages/curl -s ifconfig.me

Vérification depuis un conteneur en cours d'exécution

Il est souvent utile de voir ce que voit un conteneur de longue durée. Lançons Alpine Linux en mode interactif et vérifions les variables.

1. Exécutez docker run -it --rm --env-file proxy.env alpine sh. Vous serez à l'intérieur du conteneur, l'invite deviendra un dièse ou un signe dollar.
2. Tapez env | grep -i proxy. Vous verrez la liste de vos variables.
3. Tapez apk add --no-cache curl. Le gestionnaire de paquets apk récupérera lui-même https_proxy et téléchargera le paquet via le proxy.
4. Tapez curl -s ifconfig.me et vérifiez que l'IP est bien mobile.
5. Tapez exit pour sortir. Le conteneur sera supprimé automatiquement grâce au flag --rm.

Conseil : Pour vérifier l'IP, en plus de ifconfig.me, il est pratique d'utiliser des services qui renvoient du JSON avec des informations sur le pays, la ville et le fournisseur. Vous verrez ainsi immédiatement que l'IP appartient à un opérateur mobile de la région souhaitée, et pas simplement à « une autre IP ».

✅ Vérification : Les deux lancements avec curl ont renvoyé l'IP du proxy mobile. La commande env à l'intérieur du conteneur a affiché les variables HTTP_PROXY et HTTPS_PROXY avec vos données.

Problèmes possibles à cette étape

• L'IP n'a pas changé. L'application dans le conteneur ignore les variables d'environnement. Pour curl, ça n'arrive jamais, donc si curl affiche une IP mobile et que votre application non, passez à la méthode réseau de l'étape 6.
• Erreur invalid reference format. C'est généralement un espace ou un retour à la ligne en trop dans la commande. Assemblez la commande sur une seule ligne.
• Les variables ne sont pas visibles. Dans le fichier env-file, il ne doit pas y avoir de guillemets autour des valeurs : Docker les transmettrait littéralement, et l'adresse du proxy deviendrait incorrecte.

Étape 3 : configurer le proxy pour le client Docker afin que les variables soient transmises automatiquement

Objectif de l'étape : faire en sorte que chaque nouveau conteneur et chaque build d'image reçoive automatiquement les variables de proxy sans flags -e. Cela vous fait gagner du temps si vous lancez en permanence différents conteneurs via le même proxy mobile.

Comment ça marche

Le client Docker lit le fichier config.json dans le dossier ~/.docker (sur Windows, c'est le dossier .docker dans le profil utilisateur). S'il contient une section proxies, le client ajoute à chaque docker run et docker build les variables indiquées dans le conteneur. Le démon n'est pas concerné, donc docker pull continuera de passer en direct.

Configuration pas à pas

1. Vérifiez si le fichier existe : cat ~/.docker/config.json. Si le fichier existe et contient déjà des réglages (par exemple auths avec des identifiants de registre), faites une copie : cp ~/.docker/config.json ~/.docker/config.json.bak
2. Ouvrez le fichier dans un éditeur : nano ~/.docker/config.json. Si le fichier n'existe pas, l'éditeur le créera.
3. Ajoutez la section proxies. Si le fichier était vide, son contenu entier sera :

{ "proxies": { "default": { "httpProxy": "http://user123:secret@185.10.10.10:1050", "httpsProxy": "http://user123:secret@185.10.10.10:1050", "noProxy": "localhost,127.0.0.1,*.local" } } }

Si le fichier contenait déjà d'autres clés, ajoutez proxies comme une clé supplémentaire de premier niveau, séparée par une virgule, sans supprimer celles qui existent. Surveillez l'appariement des accolades et des guillemets : le JSON ne pardonne pas une virgule oubliée.

1. Enregistrez le fichier.
2. Vérifiez la syntaxe. Sur Linux et macOS, c'est pratique ainsi : python3 -m json.tool ~/.docker/config.json. Si la sortie reprend votre fichier joliment formaté, tout va bien. Si une erreur avec un numéro de ligne apparaît, corrigez-la.
3. Lancez un conteneur de test sans aucun flag : docker run --rm curlimages/curl -s ifconfig.me. L'IP doit être mobile.
4. Regardez les variables de n'importe quel conteneur : docker run --rm alpine env. Dans la sortie figureront HTTP_PROXY, HTTPS_PROXY, NO_PROXY et leurs variantes en minuscules : Docker ajoute les deux casses lui-même.

⚠ Attention : La section proxies de config.json affecte tous les conteneurs que vous lancez avec cet utilisateur, y compris les bases de données, les serveurs web locaux et tout le reste. Si un service communique avec une API externe inaccessible via votre proxy, il plantera. Ajoutez ces adresses dans noProxy ou retirez temporairement la section.

Des proxys différents pour des connexions différentes

La clé default s'applique à toutes les connexions au démon. Si vous gérez plusieurs hôtes Docker via des contextes ou la variable DOCKER_HOST, vous pouvez indiquer à la place de default l'adresse d'un démon précis, par exemple tcp://192.168.1.50:2376, et le proxy ne s'appliquera qu'à celui-ci. Pour un travail local, default suffit.

Proxy lors de la construction d'images

Les réglages de config.json sont également transmis à docker build comme arguments de build. Cela signifie que les commandes RUN apt-get install ou RUN pip install à l'intérieur du Dockerfile passeront par le proxy. Point important : ces variables ne sont pas conservées dans l'image finale, ce qui est bon du point de vue de la sécurité : le mot de passe du proxy ne fuit pas vers ceux à qui vous transmettez l'image.

Conseil : Si vous voulez transmettre le proxy uniquement pour un build, sans toucher à config.json, utilisez les flags docker build --build-arg HTTP_PROXY=http://user123:secret@185.10.10.10:1050 --build-arg HTTPS_PROXY=http://user123:secret@185.10.10.10:1050 . Docker comprend ces arguments prédéfinis sans déclaration ARG dans le Dockerfile.

✅ Vérification : Le conteneur lancé sans flags -e sort sur Internet avec l'IP du proxy. La commande docker run --rm alpine env affiche les variables de proxy.

Comment revenir en arrière

Supprimez la section proxies de config.json ou restaurez le fichier depuis la sauvegarde : cp ~/.docker/config.json.bak ~/.docker/config.json. Aucun redémarrage n'est nécessaire, les changements s'appliquent au prochain lancement de conteneur.

Étape 4 : configurer le proxy pour le démon Docker afin que les images soient téléchargées via le proxy

Objectif de l'étape : faire en sorte que Docker lui-même (le démon) aille chercher les images via un proxy. C'est nécessaire quand l'accès direct au registre d'images depuis votre serveur est restreint par une politique d'entreprise, lent, ou quand vous voulez que toute l'activité réseau du serveur passe par un seul canal. Pour les tâches marketing, cette étape est souvent inutile, mais il vaut mieux la connaître : les erreurs au niveau du démon sont régulièrement confondues avec celles au niveau du conteneur.

Méthode 1 : fichier daemon.json (Linux, Docker 23 et plus récent)

1. Faites une copie : sudo cp /etc/docker/daemon.json /etc/docker/daemon.json.bak (si le fichier n'existe pas, la commande renverra une erreur, c'est normal).
2. Ouvrez le fichier : sudo nano /etc/docker/daemon.json
3. Ajoutez la section proxies :

{ "proxies": { "http-proxy": "http://user123:secret@185.10.10.10:1050", "https-proxy": "http://user123:secret@185.10.10.10:1050", "no-proxy": "localhost,127.0.0.1" } }

Remarquez que les clés s'écrivent ici avec un tiret et en minuscules : cela diffère du config.json du client, où les clés sont de style httpProxy. Les confondre est une erreur classique.

1. Enregistrez le fichier et redémarrez le démon : sudo systemctl restart docker
2. Vérifiez que le démon est bien reparti : sudo systemctl status docker. La sortie doit contenir active (running).
3. Vérifiez l'application : docker info | grep -i proxy. Vous verrez les lignes HTTP Proxy et HTTPS Proxy avec votre adresse, le mot de passe étant masqué par des astérisques.

Méthode 2 : fichier drop-in systemd (Linux, toutes versions)

C'est la méthode classique, qui fonctionne même sur les anciennes versions de Docker.

1. Créez le dossier : sudo mkdir -p /etc/systemd/system/docker.service.d
2. Créez le fichier : sudo nano /etc/systemd/system/docker.service.d/http-proxy.conf
3. Écrivez le contenu, chaque directive sur sa propre ligne :

[Service] Environment="HTTP_PROXY=http://user123:secret@185.10.10.10:1050" Environment="HTTPS_PROXY=http://user123:secret@185.10.10.10:1050" Environment="NO_PROXY=localhost,127.0.0.1"

1. Enregistrez, puis rechargez la configuration systemd : sudo systemctl daemon-reload
2. Redémarrez Docker : sudo systemctl restart docker
3. Vérifiez : sudo systemctl show --property=Environment docker. La sortie contiendra vos variables.

⚠ Attention : Ne configurez pas le proxy du démon par les deux méthodes à la fois. Si daemon.json et le fichier systemd contiennent des adresses différentes, le comportement deviendra imprévisible et le débogage pénible. Choisissez une méthode et tenez-vous-y.

Méthode 3 : Docker Desktop (Windows et macOS)

1. Ouvrez Docker Desktop, cliquez sur l'icône en forme d'engrenage dans le coin supérieur droit.
2. Dans le menu de gauche, sélectionnez Resources, puis Proxies.
3. Activez l'interrupteur Manual proxy configuration.
4. Dans les champs Web Server (HTTP) et Secure Web Server (HTTPS), collez l'adresse du proxy au format http://user123:secret@185.10.10.10:1050.
5. Dans le champ Bypass proxy settings for these hosts, saisissez localhost,127.0.0.1.
6. Cliquez sur Apply and restart. Docker Desktop redémarrera, cela prendra 30 à 60 secondes.

Docker Desktop applique ces réglages à la fois au démon et aux conteneurs, donc une modification séparée de config.json sur les systèmes de bureau est souvent inutile.

Vérification du résultat

1. Supprimez une petite image si vous en avez une : docker rmi alpine
2. Téléchargez-la à nouveau : docker pull alpine. Le téléchargement doit réussir.
3. Si le proxy dispose de statistiques de trafic (dans l'espace client mobileproxy.space, c'en est le cas), vous verrez que le volume de trafic consommé a augmenté de quelques mégaoctets.

✅ Vérification : docker info affiche l'adresse du proxy, docker pull télécharge les images sans erreur, le service docker est à l'état active.

Problèmes possibles

• Docker ne démarre pas après modification de daemon.json. La cause est presque toujours une syntaxe JSON erronée. Vérifiez le fichier avec python3 -m json.tool /etc/docker/daemon.json ou restaurez la copie.
• docker pull se bloque. Le proxy ne laisse pas passer les connexions vers le registre ou la limite de trafic du forfait est atteinte. Vérifiez le proxy depuis l'hôte avec curl, comme à l'étape 1.
• Erreur x509 certificate. Le proxy remplace les certificats (pertinent pour les proxys d'entreprise, rare pour les proxys mobiles). Renseignez-vous auprès du fournisseur.

Étape 5 : configurer le proxy dans Docker Compose

Objectif de l'étape : décrire le proxy dans le fichier compose.yaml pour qu'un groupe de conteneurs se lance en une commande avec les bons réglages, et que différents services puissent utiliser différents proxys mobiles. C'est précisément le scénario dont les arbitragistes et les marketeurs ont le plus souvent besoin : un parseur travaille via un proxy de Moscou, un second via un proxy de Kazan, et la base de données n'utilise aucun proxy.

Préparation du projet

1. Créez le dossier du projet et déplacez-vous dedans : mkdir proxy-demo, puis cd proxy-demo
2. Créez le fichier .env (avec le point au début) pour stocker les secrets : nano .env
3. Écrivez les variables, une par ligne :

PROXY_MSK=http://user123:secret@185.10.10.10:1050 PROXY_KZN=http://user456:secret2@185.10.10.20:1050

Compose lit le fichier .env automatiquement, et ses valeurs peuvent être insérées dans compose.yaml via la syntaxe ${NOM}. Ajoutez .env à .gitignore si le projet est sous contrôle de version : les mots de passe ne doivent pas finir dans le dépôt.

Fichier compose.yaml

Créez le fichier compose.yaml (nano compose.yaml) et décrivez trois services. En YAML, l'indentation compte : utilisez deux espaces par niveau, pas de tabulation.

services: parser-msk: image: curlimages/curl command: -s ifconfig.me environment: HTTP_PROXY: ${PROXY_MSK} HTTPS_PROXY: ${PROXY_MSK} http_proxy: ${PROXY_MSK} https_proxy: ${PROXY_MSK} NO_PROXY: localhost,127.0.0.1,db no_proxy: localhost,127.0.0.1,db parser-kzn: image: curlimages/curl command: -s ifconfig.me environment: HTTP_PROXY: ${PROXY_KZN} HTTPS_PROXY: ${PROXY_KZN} http_proxy: ${PROXY_KZN} https_proxy: ${PROXY_KZN} NO_PROXY: localhost,127.0.0.1,db no_proxy: localhost,127.0.0.1,db db: image: postgres:16-alpine environment: POSTGRES_PASSWORD: example

Ici, dans le vrai fichier, chaque ligne est placée séparément avec les bonnes indentations : services au niveau zéro, les noms de services avec une indentation de deux espaces, leurs paramètres à quatre, les variables d'environnement à six. Remarquez le nom db dans NO_PROXY : ainsi les parseurs accéderont à la base de données directement via le réseau interne Docker, au lieu d'essayer de l'atteindre via le proxy mobile, ce qui ne fonctionnerait de toute façon pas.

Lancement et vérification

1. Vérifiez comment Compose a substitué les variables : docker compose config. La commande affichera le fichier final avec les valeurs développées. Assurez-vous qu'à la place de ${PROXY_MSK} se trouve bien une adresse réelle.
2. Lancez : docker compose up. Compose téléchargera les images et démarrera les trois services, en affichant leurs logs dans le terminal.
3. Dans les logs, vous verrez des lignes du type parser-msk-1 | 91.xxx.xxx.xxx et parser-kzn-1 | 176.xxx.xxx.xxx : deux IP différentes issues de deux proxys différents. Postgres démarrera et attendra les connexions.
4. Arrêtez tout avec Ctrl+C, puis supprimez les conteneurs : docker compose down

Alternative : env_file pour chaque service

Si les variables sont nombreuses, plutôt que le bloc environment, il est plus pratique d'indiquer un fichier :

services: parser-msk: image: curlimages/curl command: -s ifconfig.me env_file: - proxy-msk.env

Le fichier proxy-msk.env contient alors les mêmes six lignes que proxy.env de l'étape 2. Ainsi chaque proxy est dans son propre fichier, et vous pouvez le remplacer sans ouvrir compose.yaml.

Proxy lors de la construction dans Compose

Si le service est construit à partir d'un Dockerfile et non pris tout fait, transmettez le proxy au build via build.args :

services: app: build: context: . args: HTTP_PROXY: ${PROXY_MSK} HTTPS_PROXY: ${PROXY_MSK}

Ainsi, pip, npm ou apt à l'intérieur du Dockerfile fonctionneront via le proxy, et les valeurs ne finiront pas dans l'image finale.

Conseil : Compose prend en charge plusieurs fichiers. Gardez un compose.yaml de base sans proxy, et décrivez uniquement les blocs environment dans compose.proxy.yaml. Lancez docker compose -f compose.yaml -f compose.proxy.yaml up quand vous avez besoin du proxy, et simplement docker compose up quand vous n'en avez pas besoin. C'est pratique en débogage : vous basculez entre les modes en une seconde.

✅ Vérification : docker compose config affiche les adresses proxy substituées, et dans les logs de docker compose up, les services avec des proxys différents affichent des IP différentes.

Étape 6 : configurer le proxy au niveau du réseau via un conteneur-passerelle

Objectif de l'étape : lancer un conteneur dédié qui accepte les connexions des voisins sur le réseau Docker et les redirige vers le proxy mobile. Les autres conteneurs s'adressent à la passerelle par son nom et ne stockent pas chez eux l'identifiant et le mot de passe. Cela résout trois problèmes d'un coup : centralise la gestion du proxy, élimine les mots de passe de dizaines de configs, et permet de changer le proxy sans redémarrer les conteneurs de travail.

Pourquoi une passerelle, si les variables existent

Imaginez que vous avez vingt conteneurs de parseurs et que le fournisseur a attribué un nouveau port. Avec les variables d'environnement, vous devrez modifier vingt configs et tout redémarrer. Avec une passerelle, vous changez une seule ligne à un seul endroit. De plus, certaines applications ne prennent pas en charge l'authentification proxy par identifiant/mot de passe, mais fonctionnent parfaitement avec un proxy sans authentification. La passerelle, à l'intérieur du réseau Docker fermé, ne demande pas d'authentification et se connecte elle-même au proxy mobile avec vos données.

Création du réseau

1. Créez un réseau utilisateur : docker network create proxynet
2. Vérifiez qu'il est apparu : docker network ls. La liste contiendra proxynet avec le driver bridge.

Un réseau utilisateur est nécessaire car c'est uniquement dans celui-ci que fonctionne la résolution de noms : un conteneur pourra s'adresser à la passerelle par le nom gateway, et non par une IP qui change à chaque redémarrage.

Lancement de la passerelle

Comme passerelle, nous utilisons gost — un serveur proxy compact, capable d'accepter des connexions sur un protocole et de les rediriger vers un autre avec authentification. L'image est disponible dans le registre public sous le nom gogost/gost.

1. Lancez le conteneur-passerelle :

docker run -d --name gateway --network proxynet --restart unless-stopped gogost/gost -L=http://:8118 -F=http://user123:secret@185.10.10.10:1050

Décortiquons les paramètres. Le flag -d lance le conteneur en arrière-plan. Le flag --name gateway définit le nom par lequel les voisins s'adresseront à lui. Le flag --network proxynet le connecte à notre réseau. Le flag --restart unless-stopped relance la passerelle après un redémarrage du serveur. Le paramètre -L=http://:8118 demande à gost d'accepter des connexions proxy HTTP sur le port 8118 sans authentification. Le paramètre -F indique vers quoi rediriger : votre proxy mobile avec identifiant et mot de passe.

1. Vérifiez que la passerelle fonctionne : docker logs gateway. Le log doit contenir une ligne indiquant que le serveur écoute sur le port 8118, sans erreur.

⚠ Attention : Ne publiez pas le port de la passerelle vers l'extérieur avec le flag -p si ce n'est pas absolument nécessaire. La passerelle fonctionne sans authentification, et un port 8118 ouvert sur un serveur public signifie que n'importe qui sur Internet pourra utiliser votre proxy mobile et consommer votre trafic. À l'intérieur du réseau proxynet, il n'est accessible qu'à vos conteneurs, et cela suffit.

Connexion des conteneurs de travail

1. Lancez un conteneur de test dans le même réseau, en indiquant la passerelle comme proxy :

docker run --rm --network proxynet -e HTTP_PROXY=http://gateway:8118 -e HTTPS_PROXY=http://gateway:8118 curlimages/curl -s ifconfig.me

1. Vous devez voir l'IP du proxy mobile. Remarquez : dans les variables, il n'y a ni identifiant, ni mot de passe, ni adresse réelle du proxy. Seule la passerelle connaît tout cela.

La même chose dans Compose

Pour un fonctionnement permanent, décrivez la passerelle et les services de travail dans le même compose.yaml :

services: gateway: image: gogost/gost command: -L=http://:8118 -F=${PROXY_MSK} restart: unless-stopped networks: - proxynet worker: image: curlimages/curl command: -s ifconfig.me environment: HTTP_PROXY: http://gateway:8118 HTTPS_PROXY: http://gateway:8118 NO_PROXY: localhost,127.0.0.1 depends_on: - gateway networks: - proxynet networks: proxynet: driver: bridge

La directive depends_on garantit que la passerelle démarre avant le worker. La valeur PROXY_MSK est tirée du fichier .env, comme à l'étape 5.

Plusieurs passerelles pour plusieurs géos

Vous voulez des proxys différents pour différents groupes de conteneurs ? Lancez plusieurs passerelles : gateway-msk, gateway-kzn, gateway-spb, chacune avec son propre -F. Les conteneurs de travail indiquent simplement le bon nom dans HTTP_PROXY. Vous pouvez aller plus loin et créer un réseau distinct par géo : les conteneurs du groupe Moscou ne pourront alors physiquement pas atteindre la passerelle de Kazan par accident.

Isolation : un conteneur sans accès direct à Internet

La variante la plus stricte consiste à interdire au conteneur de travail tout accès à Internet autrement que par la passerelle. Pour cela, créez un réseau interne avec le flag --internal : docker network create --internal isolated. Les conteneurs de ce réseau n'ont aucune route vers l'extérieur. Connectez la passerelle à deux réseaux à la fois (isolated et le réseau classique proxynet), et les workers uniquement à isolated. Désormais, même si l'application ignore les variables de proxy, elle ne pourra tout simplement pas sortir directement sur Internet et aucune fuite d'IP réelle ne se produira.

1. docker network create --internal isolated
2. docker network connect isolated gateway
3. docker run --rm --network isolated -e HTTP_PROXY=http://gateway:8118 -e HTTPS_PROXY=http://gateway:8118 curlimages/curl -s ifconfig.me
4. Pour contrôle, lancez le même conteneur sans variables de proxy : docker run --rm --network isolated curlimages/curl -s -m 5 ifconfig.me. La requête doit se terminer par un timeout : il n'y a pas d'accès direct.

Conseil : La combinaison réseau interne + passerelle est la meilleure protection contre les fuites lors du travail multi-comptes. Même si un développeur a oublié de configurer le proxy dans un nouveau service, celui-ci ne pourra pas exposer l'IP du serveur : soit il passera par la passerelle, soit il ne passera nulle part.

✅ Vérification : Un conteneur du réseau proxynet avec la variable HTTP_PROXY=http://gateway:8118 affiche l'IP du proxy mobile. Un conteneur du réseau interne sans proxy ne peut pas du tout accéder à Internet.

Problèmes possibles

• Could not resolve host: gateway. Le conteneur de travail n'est pas dans le bon réseau ou a été lancé dans le réseau par défaut, où les noms ne sont pas résolus. Vérifiez le flag --network.
• La passerelle redémarre en boucle. Erreur dans la chaîne -F : faute de frappe dans le mot de passe ou port incorrect. Consultez docker logs gateway.
• C'est lent. Les proxys mobiles sont par nature plus lents que ceux de centre de données, mais si la latence se compte en dizaines de secondes, vérifiez que le DNS ne passe pas à côté : utilisez socks5h au lieu de socks5 dans la chaîne -F, si le fournisseur propose SOCKS5.

Vérification du résultat : la checklist d'un proxy fonctionnel dans Docker

Parcourez la liste. Si chaque point est coché, vous maîtrisez complètement la configuration d'un proxy dans Docker en pratique.

Checklist

• curl depuis l'hôte via le proxy renvoie une IP mobile.
• Le conteneur avec le flag --env-file proxy.env renvoie une IP mobile.
• Le conteneur sans flags après configuration de config.json renvoie une IP mobile (si vous avez fait l'étape 3).
• docker info affiche l'adresse du proxy, et docker pull fonctionne (si vous avez fait l'étape 4).
• docker compose up lance les services, et les logs montrent des IP différentes pour des proxys différents.
• Le conteneur-passerelle fonctionne, les voisins passent par lui sans identifiant ni mot de passe.
• Un conteneur du réseau interne sans proxy ne peut pas accéder à Internet.

Comment tester de bout en bout

1. Lancez un conteneur longue durée : docker run -d --name test --network proxynet -e HTTP_PROXY=http://gateway:8118 -e HTTPS_PROXY=http://gateway:8118 alpine sleep 3600
2. Entrez dedans : docker exec -it test sh
3. Installez curl : apk add --no-cache curl. L'installation doit passer par le proxy.
4. Faites cinq requêtes d'affilée : for i in 1 2 3 4 5; do curl -s ifconfig.me; echo; done. Les cinq doivent renvoyer une IP mobile. Si votre proxy a la rotation automatique activée, les IP peuvent différer d'une requête à l'autre, c'est normal.
5. Sortez (exit) et supprimez le conteneur : docker rm -f test

Indicateurs de réussite

Une configuration réussie signifie que vous pouvez répondre en une seconde à trois questions : par quelle IP sort un conteneur donné, où est stocké le mot de passe du proxy, et que faut-il changer pour basculer un conteneur sur un autre proxy. Si la réponse à chaque question est évidente, c'est gagné.

Erreurs courantes lors de la configuration d'un proxy dans Docker et leurs solutions

Erreur 1 : l'IP ne change pas, alors que les variables sont définies

Cause : l'application à l'intérieur du conteneur ne lit pas les variables d'environnement de proxy. C'est typique des navigateurs headless, de certains programmes Go et des utilitaires qui utilisent leurs propres piles réseau.

Solution : vérifiez la documentation de l'application pour un flag proxy natif (chez les navigateurs, c'est généralement --proxy-server). S'il n'y a pas de flag, utilisez la passerelle et le réseau interne de l'étape 6 ou le proxy transparent de la section pour avancés.

Erreur 2 : 407 Proxy Authentication Required

Cause : identifiant ou mot de passe erroné, ou caractères spéciaux non encodés, ou authentification par IP activée côté proxy et IP du serveur absente de la liste blanche.

Solution : vérifiez les données depuis l'hôte avec curl. Encodez les caractères spéciaux. Ajoutez l'IP du serveur à la liste blanche dans l'espace client ou basculez le proxy en authentification par identifiant/mot de passe.

Erreur 3 : Docker ne démarre pas après modification de daemon.json

Cause : erreur de syntaxe JSON : virgule en trop, guillemet manquant, clés au style config.json au lieu du style daemon.json.

Solution : consultez le journal : sudo journalctl -u docker -n 50. La ligne fautive y sera indiquée. Corrigez ou restaurez la sauvegarde et redémarrez le service.

Erreur 4 : les conteneurs ne se voient plus

Cause : après un réglage global du proxy dans config.json, les requêtes vers les conteneurs voisins passent aussi par le proxy mobile, qui ne sait pas ce que sont db ou redis.

Solution : ajoutez les noms de services et les sous-réseaux internes dans NO_PROXY : localhost,127.0.0.1,db,redis,172.16.0.0/12. Notez que les masques de sous-réseau ne sont pas compris par tous les programmes, donc mieux vaut lister les noms explicitement.

Erreur 5 : docker build échoue sur apt-get ou pip

Cause : le build se fait sans proxy, parce que les variables sont définies pour les conteneurs et non pour le build, ou parce que le proxy du démon est configuré mais n'influence pas les étapes RUN.

Solution : transmettez --build-arg HTTP_PROXY et HTTPS_PROXY, ou configurez la section proxies dans le config.json du client : elle s'applique aussi au build.

Erreur 6 : le mot de passe du proxy est visible dans docker inspect et les logs

Cause : les variables d'environnement sont stockées dans les métadonnées du conteneur en clair, et quiconque a accès à Docker les verra via docker inspect.

Solution : utilisez la passerelle : les conteneurs de travail ne connaissent que l'adresse gateway:8118. Le mot de passe reste dans un seul conteneur et dans un fichier .env aux droits restreints (chmod 600 .env).

Erreur 7 : après redémarrage du serveur, le proxy ne fonctionne plus

Cause : le conteneur-passerelle n'a pas été lancé avec une politique de redémarrage, ou l'adresse de l'hôte du proxy mobile a changé.

Solution : ajoutez --restart unless-stopped à la passerelle. Utilisez le nom de domaine du proxy au lieu de l'IP, si le fournisseur en propose un. Vérifiez docker ps -a : si la passerelle est en statut Exited, consultez ses logs.

Erreur 8 : les sites HTTPS ne s'ouvrent pas, alors que HTTP fonctionne

Cause : seul HTTP_PROXY est défini, et HTTPS_PROXY est vide, ou bien HTTPS_PROXY utilise le schéma https:// au lieu de http://.

Solution : définissez toujours les deux variables avec la même valeur et le schéma http://.

Fonctionnalités supplémentaires pour les avancés : proxy transparent, rotation d'IP et sécurité

Cette section s'adresse à ceux qui ont passé les étapes de base et veulent tirer le maximum du duo Docker + proxys mobiles. Ici, moins de listes pas à pas et plus d'idées avec les commandes clés.

Proxy transparent : quand l'application ignore totalement le proxy

Si vous avez une application qui ne sait pas du tout travailler avec un proxy, vous pouvez détourner tout son trafic TCP au niveau de la pile réseau. L'idée est la suivante : le conteneur de travail est lancé avec le paramètre network_mode: service:gateway (dans Compose) ou --network container:gateway (dans docker run). Il utilise ainsi entièrement la pile réseau du conteneur-passerelle : la même IP, les mêmes interfaces, les mêmes règles de routage.

Dans la passerelle tourne alors un programme comme redsocks, qui écoute sur un port local et redirige les connexions vers un proxy SOCKS5, tandis que des règles iptables redirigent tout le trafic TCP sortant vers ce port. La passerelle a besoin pour cela de droits : cap_add: NET_ADMIN. L'application dans le conteneur de travail fait une requête classique vers le site, le noyau l'intercepte et la dirige vers redsocks, qui la redirige vers le proxy mobile. Aucune variable d'environnement. La configuration demande de la précision : une règle iptables erronée peut faire boucler le trafic, donc testez sur une machine séparée. Notez aussi qu'avec network_mode: service, le conteneur de travail perd ses propres ports et ses connexions à d'autres réseaux, tout cela devant être décrit sur la passerelle.

Rotation d'IP depuis le conteneur

Les proxys mobiles ont une particularité pour laquelle on les choisit : l'IP peut être changée sur demande. Les fournisseurs proposent un lien spécial de changement d'IP, qu'il suffit d'ouvrir pour que le modem se reconnecte. Depuis un conteneur, cela se fait avec le même curl. Un schéma utile : un petit service séparé dans Compose, qui déclenche le lien de rotation selon un planning. Il ne doit pas passer par le proxy (sinon, après le changement d'IP, il perdra lui-même la connexion), donc lancez-le sans variables de proxy ou avec HTTP_PROXY explicitement vide. Notez qu'après le changement d'IP, les connexions actives des conteneurs de travail seront rompues : prévoyez des tentatives de reconnexion dans les parseurs.

Santé de la passerelle : healthcheck

Ajoutez dans Compose une vérification que la passerelle fait bien office de proxy, et pas seulement qu'elle est lancée :

healthcheck: test: ["CMD", "gost", "-V"] interval: 30s timeout: 10s retries: 3

C'est une vérification minimale de la vie du processus. Pour tester la véritable sortie Internet, mieux vaut un conteneur-moniteur séparé, qui fait une requête via la passerelle toutes les minutes et écrit le résultat dans un log ou envoie une notification. Si l'IP devient soudain celle du serveur, c'est une alerte : la passerelle est tombée et les conteneurs sont passés en direct. Le réseau interne de l'étape 6 protège justement contre ce scénario.

Stockage sécurisé des mots de passe

Le fichier .env est bien pour un travail local, mais sur un serveur avec plusieurs utilisateurs, il faut le protéger : chmod 600 .env, propriétaire — l'utilisateur depuis lequel Compose est lancé. Compose prend aussi en charge les secrets via la directive secrets, qui sont montés dans le conteneur sous forme de fichier dans /run/secrets/, et non en variable d'environnement. Gost ne lit pas le mot de passe directement depuis un fichier, mais vous pouvez écrire un petit script d'enrobage qui assemble la chaîne -F depuis le fichier secret au démarrage. Ainsi le mot de passe n'apparaîtra ni dans docker inspect, ni dans la sortie de docker compose config.

Plusieurs projets et une seule infrastructure proxy

Si vous avez plusieurs projets Compose et que les proxys sont partagés, sortez les passerelles dans un projet séparé avec un réseau externe : dedans, déclarez networks avec le paramètre name: proxynet, et dans les autres projets connectez-vous à elle en external: true. Les passerelles vivent alors indépendamment, et vous pouvez redémarrer les projets de travail autant que vous voulez sans toucher aux proxys.

Limitation du trafic

Le trafic mobile est généralement facturé, et un parseur qui s'emballe peut télécharger des dizaines de gigaoctets en une nuit. Au niveau Docker, il n'y a pas de quotas stricts sur le trafic, mais il existe des mesures indirectes : limitation de la fréquence des requêtes dans l'application elle-même, limite de durée de vie du conteneur via timeout dans la commande de lancement, et surveillance via docker stats, qui affiche les NET I/O de chaque conteneur en temps réel. Comparez régulièrement ces chiffres avec les statistiques de votre espace client chez le fournisseur.

Des logs sans secrets

Beaucoup d'applications affichent au démarrage les variables d'environnement dans le log, y compris HTTP_PROXY avec le mot de passe. Si les logs partent dans un système centralisé, le mot de passe y fuira. La passerelle résout aussi ce problème : dans les logs des conteneurs de travail, il n'y aura que gateway:8118.

Conseil : Renouvelez les mots de passe proxy une fois par trimestre et mettez à jour .env. Avec la passerelle, cela prend une minute : vous modifiez une ligne, faites docker compose up -d gateway, et tous les workers continuent de fonctionner sans redémarrage.

FAQ : questions fréquentes sur la configuration d'un proxy dans Docker

Faut-il redémarrer le conteneur pour appliquer de nouvelles variables de proxy ?

Oui. Les variables d'environnement sont définies au moment de la création du conteneur et ne peuvent pas être modifiées sur un conteneur en cours d'exécution. Arrêtez, supprimez et recréez le conteneur (dans Compose, c'est docker compose up -d --force-recreate nom_du_service). Si les redémarrages gênent, utilisez la passerelle : ses réglages peuvent être modifiés indépendamment.

Quelle différence entre configurer un proxy pour docker pull et pour l'application dans le conteneur ?

Ce sont deux niveaux différents. docker pull est exécuté par le démon, et pour lui le proxy se configure dans daemon.json ou via systemd. L'application dans le conteneur est un processus séparé avec son propre environnement ; pour elle, le proxy se configure par variables, par config.json du client ou par le réseau. L'un ne remplace pas l'autre.

Peut-on utiliser SOCKS5 au lieu d'un proxy HTTP dans les variables d'environnement ?

Oui, si l'application prend en charge SOCKS. curl, Python requests (avec le paquet PySocks installé), git le prennent en charge. apt et beaucoup d'autres non. La solution universelle : la passerelle gost, qui accepte HTTP en entrée et envoie en SOCKS5 en sortie : -L=http://:8118 -F=socks5://user:pass@host:port.

Comment vérifier quel proxy utilise un conteneur déjà lancé ?

Exécutez docker inspect -f '{{.Config.Env}}' nom_du_conteneur. Vous verrez toutes les variables d'environnement. Pour vérifier l'IP réelle, utilisez docker exec nom_du_conteneur curl -s ifconfig.me, si curl est présent dans le conteneur, ou wget -qO- ifconfig.me.

Pourquoi le proxy fonctionne-t-il dans Docker Desktop, alors que sur un serveur Linux les mêmes réglages ne fonctionnent pas ?

Docker Desktop applique les réglages de la fenêtre Proxies à la fois au démon et aux conteneurs. Sur Linux, ce sont deux endroits distincts : daemon.json pour le démon et ~/.docker/config.json pour les conteneurs. Vérifiez que vous avez configuré les deux si vous avez besoin des deux.

Comment configurer un proxy pour un seul domaine et laisser le reste en direct ?

Les variables d'environnement ne savent pas faire cela : elles fonctionnent selon le principe « tout via le proxy, sauf NO_PROXY ». Si vous avez besoin de la logique inverse, utilisez un fichier PAC côté application (les navigateurs le prennent en charge) ou des règles de routage dans gost, qui sait diriger le trafic vers différents canaux sortants selon les domaines.

Est-il sûr de stocker le mot de passe du proxy dans compose.yaml ?

Mieux vaut éviter. Gardez-le dans .env avec des droits 600 et insérez-le via ${NOM}. Ne commitez pas .env dans le dépôt. Pour les serveurs, utilisez la passerelle pour que le mot de passe soit à un seul endroit.

Que faire si le proxy mobile a changé d'IP et que les connexions dans les conteneurs ont été rompues ?

C'est un comportement normal lors d'une rotation. L'application doit savoir répéter les requêtes. Si la rotation se produit selon le planning du fournisseur, renseignez-vous sur l'intervalle et synchronisez avec lui les opérations lourdes. Si la rotation se fait via votre lien, appelez-le entre les lots de tâches, pas au milieu.

Ces réglages fonctionnent-ils sur Windows sans WSL2 ?

Docker Desktop sur Windows utilise WSL2 ou Hyper-V sous le capot, et toutes les commandes docker run et docker compose fonctionnent de la même manière depuis PowerShell. Seuls les chemins diffèrent : le fichier config.json se trouve dans C:\Users\NomUtilisateur\.docker\config.json, et les réglages du démon se font via la fenêtre Docker Desktop, pas en modifiant daemon.json à la main.

Combien de conteneurs peut-on faire passer par un seul proxy mobile ?

Techniquement, autant que vous voulez ; la seule limite est la bande passante du canal mobile et les limites du forfait. En pratique, pour les tâches avec des comptes, il est raisonnable de garder un proxy par entité logique (compte, projet, région), pour que le comportement paraisse naturel et qu'une erreur dans un conteneur n'affecte pas les autres.

Conclusion : ce que vous avez fait et vers quoi aller ensuite

Résumons. Vous avez vérifié le bon fonctionnement du proxy depuis l'hôte et compris le format de la chaîne de connexion. Vous avez configuré le proxy pour un conteneur individuel via les variables d'environnement et le fichier env-file. Vous avez rendu la transmission des variables automatique via le config.json du client. Vous avez compris comment et pourquoi configurer le proxy pour le démon Docker lui-même, de trois manières. Vous avez décrit plusieurs services avec différents proxys mobiles dans Docker Compose, en plaçant les secrets dans .env. Et enfin, vous avez construit une passerelle-conteneur avec réseau isolé — la solution la plus fiable pour la production, qui protège contre les fuites d'IP réelle, même si l'application ignore les variables.

Désormais, le proxy dans Docker n'est plus pour vous une boîte noire, mais trois niveaux clairs aux frontières nettes : démon, conteneur, réseau. Vous savez où chercher le problème si l'IP s'avère être la mauvaise, et vous savez le vérifier en une commande.

Que faire ensuite

1. Passez vos projets de travail au schéma passerelle + réseau interne. Commencez par un service non critique, vérifiez que tout fonctionne, puis étendez.
2. Ajoutez un conteneur-moniteur qui vérifie l'IP externe via la passerelle toutes les minutes et alerte si elle coïncide avec l'IP du serveur.
3. Configurez la rotation d'IP selon un planning adapté à vos tâches et apprenez aux applications à survivre aux coupures de connexion.
4. Mettez de l'ordre dans les secrets : .env en droits 600, aucun mot de passe dans compose.yaml ni dans le Dockerfile.

Vers quoi évoluer

L'étape logique suivante est de relier Docker aux navigateurs antidetect et aux outils de multi-comptes, où chaque profil correspond à son propre conteneur et à son propre proxy mobile. Une autre direction : l'automatisation via l'API du fournisseur — récupération de la liste des proxys, vérification de leur statut et rotation directement depuis vos services. Les deux sujets dépassent le cadre de ce guide, mais la base que vous venez de poser les rend nettement plus simples. Bonnes mises en route et des IP stables !