Proxy-Balancing für n8n in Docker: Behebung von DNS-Fehlern

# Fehlertolerantes Proxy-Load-Balancing für n8n in Docker: Behebung von DNS-Timeouts und Zugriffsfehlern

Das Ausführen von n8n über einen einzelnen Proxy ist eine architektonische Schwachstelle. Wenn die IP blockiert wird oder der Proxy-Server ausfällt, kommen alle Workflows zum Stillstand. Die einzige zuverlässige Lösung ist der Einsatz eines Pools von Proxys mit automatischem Failover und Round-Robin-Balancing. Diese Anleitung führt Sie Schritt für Schritt durch die Einrichtung von 3proxy in einem Docker-Stack, behebt kritische DNS-Fehler und Berechtigungsprobleme und überprüft die Zuverlässigkeit der gesamten Kette.

Fehlertolerante Proxy-Pool-Architektur

Statt n8n direkt mit Telegram oder anderen externen APIs zu verbinden, schalten wir einen lokalen 3proxy-Container als Gateway dazwischen. Er bearbeitet HTTP/HTTPS-Anfragen von n8n auf Port 3128 und verteilt sie auf eine vordefinierte Liste externer SOCKS5-Proxys. Wichtige Vorteile:

• Automatisches Failover: Wenn ein Knoten ausfällt, wird der Traffic sofort auf den nächsten verfügbaren Proxy umgeleitet.
• Transparenz für n8n: Keine Änderungen an Workflows nötig – einfach eine einzige Proxy-Adresse in den Umgebungsvariablen setzen.
• Schutz vor IP-Lecks: Wenn alle externen Proxys ausfallen, werden Verbindungen zwangsweise getrennt, um ein Auslaufen des Traffics über die echte Server-IP zu verhindern.

Die Einrichtung verwendet docker-compose mit beiden Diensten (n8n und 3proxy) in einem benutzerdefinierten Netzwerk. So ist eine stabile interne Weiterleitung ohne Freigabe von Ports am Host gewährleistet.

Einrichtung von docker-compose.yml und der 3proxy-Konfigurationsdatei

Beginnen Sie mit diesem grundlegenden Stack. Beachten Sie den Parameter user: "0:0" – er ist essenziell, damit 3proxy im Container funktioniert, da der Prozess Berechtigungen zum Binden von Netzwerkports und Lesen der Konfig aus Volumes benötigt.

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

Die Kernlogik für das Balancing kommt in 3proxy.cfg. Hier eine minimale, funktionierende Konfiguration mit Kommentaren:

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

Diagnose und Behebung gängiger Fehler

Beim ersten Start stoßen Sie auf drei typische Probleme. Ihre Lösung ist entscheidend für ein stabiles System.

Fehler 1: DNS-Timeouts (26 Sekunden pro Anfrage)

Symptome: n8n hängt bei jeder Anfrage exakt 26 Sekunden, dann erfolgt entweder eine Antwort oder ein Timeout.

Ursache: Die Konfig zeigt auf einen externen DNS-Server (z. B. nserver 8.8.8.8), aber der 3proxy-Container kann außerhalb des Docker-Custom-Netzwerks kein Internet erreichen. DNS-Abfragen gehen ins Leere und warten auf Timeout.

Lösung: Wechseln Sie zum internen Docker-Resolver mit nserver 127.0.0.11. Diese Adresse ist in jedem Container immer verfügbar und leitet Abfragen an das Host-System weiter.

Fehler 2: Berechtigung verweigert beim Container-Start

Symptome: Der 3proxy-Container stürzt direkt nach dem Start ab, Logs zeigen Unfähigkeit, Ports zu binden oder die Konfig zu lesen.

Ursache: Das offizielle 3proxy-Image läuft standardmäßig als nicht privilegiertes Benutzerkonto, das keine Ports unter 1024 binden oder gemountete Volumes erreichen kann.

Lösung: Setzen Sie explizit user: "0:0" in docker-compose für den 3proxy-Dienst. Dadurch läuft der Prozess als root im isolierten Namensraum des Containers – sicher, da das Netzwerk eingeschränkt ist.

Fehler 3: Traffic umgeht den Proxy-Pool

Symptome: n8n funktioniert, aber IP-Checks nach außen zeigen die echte Server-Adresse statt eines Proxys. Der Balancer ignoriert parent-Direktiven.

Ursachen und Lösungen:

• Falsche Reihenfolge der Direktiven: allow * muss strikt vor dem ersten parent stehen, sonst wirft der Parser einen Chaining error und deaktiviert Chaining.
• ACL deaktiviert: auth none schaltet die Zugriffssteuerung komplett aus und zerstört die Weiterleitungslogik. Verwenden Sie stattdessen auth iponly.
• Kein Fallback-Schutz: Ohne deny 0.0.0.0/0 kann das System bei Ausfall des gesamten Pools direkten Traffic durchleiten. Diese Zeile sorgt dafür, dass Verbindungen unterbrochen werden, statt auf die Standardroute auszuweichen.

Überprüfung der Systemfunktionalität

Nach der Einrichtung prüfen Sie, ob der Traffic durch den Balancer und den Proxy-Pool fließt. Nutzen Sie diese zwei Tests:

• 3proxy-Logs prüfen:

```

docker compose logs --tail 20 3proxy

```

Suchen Sie nach Einträgen wie [NNN] CONNECT ... – sie bestätigen, dass Anfragen angenommen und weitergeleitet werden. Bei Permission denied nochmals user: "0:0" überprüfen.

• End-to-End-Test von n8n aus:

```

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

```

Erwarten Sie HTTP 200 OK und Header. Bei Hängen liegt es an DNS (nserver). Bei Connection refused prüfen, ob 3proxy läuft und Port 3128 offen ist.

Optional: Fügen Sie logrotate 1000000 5 zur 3proxy-Konfig hinzu, für größenbasierte Log-Rotation, um die Festplatte nicht zu überfüllen.

Wichtige Erkenntnisse

• Docker-DNS muss immer auf 127.0.0.11 zeigen, sonst gibt es 26-Sekunden-Timeouts.
• Container-Benutzerberechtigungen sind entscheidend: Ohne user: "0:0" kann 3proxy Port 3128 nicht binden.
• Reihenfolge der Direktiven in der 3proxy-Konfig zählt: allow * vor parent, auth iponly statt none.
• IP-Leak-Schutz ist essenziell: deny 0.0.0.0/0 blockiert direkten Traffic bei vollständigem Proxy-Ausfall.
• Round-Robin-Balancing ist in 3proxy integriert – keine extra Tools oder Skripte nötig.

Diese Einrichtung hält n8n auch bei teilweisen Infrastruktur-Ausfällen am Laufen. Änderungen sind für Workflows transparent – einmal auf den lokalen Proxy zeigen, und die Weiterleitung erledigt den Rest automatisch.

— Editorial Team