Configuration de proxy dans les conteneurs Docker : guide complet avec des exemples de code

Les conteneurs Docker nécessitent souvent un accès à des ressources externes via des proxies — pour le scraping, les tests depuis différentes régions ou le contournement des restrictions. Une mauvaise configuration des proxies entraîne des erreurs de connexion, des fuites de l'IP réelle et des pannes d'applications. Dans cet article, nous examinerons tous les moyens de configurer des proxies dans Docker : des variables d'environnement simples aux scénarios avancés avec docker-compose et des réseaux personnalisés.

Pourquoi utiliser des proxies dans les conteneurs Docker

Les conteneurs Docker sont utilisés dans divers scénarios où les proxies deviennent une nécessité. Examinons les principales tâches que les proxies résolvent dans les applications conteneurisées.

Scraping et collecte de données : Si vous exécutez des scrapers dans des conteneurs Docker pour collecter des données à partir de places de marché (Wildberries, Ozon), de réseaux sociaux ou de moteurs de recherche, les proxies protègent contre les blocages par IP. Les conteneurs permettent de mettre à l'échelle le scraping — en lançant 10 à 50 instances simultanément, chacune avec son propre proxy.

Tests depuis différentes régions : Lors du développement d'applications web ou d'API mobiles, il est souvent nécessaire de vérifier comment le service fonctionne depuis différents pays. Les conteneurs Docker avec des proxies de différentes géolocalisations permettent d'automatiser ces tests dans un pipeline CI/CD.

Automatisation et bots : Les conteneurs avec Selenium, Puppeteer ou Playwright pour l'automatisation des navigateurs nécessitent des proxies pour travailler avec plusieurs comptes. Chaque conteneur reçoit son propre proxy et un environnement isolé.

Contournement des restrictions d'entreprise : Dans certaines infrastructures, les conteneurs Docker doivent passer par un proxy d'entreprise pour accéder à Internet. Sans une configuration correcte, les conteneurs ne pourront pas télécharger de paquets ou accéder à des API externes.

Configuration de base via des variables d'environnement

Le moyen le plus simple de configurer un proxy dans un conteneur Docker est de passer des variables d'environnement lors du démarrage. Cette méthode fonctionne pour la plupart des applications qui respectent les variables standard HTTP_PROXY, HTTPS_PROXY et NO_PROXY.

Démarrer un conteneur avec un proxy via docker run :

docker run -d \
  -e HTTP_PROXY="http://username:password@proxy.example.com:8080" \
  -e HTTPS_PROXY="http://username:password@proxy.example.com:8080" \
  -e NO_PROXY="localhost,127.0.0.1,.local" \
  your-image:latest

Explication des paramètres :

• HTTP_PROXY — proxy pour les requêtes HTTP
• HTTPS_PROXY — proxy pour les requêtes HTTPS (utilisez http://, pas https://)
• NO_PROXY — liste des adresses qui ne doivent pas passer par le proxy

Exemple avec un proxy SOCKS5 :

docker run -d \
  -e HTTP_PROXY="socks5://username:password@proxy.example.com:1080" \
  -e HTTPS_PROXY="socks5://username:password@proxy.example.com:1080" \
  your-image:latest

Configuration du proxy pour le démon Docker (affecte tous les conteneurs) :

Si vous souhaitez que tous les conteneurs utilisent par défaut le proxy, configurez le démon Docker. Créez un fichier /etc/systemd/system/docker.service.d/http-proxy.conf :

[Service]
Environment="HTTP_PROXY=http://proxy.example.com:8080"
Environment="HTTPS_PROXY=http://proxy.example.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,.local"

Après les modifications, redémarrez Docker :

sudo systemctl daemon-reload
sudo systemctl restart docker

Configuration des proxies dans le Dockerfile

Lorsque vous construisez une image Docker qui doit télécharger des paquets via un proxy (par exemple, apt-get, pip, npm), vous devez configurer le proxy au moment de la construction. Docker prend en charge les arguments de build-time pour cela.

Exemple de Dockerfile avec support de proxy :

FROM python:3.11-slim

# Arguments pour le proxy (passés lors de la construction)
ARG HTTP_PROXY
ARG HTTPS_PROXY
ARG NO_PROXY

# Définition des variables d'environnement pour la construction
ENV HTTP_PROXY=${HTTP_PROXY}
ENV HTTPS_PROXY=${HTTPS_PROXY}
ENV NO_PROXY=${NO_PROXY}

# Installation des dépendances via le proxy
RUN apt-get update && apt-get install -y curl

# Installation des paquets Python
COPY requirements.txt .
RUN pip install --proxy ${HTTP_PROXY} -r requirements.txt

# Copie de l'application
COPY . /app
WORKDIR /app

# Suppression des variables de proxy pour le runtime (optionnel)
ENV HTTP_PROXY=
ENV HTTPS_PROXY=

CMD ["python", "app.py"]

Construction de l'image avec passage du proxy :

docker build \
  --build-arg HTTP_PROXY=http://proxy.example.com:8080 \
  --build-arg HTTPS_PROXY=http://proxy.example.com:8080 \
  --build-arg NO_PROXY=localhost,127.0.0.1 \
  -t my-app:latest .

Pour les applications Node.js (npm via un proxy) :

FROM node:18-alpine

ARG HTTP_PROXY
ARG HTTPS_PROXY

# Configuration de npm pour fonctionner via un proxy
RUN npm config set proxy ${HTTP_PROXY}
RUN npm config set https-proxy ${HTTPS_PROXY}

COPY package*.json ./
RUN npm install

# Nettoyage des paramètres de proxy pour npm
RUN npm config delete proxy
RUN npm config delete https-proxy

COPY . .
CMD ["node", "server.js"]

Configuration des proxies dans docker-compose.yml

Docker Compose simplifie la gestion des proxies pour les applications multi-conteneurs. Vous pouvez configurer des proxies globalement ou pour des services spécifiques.

Configuration de base avec proxy pour un service :

version: '3.8'

services:
  parser:
    image: python:3.11-slim
    environment:
      - HTTP_PROXY=http://username:password@proxy.example.com:8080
      - HTTPS_PROXY=http://username:password@proxy.example.com:8080
      - NO_PROXY=localhost,127.0.0.1,db
    volumes:
      - ./app:/app
    working_dir: /app
    command: python parser.py
    
  db:
    image: postgres:15
    # La base de données n'utilise pas de proxy
    environment:
      - POSTGRES_PASSWORD=secret

Utilisation d'un fichier .env pour stocker les credentials en toute sécurité :

Créez un fichier .env dans le répertoire avec docker-compose.yml :

PROXY_URL=http://username:password@proxy.example.com:8080
NO_PROXY=localhost,127.0.0.1

Référez-vous aux variables dans docker-compose.yml :

version: '3.8'

services:
  parser:
    image: python:3.11-slim
    environment:
      - HTTP_PROXY=${PROXY_URL}
      - HTTPS_PROXY=${PROXY_URL}
      - NO_PROXY=${NO_PROXY}
    volumes:
      - ./app:/app
    working_dir: /app
    command: python parser.py

Configuration du proxy pour la construction de l'image dans docker-compose :

version: '3.8'

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
      args:
        - HTTP_PROXY=${PROXY_URL}
        - HTTPS_PROXY=${PROXY_URL}
        - NO_PROXY=${NO_PROXY}
    environment:
      - HTTP_PROXY=${PROXY_URL}
      - HTTPS_PROXY=${PROXY_URL}
    ports:
      - "3000:3000"

Scalabilité avec différents proxies pour chaque instance :

Si vous devez exécuter plusieurs scrapers, chacun avec son propre proxy, utilisez des services séparés :

version: '3.8'

services:
  parser-1:
    image: my-parser:latest
    environment:
      - PROXY_URL=http://user:pass@proxy1.example.com:8080
    volumes:
      - ./data:/data
    
  parser-2:
    image: my-parser:latest
    environment:
      - PROXY_URL=http://user:pass@proxy2.example.com:8080
    volumes:
      - ./data:/data
    
  parser-3:
    image: my-parser:latest
    environment:
      - PROXY_URL=http://user:pass@proxy3.example.com:8080
    volumes:
      - ./data:/data

Configuration des proxies au niveau de l'application

Certaines applications ne prennent pas en charge les variables d'environnement standard HTTP_PROXY. Dans de tels cas, il est nécessaire de configurer le proxy dans le code de l'application ou dans les fichiers de configuration.

Python (bibliothèque requests) :

import os
import requests

# Obtention du proxy à partir de la variable d'environnement
proxy_url = os.getenv('PROXY_URL', 'http://proxy.example.com:8080')

proxies = {
    'http': proxy_url,
    'https': proxy_url
}

# Utilisation du proxy dans les requêtes
response = requests.get('https://api.example.com/data', proxies=proxies)
print(response.json())

# Pour un proxy SOCKS5, installez pip install requests[socks]
# proxies = {
#     'http': 'socks5://user:pass@proxy.example.com:1080',
#     'https': 'socks5://user:pass@proxy.example.com:1080'
# }

Python (aiohttp pour les requêtes asynchrones) :

import os
import aiohttp
import asyncio

async def fetch_with_proxy():
    proxy_url = os.getenv('PROXY_URL')
    
    async with aiohttp.ClientSession() as session:
        async with session.get(
            'https://api.example.com/data',
            proxy=proxy_url
        ) as response:
            data = await response.json()
            print(data)

asyncio.run(fetch_with_proxy())

Node.js (bibliothèque axios) :

const axios = require('axios');
const { HttpsProxyAgent } = require('https-proxy-agent');

const proxyUrl = process.env.PROXY_URL || 'http://proxy.example.com:8080';
const agent = new HttpsProxyAgent(proxyUrl);

axios.get('https://api.example.com/data', {
  httpsAgent: agent
})
.then(response => {
  console.log(response.data);
})
.catch(error => {
  console.error('Erreur :', error.message);
});

Node.js (module https intégré) :

const https = require('https');
const { HttpsProxyAgent } = require('https-proxy-agent');

const proxyUrl = process.env.PROXY_URL;
const agent = new HttpsProxyAgent(proxyUrl);

const options = {
  hostname: 'api.example.com',
  port: 443,
  path: '/data',
  method: 'GET',
  agent: agent
};

const req = https.request(options, (res) => {
  let data = '';
  res.on('data', (chunk) => data += chunk);
  res.on('end', () => console.log(JSON.parse(data)));
});

req.on('error', (error) => console.error(error));
req.end();

Selenium avec proxy dans un conteneur Docker :

from selenium import webdriver
from selenium.webdriver.common.proxy import Proxy, ProxyType
import os

proxy_url = os.getenv('PROXY_URL', 'proxy.example.com:8080')

# Configuration du proxy pour Chrome
chrome_options = webdriver.ChromeOptions()
chrome_options.add_argument(f'--proxy-server={proxy_url}')

# Pour l'authentification, utilisez une extension ou un tunnel SSH
driver = webdriver.Chrome(options=chrome_options)
driver.get('https://example.com')
print(driver.title)
driver.quit()

Puppeteer avec proxy :

const puppeteer = require('puppeteer');

(async () => {
  const proxyUrl = process.env.PROXY_URL || 'proxy.example.com:8080';
  
  const browser = await puppeteer.launch({
    args: [`--proxy-server=${proxyUrl}`],
    headless: true
  });
  
  const page = await browser.newPage();
  
  // Authentification pour le proxy
  await page.authenticate({
    username: 'your-username',
    password: 'your-password'
  });
  
  await page.goto('https://example.com');
  console.log(await page.title());
  
  await browser.close();
})();

Quel type de proxy choisir pour Docker

Le choix du type de proxy dépend de la tâche que votre application doit accomplir dans le conteneur Docker. Examinons les principaux scénarios et recommandations.

Recommandations pour le choix en fonction des tâches spécifiques :

Scraping de places de marché et de catalogues de produits : Si vous scrapez Wildberries, Ozon ou d'autres places de marché via des conteneurs Docker, utilisez des proxies résidentiels. Ces plateformes bloquent activement les IP des datacenters. Configurez la rotation des proxies toutes les 5 à 10 minutes pour simuler différents utilisateurs.

Tests d'API et développement : Pour tester vos propres API ou intégrations avec des services externes, des proxies de datacenter conviennent. Ils offrent une haute vitesse et une stabilité de connexion, ce qui est important pour les tests automatisés dans CI/CD.

Automatisation Selenium/Puppeteer : Lors du lancement de l'automatisation des navigateurs dans des conteneurs pour travailler avec des sites sécurisés (réseaux sociaux, banques, applications web complexes), choisissez des proxies résidentiels. Ils réduisent la probabilité de captchas et de blocages.

Tests géodistribués : Si vous devez vérifier l'accessibilité d'un service depuis différents pays, utilisez des proxies résidentiels avec un choix de géolocalisation spécifique. Lancez plusieurs conteneurs Docker, chacun avec un proxy de son pays.

Résolution des problèmes courants

Lors de l'utilisation de proxies dans des conteneurs Docker, des problèmes typiques peuvent survenir. Examinons les plus fréquents et les solutions possibles.

Problème 1 : Le conteneur ne peut pas se connecter au proxy

Symptômes : Erreurs "Connection refused", "Proxy connection failed", délais d'attente lors du démarrage du conteneur.

Solutions :

• Vérifiez l'accessibilité du proxy depuis l'hôte : curl -x http://proxy:port https://example.com
• Assurez-vous que le serveur proxy est accessible depuis le réseau Docker. Si le proxy est sur localhost de l'hôte, utilisez host.docker.internal (Mac/Windows) ou l'IP de l'hôte dans le réseau bridge
• Vérifiez les règles du pare-feu — les conteneurs Docker peuvent être bloqués pour les connexions sortantes
• Pour les proxies avec authentification, vérifiez la validité du nom d'utilisateur et du mot de passe, échappez les caractères spéciaux dans l'URL

Exemple d'accès au proxy sur l'hôte :

# Mac/Windows
docker run -e HTTP_PROXY=http://host.docker.internal:8080 my-image

# Linux (déterminez l'IP de l'hôte dans le réseau bridge)
ip addr show docker0  # Généralement 172.17.0.1
docker run -e HTTP_PROXY=http://172.17.0.1:8080 my-image

Problème 2 : DNS ne se résout pas via le proxy

Symptômes : Erreurs "Could not resolve host", les requêtes DNS ne passent pas par le proxy.

Solutions :

• Utilisez un proxy SOCKS5 au lieu de HTTP — SOCKS5 proxy les requêtes DNS
• Configurez DNS dans Docker : ajoutez --dns 8.8.8.8 lors du démarrage du conteneur
• Pour les applications qui ne prennent pas en charge DNS via le proxy, utilisez proxychains à l'intérieur du conteneur

# Dockerfile avec proxychains
FROM python:3.11-slim

RUN apt-get update && apt-get install -y proxychains4

# Configuration de proxychains
RUN echo "strict_chain\nproxy_dns\n[ProxyList]\nsocks5 proxy.example.com 1080" > /etc/proxychains4.conf

# Lancement de l'application via proxychains
CMD ["proxychains4", "python", "app.py"]

Problème 3 : Fuite de l'IP réelle du conteneur

Symptômes : Le service cible voit l'IP de l'hôte ou du conteneur au lieu de l'IP du proxy.

Solutions :

• Vérifiez que l'application utilise bien le proxy — faites une requête à https://api.ipify.org
• Assurez-vous que tous les clients HTTP dans le code sont configurés pour utiliser le proxy
• Pour les connexions WebRTC et WebSocket, le proxy peut ne pas fonctionner — désactivez WebRTC dans les navigateurs
• Vérifiez les en-têtes des requêtes — certaines bibliothèques ajoutent X-Forwarded-For avec l'IP réelle

Test de fuite d'IP dans le conteneur :

# Sans proxy
docker run --rm curlimages/curl:latest curl https://api.ipify.org

# Avec proxy
docker run --rm \
  -e HTTPS_PROXY=http://proxy.example.com:8080 \
  curlimages/curl:latest curl https://api.ipify.org

Problème 4 : Fonctionnement lent via le proxy

Symptômes : Retards élevés, délais d'attente, chargement lent des données.

Solutions :

• Vérifiez la vitesse du proxy directement depuis l'hôte — le problème peut venir du proxy lui-même
• Augmentez les délais d'attente dans l'application pour travailler avec des proxies lents
• Utilisez des connexions keep-alive pour réutiliser les connexions TCP
• Pour les proxies résidentiels, une vitesse lente est normale, optimisez le nombre de requêtes
• Configurez un pool de connexions dans les clients HTTP pour des requêtes parallèles

Problème 5 : Le proxy fonctionne pour HTTP, mais pas pour HTTPS

Symptômes : Les requêtes HTTP passent, les HTTPS renvoient des erreurs SSL/TLS.

Solutions :

• Assurez-vous que la variable HTTPS_PROXY est définie (pas seulement HTTP_PROXY)
• Utilisez http:// dans l'URL du proxy pour HTTPS_PROXY, pas https://
• Vérifiez si le proxy prend en charge la méthode CONNECT pour le tunneling HTTPS
• Pour les proxies avec des certificats auto-signés, désactivez la vérification SSL (uniquement pour les tests !)

Sécurité et gestion des credentials

Le stockage des credentials de proxy dans des conteneurs Docker nécessite une attention particulière à la sécurité. Une mauvaise gestion des mots de passe peut entraîner leur fuite dans les logs, les images ou les dépôts.

Utilisez Docker Secrets pour la production :

Docker Swarm prend en charge le mécanisme des secrets pour le stockage sécurisé des mots de passe. Créez un secret :

echo "http://username:password@proxy.example.com:8080" | docker secret create proxy_url -

Utilisez-le dans docker-compose pour Swarm :

version: '3.8'

services:
  app:
    image: my-app:latest
    secrets:
      - proxy_url
    environment:
      - PROXY_URL_FILE=/run/secrets/proxy_url
    command: sh -c 'export HTTP_PROXY=$(cat $$PROXY_URL_FILE) && python app.py'

secrets:
  proxy_url:
    external: true

Variables d'environnement via des fichiers (.env) :

Pour le développement, utilisez des fichiers .env, mais NE LES COMMITEZ JAMAIS dans Git. Ajoutez-les à .gitignore :

# .gitignore
.env
.env.local
*.env

Créez .env.example sans credentials réels :

# .env.example
PROXY_URL=http://username:password@proxy.example.com:8080
NO_PROXY=localhost,127.0.0.1

Évitez de hardcoder les credentials dans les images :

# ❌ MAUVAIS - le mot de passe restera dans l'image
FROM python:3.11
ENV HTTP_PROXY=http://user:secretpass@proxy.com:8080
COPY . /app

# ✅ BON - passez par des arguments de construction ou des variables runtime
FROM python:3.11
ARG HTTP_PROXY
# Utilisé uniquement pendant la construction, non conservé dans l'image finale

Utilisez des constructions multi-étapes pour nettoyer les credentials :

# Étape de construction avec proxy
FROM python:3.11 AS builder
ARG HTTP_PROXY
ENV HTTP_PROXY=${HTTP_PROXY}
COPY requirements.txt .
RUN pip install -r requirements.txt

# Étape finale sans variables de proxy
FROM python:3.11-slim
COPY --from=builder /usr/local/lib/python3.11/site-packages /usr/local/lib/python3.11/site-packages
COPY . /app
WORKDIR /app
CMD ["python", "app.py"]

Rotation des credentials de proxy :

Si votre fournisseur de proxy prend en charge une API pour générer des credentials temporaires, utilisez-les au lieu de mots de passe statiques. Créez un script d'initialisation dans le conteneur :

#!/bin/bash
# entrypoint.sh

# Obtention des credentials temporaires depuis l'API
PROXY_CREDS=$(curl -s https://api.proxyservice.com/generate-temp-auth)
export HTTP_PROXY="http://${PROXY_CREDS}@proxy.example.com:8080"

# Lancement de l'application
exec python app.py

Journalisation sans fuite de mots de passe :

Configurez la journalisation de manière à ce que les variables de proxy ne soient pas affichées dans la sortie :

import os
import re

def safe_log_env():
    """Journalisation des variables d'environnement sans mots de passe"""
    for key, value in os.environ.items():
        if 'PROXY' in key:
            # Masquer le mot de passe dans l'URL
            safe_value = re.sub(r'://([^:]+):([^@]+)@', r'://\1:****@', value)
            print(f"{key}={safe_value}")
        else:
            print(f"{key}={value}")

safe_log_env()

Conclusion

La configuration des proxies dans des conteneurs Docker est une compétence importante pour les développeurs travaillant avec le scraping, l'automatisation et les systèmes distribués. Vous avez appris à configurer des proxies via des variables d'environnement, Dockerfile et docker-compose, comment intégrer des proxies dans le code des applications en Python et Node.js, et comment résoudre les problèmes typiques de connexion et de sécurité.

Les points clés pour réussir à travailler avec des proxies dans Docker : utilisez des variables d'environnement pour la flexibilité, stockez les credentials en toute sécurité via des secrets ou des fichiers .env, choisissez le type de proxy en fonction de la tâche, et testez toujours l'absence de fuites de l'IP réelle avant de passer en production.

Pour la plupart des tâches de scraping et d'automatisation dans des conteneurs Docker, nous vous recommandons d'utiliser des proxies résidentiels — ils offrent une grande anonymité et un risque minimal de blocage lors de l'accès à des sites et API sécurisés. Si vous avez besoin d'une vitesse maximale pour les tests d'API ou des tâches internes, envisagez des proxies de datacenter.