Équilibrage de proxy pour n8n dans Docker : correction des erreurs DNS

Équilibrage de charge tolérant aux pannes de proxy pour n8n dans Docker : Résolution des timeouts DNS et erreurs d'accès

Exécuter n8n via un seul proxy représente une vulnérabilité architecturale. Si l'IP est bloquée ou si le serveur proxy tombe en panne, tous les workflows s'arrêtent net. La seule solution fiable consiste à déployer un pool de proxies avec basculement automatique et équilibrage round-robin. Ce guide vous guide pas à pas dans la configuration de 3proxy dans une pile Docker, résolvant les erreurs DNS critiques et les problèmes de permissions, et vérifiant la fiabilité de la chaîne complète.

Architecture de pool de proxies tolérant aux pannes

Au lieu de connecter n8n directement à Telegram ou d'autres API externes, nous insérons un conteneur local 3proxy agissant comme une passerelle. Il gère les requêtes HTTP/HTTPS de n8n sur le port 3128 et les distribue sur une liste prédéfinie de proxies SOCKS5 externes. Avantages clés :

• Basculement automatique : Si un nœud tombe en panne, le trafic bascule instantanément vers le proxy disponible suivant.
• Transparence pour n8n : Aucune modification des workflows nécessaire — il suffit de définir une seule adresse de proxy dans les variables d'environnement.
• Protection contre les fuites d'IP : Si tous les proxies externes échouent, les connexions sont forcées à se fermer, empêchant le trafic de fuiter via l'IP réelle du serveur.

La configuration utilise docker-compose, avec les deux services (n8n et 3proxy) dans un réseau personnalisé. Cela garantit un routage interne stable sans exposer les ports sur l'hôte.

Configuration de docker-compose.yml et du fichier de configuration 3proxy

Commencez par cette pile de base. Notez le paramètre user: "0:0" — il est essentiel pour que 3proxy fonctionne dans le conteneur, car le processus a besoin de privilèges pour lier les ports réseau et lire la configuration depuis les volumes.

version: '3.8'

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    container_name: n8n
    environment:
      - HTTP_PROXY=http://3proxy:3128
      - HTTPS_PROXY=http://3proxy:3128
      - http_proxy=http://3proxy:3128
      - https_proxy=http://3proxy:3128
    networks:
      - n8n_net

  3proxy:
    image: ghcr.io/z3apa3a/3proxy:latest
    container_name: 3proxy
    restart: always
    user: "0:0"
    volumes:
      - ./3proxy.cfg:/etc/3proxy/3proxy.cfg
    networks:
      - n8n_net

networks:
  n8n_net:
    name: n8n_net

La logique d'équilibrage principale va dans 3proxy.cfg. Voici une configuration minimale fonctionnelle avec commentaires :

daemon
log /var/log/3proxy.log D
logformat "L%t.%. %N.%p %E %U %C:%c %R:%r %O %I %h %T"

# Use Docker's DNS resolver, not an external one (e.g., 8.8.8.8)
nserver 127.0.0.11
nscache 65536
timeouts 1 5 30 60 180 1800 15 60

# Enable ACL — without this, parent chains are ignored
auth iponly

# Allow must come BEFORE declaring parent
allow *

# Pool of external proxies (round-robin)
parent 1000 socks5 IP_PROXY_1 PORT_1 LOGIN_1 PASS_1
parent 1000 socks5 IP_PROXY_2 PORT_2 LOGIN_2 PASS_2
parent 1000 socks5 IP_PROXY_3 PORT_3 LOGIN_3 PASS_3

# Deny direct outbound if all proxies are unavailable
deny * * 0.0.0.0/0

# Launch HTTP proxy on port 3128
proxy -p3128 -a
flush

Diagnostic et correction des erreurs courantes

Au premier lancement, vous rencontrerez trois problèmes typiques. Les résoudre est clé pour un système stable.

Erreur 1 : Timeouts DNS (26 secondes par requête)

Symptômes : n8n bloque sur chaque requête pendant exactement 26 secondes, puis obtient une réponse ou expire.

Cause : La configuration pointe vers un serveur DNS externe (par ex., nserver 8.8.8.8), mais le conteneur 3proxy ne peut pas atteindre Internet en dehors du réseau personnalisé de Docker. Les requêtes DNS n'aboutissent nulle part et attendent l'expiration.

Correction : Passez au résolveur DNS interne de Docker avec nserver 127.0.0.11. Cette adresse est toujours disponible dans n'importe quel conteneur et transfère les requêtes vers le système hôte.

Erreur 2 : Permission refusée au démarrage du conteneur

Symptômes : Le conteneur 3proxy plante juste après le démarrage, avec des logs indiquant l'impossibilité de lier les ports ou de lire la configuration.

Cause : L'image officielle 3proxy s'exécute par défaut sous un utilisateur non privilégié, qui ne peut pas lier les ports inférieurs à 1024 ni accéder aux volumes montés.

Correction : Définissez explicitement user: "0:0" dans docker-compose pour le service 3proxy. Cela exécute le processus en root dans l'espace de noms isolé du conteneur — sûr car le réseau est restreint.

Erreur 3 : Trafic contournant le pool de proxies

Symptômes : n8n fonctionne, mais les vérifications d'IP sortante montrent l'adresse réelle du serveur, pas celle d'un proxy. L'équilibreur ignore les directives parent.

Causes et corrections :

• Ordre de directives incorrect : allow * doit venir strictement avant le premier parent, sinon l'analyseur génère une Chaining error et désactive le chaînage.
• ACL désactivée : auth none désactive complètement le contrôle d'accès, cassant la logique de redirection. Utilisez auth iponly à la place.
• Aucune protection de repli : Sans deny 0.0.0.0/0, le système peut laisser fuiter du trafic direct si tout le pool échoue. Cette ligne assure que les connexions se ferment plutôt que de retomber sur la route par défaut.

Vérification du fonctionnement du système

Une fois configuré, confirmez que le trafic passe par l'équilibreur et le pool de proxies. Utilisez ces deux vérifications :

• Vérifiez les logs 3proxy :

```

docker compose logs --tail 20 3proxy

```

Recherchez des entrées comme [NNN] CONNECT ... — elles confirment que les requêtes sont acceptées et redirigées. Si vous voyez Permission denied, revérifiez le paramètre user: "0:0".

• Test de bout en bout depuis n8n :

```

docker compose exec n8n curl -Ivx http://3proxy:3128 https://api.telegram.org

```

Attendez un HTTP 200 OK et des en-têtes. S'il bloque, c'est un problème DNS (nserver). Si Connection refused, assurez-vous que 3proxy tourne et que le port 3128 est ouvert.

Optionnellement, ajoutez logrotate 1000000 5 à la configuration 3proxy pour une rotation des logs basée sur la taille et éviter de remplir le disque.

Points clés à retenir

• Le DNS Docker doit toujours pointer vers 127.0.0.11, sinon vous obtiendrez des timeouts de 26 secondes.
• Les permissions utilisateur du conteneur sont critiques : Sans user: "0:0", 3proxy ne peut pas lier le port 3128.
• L'ordre des directives dans la configuration 3proxy compte : allow * avant parent, auth iponly plutôt que none.
• La protection contre les fuites d'IP est essentielle : deny 0.0.0.0/0 bloque le trafic direct en cas d'échec total des proxies.
• L'équilibrage round-robin est intégré à 3proxy — aucun outil ou script supplémentaire nécessaire.

Cette configuration maintient n8n opérationnel même en cas de pannes partielles d'infrastructure. Les changements sont transparents pour les workflows — pointez une seule fois vers le proxy local, et le routage gère le reste automatiquement.

— Editorial Team