Jak skonfigurować proxy w n8n

Instrukcja krok po kroku, jak podłączyć proxy Prokso w n8n. Zajmie Ci to kilka minut.

Krok 1. Pobierz dane proxy z panelu klienta

Otwórz swój plan i skopiuj host gw.prokso.com, port, login i hasło. Port 823 to HTTP, a 824 to SOCKS5 (oba dają nowy IP przy każdym żądaniu); porty 10000–20000 utrzymują jeden IP (stały IP) do 120 minut i działają zarówno jako HTTP, jak i SOCKS5 (każdy port to osobny adres). Kraj ustawisz w loginie: username__cr.ua.

Krok 2. Dodaj opcję Proxy do węzła HTTP Request

Otwórz workflow, dodaj węzeł HTTP Request i jak zwykle ustaw metodę oraz adres URL strony. W parametrach węzła kliknij Add Option i wybierz Proxy: pojawi się pole na adres proxy.

Krok 3. Wpisz adres URL proxy z danymi logowania

W polu Proxy wklej http://USERNAME:PASSWORD@gw.prokso.com:823, biorąc login i hasło z generatora w panelu klienta. Pole przyjmuje tylko adresy zaczynające się od http:// lub https://, więc SOCKS5 na porcie 824 tu nie zadziała: użyj portu 823 albo portu ze stałym IP z zakresu 10000-20000. Proxy działa tylko dla tego węzła; pozostałe węzły HTTP Request skonfiguruj osobno.

Krok 4. Ustaw tempo i limit czasu

Jeśli do węzła trafia wiele elementów, każdy z nich staje się osobnym żądaniem, a na porcie 823 każde dostaje nowy adres. Żeby nie zasypać strony żądaniami, dodaj opcję Batching: Items per Batch to liczba żądań w jednej partii, a Batch Interval to przerwa między partiami w milisekundach. Opcja Timeout określa, ile milisekund czekać na odpowiedź.

Krok 5. Proxy dla całego n8n na własnym serwerze

Jeśli n8n działa na Twoim serwerze, możesz ustawić proxy raz, za pomocą zmiennych środowiskowych: HTTP_PROXY dla stron http, HTTPS_PROXY dla stron https i ALL_PROXY jako wartość zapasową dla obu. Wtedy cały ruch HTTP z węzłów przechodzi przez proxy. Opcja Proxy w węźle ma pierwszeństwo przed tymi zmiennymi. Poniżej uruchomienie w Dockerze; po zmianie zmiennych uruchom kontener ponownie.

docker volume create n8n_data

docker run -it --rm \
  --name n8n \
  -p 5678:5678 \
  -e HTTP_PROXY=http://USERNAME:PASSWORD@gw.prokso.com:823 \
  -e HTTPS_PROXY=http://USERNAME:PASSWORD@gw.prokso.com:823 \
  -e NO_PROXY=localhost,127.0.0.1 \
  -v n8n_data:/home/node/.n8n \
  n8nio/n8n

Krok 6. Wyklucz hosty, które nie potrzebują proxy

W NO_PROXY wymień po przecinku hosty, z którymi n8n ma łączyć się bezpośrednio, np. swoje usługi wewnętrzne. Dzięki temu nie zużywają one transferu z planu. Pamiętaj, że n8n odczytuje te zmienne przez pakiet proxy-from-env, a zapis małymi literami (http_proxy) wygrywa z zapisem wielkimi (HTTP_PROXY), gdy ustawione są oba.

Krok 7. Sprawdź IP w workflow

Zbuduj testowy workflow: węzeł Manual Trigger, a po nim węzeł HTTP Request z GET https://api.ipify.org?format=json i ustawionym proxy. Uruchom workflow ręcznie i spójrz na wynik węzła: pole ip powinno pokazywać adres proxy, a nie Twojego serwera. Błąd 407 oznacza nieprawidłowy login lub hasło albo wyczerpany transfer w planie. Strona Mój IP w przeglądarce tu nie pomoże: żądanie wysyła serwer n8n, a nie przeglądarka.

Kraj i IP dla każdego item przez wyrażenie w polu Proxy

Jak inne parametry węzła, pole Proxy możesz przełączyć w tryb Expression. Wtedy każdy item wychodzi przez własny kraj i własny port. Umieść adres strony, kod kraju i port w danych wejściowych, na przykład z węzła Set albo z tabeli:

[
  { "url": "https://example.de/catalog", "country": "de", "port": 10001 },
  { "url": "https://example.pl/catalog", "country": "pl", "port": 10002 },
  { "url": "https://example.com/catalog", "country": "us", "port": 823 }
]

W polu URL wpisz {{ $json.url }}, a w polu Proxy:

http://USERNAME__cr.{{ $json.country }}:PASSWORD@gw.prokso.com:{{ $json.port }}

Items z portem ze stałym IP z zakresu 10000-20000 trzymają jeden IP tak długo, jak ustawisz w panelu, a każdy port to osobny adres. Items z portem 823 dostają nowy IP przy każdym żądaniu. Kraj nic nie kosztuje dodatkowo, więc w jednym uruchomieniu możesz mieszać kilka krajów.

Gdy węzeł HTTP Request w n8n zgłasza błąd

n8n zamienia błędy sieciowe i HTTP na krótkie komunikaty. Oto co zwykle oznaczają, gdy żądanie idzie przez proxy:

• The connection timed out, consider setting the 'Retry on Fail' option in the node settings. Proxy lub strona nie odpowiedziały na czas. Zwiększ opcję Timeout i włącz Retry On Fail (patrz niżej).
• The connection cannot be established, this usually occurs due to an incorrect host (domain) value. Literówka w gw.prokso.com albo w adresie strony, ewentualnie w kontenerze nie działa DNS.
• The service refused the connection - perhaps it is offline. Pod tym adresem nikt nie przyjął połączenia. Sprawdź port w polu Proxy: 823 lub 10000-20000.
• „Forbidden - perhaps check your credentials?”. n8n pokazuje to przy każdym 403, ale przez proxy to prawie zawsze odmowa strony, a nie twoje dane logowania w n8n. Złe hasło do proxy daje 407.
• The service is receiving too many requests from you. To 429 od strony. Zwiększ Batch Interval i zmniejsz Items per Batch.

Retry On Fail bez płacenia dwa razy za transfer

Na karcie Settings węzła opcja Retry On Fail uruchamia węzeł ponownie po błędzie. Max. Tries to liczba prób (n8n przyjmuje od 2 do 5, domyślnie 3), a Wait Between Tries (ms) to przerwa między nimi (do 5000 ms, domyślnie 1000). Na porcie 823 każda próba wychodzi z nowego IP, na porcie ze stałym IP z tego samego, dopóki nie minie czas utrzymania.

Pamiętaj, że węzeł uruchamia się ponownie w całości, ze wszystkimi items wejściowymi. Jeśli padnie jedna strona na sto, wszystkie sto pobiorą się jeszcze raz, a transfer za każdym razem liczy się w obie strony. Przy długich listach ustaw On Error na Continue (using error output): nieudane items trafią do osobnego wyjścia, gdzie drugi węzeł HTTP Request z przerwą ponowi tylko je.

Inny sposób to opcja Response: włącz Never Error oraz Include Response Headers and Status. Wtedy węzeł zwraca pole statusCode nawet dla 403 i 429, a węzeł IF może skierować takie items do wolniejszej gałęzi.

Jeśli proxy nie działa

• 429 Too Many Requests
• 403 Forbidden
• Transfer szybko się kończy