Balansowanie proxy dla n8n w Docker: eliminacja błędów DNS

Odporna na awarie równoważenie proxy dla n8n w Docker: eliminacja timeoutów DNS i błędów dostępu

Praca n8n poprzez pojedynczy proxy to architekturalna słabość. W przypadku zablokowania IP lub awarii serwera proxy wszystkie workflowy zatrzymują się. Jedynym niezawodnym rozwiązaniem jest wdrożenie puli proxy z automatycznym przełączaniem i równoważeniem round-robin. W tym artykule znajdziesz instrukcję krok po kroku konfiguracji 3proxy w stacku Docker, poprawki krytycznych błędów DNS i uprawnień dostępu oraz metody weryfikacji działania całego łańcucha.

Architektura odpornego na awarie puli proxy

Zamiast bezpośredniego łączenia n8n z Telegramem lub innymi zewnętrznymi API, wprowadzamy lokalny kontener 3proxy działający jako brama. Przyjmuje on żądania HTTP/HTTPS od n8n na porcie 3128 i rozdziela je na wcześniej zdefiniowaną listę zewnętrznych proxy SOCKS5. Główne zalety:

• Automatyczne odzyskiwanie: w razie niedostępności jednego z węzłów ruch jest natychmiast przekierowywany na następny działający proxy.
• Przejrzystość dla n8n: workflowy nie wymagają zmian — wystarczy podać jeden adres proxy w zmiennych środowiskowych.
• Ochrona przed wyciekiem IP: jeśli wszystkie zewnętrzne proxy są niedostępne, połączenie jest przymusowo zamykane, co zapobiega wyjściu ruchu pod prawdziwym IP serwera.

Konfiguracja realizowana jest za pomocą docker-compose, gdzie oba serwisy (n8n i 3proxy) znajdują się w jednej niestandardowej sieci. Zapewnia to stabilną wewnętrzną routetyzację bez potrzeby forwardowania portów na hoście.

Konfiguracja docker-compose.yml i pliku konfiguracyjnego 3proxy

Zacznijmy od podstawowego stacka. Zwróć uwagę na parametr user: "0:0" — jest on niezbędny do poprawnego działania 3proxy w kontenerze, ponieważ procesowi potrzebne są uprawnienia do otwierania portów sieciowych i odczytu konfiguracji z wolumenu.

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

Główna logika równoważenia jest zdefiniowana w pliku 3proxy.cfg. Poniżej znajdziesz minimalną działającą konfigurację z komentarzami:

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

# Ispolzuem DNS rezolver Docker, and not vneshniy (for example, 8.8.8.8)
nserver 127.0.0.11
nscache 65536
timeouts 1 5 30 60 180 1800 15 60

# Akaktywatsiya ACL — bez etogo parent-chains ignoriruyutsya
auth iponly

# Razreshenie must be TO obyavleniya parent
allow *

# Pul vneshnikh wytyczsi (round-robin)
parent 1000 socks5 IP_PROKWithI_1 PORT_1 LOGIN_1 PAROL_1
parent 1000 socks5 IP_PROKWithI_2 PORT_2 LOGIN_2 PAROL_2
parent 1000 socks5 IP_PROKWithI_3 PORT_3 LOGIN_3 PAROL_3

# Zapreschaem directlyy output, if all wytyczsi nedostupny
deny * * 0.0.0.0/0

# Run HTTP-wytyczsi on portu 3128
proxy -p3128 -a
flush

Diagnostyka i eliminacja typowych błędów

Przy pierwszym uruchomieniu pojawiają się trzy częste problemy. Ich rozwiązanie to klucz do stabilnego działania systemu.

Błąd 1: Timeouty DNS (26 sekund na żądanie)

Objawy: n8n zawiesza się na każdym żądaniu dokładnie przez 26 sekund, po czym albo otrzymuje odpowiedź, albo kończy się timeoutem.

Przyczyna: W konfiguracji podano zewnętrzny serwer DNS (np. nserver 8.8.8.8), ale kontener 3proxy nie ma bezpośredniego dostępu do internetu poza siecią użytkownika Docker. Żądania DNS idą w próżnię i czekają na timeout.

Rozwiązanie: Zastąpić DNS wewnętrznym resolverem Docker — nserver 127.0.0.11. Ten adres jest zawsze dostępny w każdym kontenerze i deleguje żądania do systemu hosta.

Błąd 2: Permission denied przy starcie kontenera

Objawy: Kontener 3proxy kończy pracę natychmiast po starcie, w logach komunikaty o niemożności otwarcia portu lub odczytania konfiguracji.

Przyczyna: Oficjalny obraz 3proxy domyślnie uruchamia się od nieuprzywilejowanego użytkownika, któremu zabroniono pracy z portami poniżej 1024 i montowanymi wolumenami.

Rozwiązanie: Wyraźnie wskazać user: "0:0" w docker-compose dla serwisu 3proxy. Uruchamia to proces jako root w izolowanym namespace kontenera — bezpiecznie, ponieważ sieć jest ograniczona.

Błąd 3: Ruch idzie bezpośrednio, omijając pulę proxy

Objawy: n8n działa, ale przy sprawdzaniu wychodzącego IP widać prawdziwy adres serwera, a nie proxy. Balancer ignoruje dyrektywy parent.

Przyczyny i rozwiązania:

• Nieprawidłowa kolejność dyrektyw: allow * musi stać ściśle przed pierwszym parent, w przeciwnym razie parser zgłasza błąd Chaining error i wyłącza łańcuch.
• Wyłączony ACL: Dyrektywa auth none całkowicie wyłącza mechanizm kontroli dostępu, co psuje logikę forwardingu. Użyj auth iponly.
• Brak ochrony fallback: Bez deny 0.0.0.0/0 system może "przeciec" bezpośrednio na zewnątrz przy całkowitej awarii puli. Ta linia gwarantuje, że jeśli wszystkie proxy są martwe — połączenie zostanie zerwane, a nie przekierowane na domyślną trasę.

Metody weryfikacji działania systemu

Po konfiguracji trzeba upewnić się, że ruch rzeczywiście przechodzi przez balancer i pulę proxy. Do tego użyj dwóch poziomów sprawdzenia:

• Sprawdzenie logów 3proxy:

```

docker compose logs --tail 20 3proxy

```

Szukaj wpisów w stylu [NNN] CONNECT ... — potwierdzają one, że żądania są przyjmowane i przekierowywane. Jeśli widzisz Permission denied — wróć do ustawienia user: "0:0".

• Sprawdzenie end-to-end z n8n:

```

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

```

Oczekiwany wynik — kod HTTP 200 OK i wyświetlone nagłówki. Jeśli komenda się zawiesza — problem z DNS (nserver). Jeśli zwraca Connection refused — sprawdź, czy 3proxy jest uruchomiony i czy port 3128 jest otwarty.

Dodatkowo w konfiguracji 3proxy możesz dodać linię logrotate 1000000 5 — aktywuje to rotację logów według rozmiaru, zapobiegając zapełnieniu dysku.

Co ważne

• DNS w Dockerze zawsze musi wskazywać na 127.0.0.11, inaczej wystąpią 26-sekundowe timeouty.
• Uprawnienia użytkownika w kontenerze są kluczowe: bez user: "0:0" 3proxy nie otworzy portu 3128.
• Kolejność dyrektyw w konfiguracji 3proxy wpływa na działanie: allow * przed parent, auth iponly zamiast none.
• Ochrona przed wyciekiem IP jest obowiązkowa: dyrektywa deny 0.0.0.0/0 zapobiega bezpośredniemu wyjściu ruchu przy awarii wszystkich proxy.
• Równoważenie round-robin jest wbudowane w 3proxy — nie wymaga dodatkowych narzędzi ani skryptów.

Skonfigurowany system zapewnia bezprzerwową pracę n8n nawet przy częściowej awarii infrastruktury. Wszystkie zmiany są przezroczyste dla workflowów — wystarczy raz podać lokalny proxy, a dalsza routetyzacja odbywa się automatycznie.

— Editorial Team