Web Scraping mit n8n: HTTP Request und Proxy-Einstellungen

Ihr Workflow in n8n öffnet jeden Morgen zehn Produktseiten und schreibt die Preise in eine Tabelle. In der ersten Woche läuft alles. Dann wächst die Liste auf zweihundert Produkte, der Workflow schickt seine Anfragen dicht hintereinander von der einzigen IP-Adresse Ihres Servers, und der HTTP-Request-Node wird rot: erst 429, dann 403. Oder der umgekehrte Fall: Die Ziel-API zeigt den richtigen Preis nur bei Anfragen aus einem bestimmten Land, Ihr n8n-Server steht aber in einem anderen. In beiden Fällen suchen Sie dieselbe Einstellung: die ausgehenden Anfragen von n8n über einen Proxy zu leiten.

In diesem Beitrag erklären wir die zwei Stellen, an denen ein Proxy in n8n definiert wird: die Proxy-Option im HTTP-Request-Node und die Umgebungsvariablen einer selbst gehosteten Installation. Wir gehen der Reihe nach durch, wie die Zugangsdaten in die Adresse geschrieben werden, welche Einstellung welche überschreibt, worin sich n8n Cloud und der eigene Server unterscheiden und welche Fehler häufig auftreten. Das Thema Reverse-Proxy, nach dem ein Teil der Suchenden hinter „n8n proxy“ eigentlich sucht, grenzen wir ebenfalls ab. Der Beispiel-Workflow beobachtet Preise auf einer Website, die zum Üben veröffentlicht wurde.

Was ist n8n und wo passt es ins Scraping?#

n8n ist ein Automatisierungswerkzeug, in dem Sie Workflows bauen, indem Sie Kästchen (Nodes) mit Linien verbinden. Ein Trigger-Node startet den Workflow (Zeitplan, Webhook, Formular), die folgenden Nodes holen Daten, wandeln sie um und schreiben sie irgendwohin. Sie können das Werkzeug in der Cloud von n8n nutzen (n8n Cloud) oder auf dem eigenen Server installieren (self-hosted). Diese Unterscheidung ist beim Thema Proxy entscheidend.

Beim Scraping erledigen zwei Nodes die Arbeit. Der Node HTTP Request schickt eine Anfrage an eine Adresse und nimmt die Antwort entgegen; der Node HTML zieht mit CSS-Selektoren die gewünschten Felder aus dieser Antwort. Dieses Paar funktioniert gut bei Seiten, deren Inhalt fertig vom Server kommt, und bei APIs, die JSON liefern. Bei Seiten, deren Inhalt erst im Browser per JavaScript entsteht, sieht HTTP Request nur ein leeres Gerüst; den Unterschied haben wir im Beitrag Statische und dynamische Seiten erklärt. Zum Schreiben von Selektoren siehe CSS-Selektor oder XPath.

Die Stärke von n8n liegt in dem, was danach mit den Daten geschieht: in eine Tabelle schreiben, mit dem alten Wert vergleichen, bei einer Änderung benachrichtigen. Für einen Crawl über Tausende Seiten ist es nicht das richtige Werkzeug; in dieser Größenordnung brauchen Sie ein Framework wie Scrapy oder eine Infrastruktur für Data Scraping. Welche Methode wann ausreicht, haben wir im Beitrag Daten von Websites extrahieren verglichen.

„n8n proxy“ sind zwei getrennte Themen: Welches suchen Sie?#

In den Suchvorschlägen stehen neben „n8n proxy“ auch die Wörter proxy hops, nginx und reverse. Sie haben mit der Einstellung, um die es hier geht, nichts zu tun:

Wenn Sie n8n hinter nginx betreiben, verlangt die Seite der n8n-Dokumentation zur Konfiguration der Webhook-Adresse hinter einem Reverse-Proxy zwei Dinge: N8N_PROXY_HOPS auf 1 zu setzen (der Standardwert ist 0; die Variable gibt an, wie viele Reverse-Proxys vor n8n stehen) und den letzten Proxy der Kette die Header X-Forwarded-For, X-Forwarded-Host und X-Forwarded-Proto weiterreichen zu lassen. Auf Ihre ausgehenden Anfragen haben diese Einstellungen keinerlei Einfluss. Den Unterschied zwischen beiden Konzepten und ein nginx-Beispiel finden Sie im Beitrag Forward-Proxy und Reverse-Proxy. Der Rest dieses Beitrags handelt vom Forward-Proxy.

Wie wird der Proxy im HTTP-Request-Node definiert?#

Die Einstellung steht nicht bei den Hauptfeldern des Nodes, sondern ganz unten im Bereich Options; deshalb fällt sie auf den ersten Blick nicht auf.

1. Öffnen Sie in Ihrem Workflow den HTTP-Request-Node und füllen Sie Method und URL aus.
2. Klicken Sie im Bereich Options ganz unten bei den Parametern auf Add option.
3. Fügen Sie aus der Liste Proxy hinzu.
4. Tragen Sie in das neue Feld die Proxy-Adresse samt Schema ein: http://user:pass@pr.proxynet.io:8000
5. Führen Sie den Node mit Execute step einzeln aus und prüfen Sie die Ausgabe.

Der Platzhaltertext des Feldes lautet e.g. http://myproxy:3128; n8n erwartet hier also eine vollständige URL. In der aktuellen Version, die wir für diesen Beitrag lokal installiert haben, erzeugte eine Adresse ohne Schema (user:pass@pr.proxynet.io:8000) keinen Fehler, die Anfrage ging schlicht direkt hinaus, ohne den Proxy zu berühren. Bei einer Adresse, die mit socks5:// beginnt, war das Ergebnis dasselbe: Das Feld ist für HTTP-Proxys gedacht. Die Dokumentation des HTTP-Request-Nodes sagt ausdrücklich, dass diese Option Vorrang vor der globalen Einstellung über HTTP_PROXY, HTTPS_PROXY und ALL_PROXY hat. Ist auf Ihrem Server ein Unternehmens-Proxy definiert, können Sie also einen einzelnen Node über einen anderen Endpunkt hinausschicken.

Wohin gehören Benutzername und Passwort?#

Der Node hat kein eigenes Feld für Benutzername oder Passwort des Proxys. Die Zugangsdaten stehen in der Adresse, in der Form benutzer:passwort@. Der Bereich Authentication des Nodes geht an die Zielseite, nicht an den Proxy; das Proxy-Passwort dort einzutragen behebt einen 407 nicht.

Enthält Ihr Passwort Zeichen wie @, :, / oder #, wird die Adresse an der falschen Stelle getrennt. Schreiben Sie diese Zeichen prozentkodiert: %40 statt @, %3A statt :. In unserem lokalen Test wurde das Passwort pa@ss:1 in der Schreibweise pa%40ss%3A1 am Proxy korrekt aufgelöst. Die Einzelheiten der beiden Authentifizierungsverfahren stehen im Beitrag Proxy-Authentifizierung: User:Pass oder IP-Whitelist.

Noch ein Sicherheitshinweis: Das Proxy-Feld ist Klartext und landet nicht im verschlüsselten Speicher für Zugangsdaten (Credentials) von n8n. Wenn Sie den Workflow als JSON exportieren und weitergeben, wandert Ihr Proxy-Passwort in der Datei mit; leeren Sie das Feld vor dem Teilen.

Lässt sich eine IP-Whitelist mit n8n nutzen?#

Bei n8n auf dem eigenen Server mit fester IP-Adresse ja: Sie tragen die IP des Servers in die Liste der zugelassenen Adressen in Ihrem Proxy-Dashboard ein, die Adresse wird ohne Passwort als http://pr.proxynet.io:8000 geschrieben. In n8n Cloud ist dieses Verfahren nicht verlässlich. n8n schreibt auf der Dokumentationsseite zu den Cloud-IP-Adressen, dass die ausgehenden IPs nicht statisch sind und sich ohne Vorwarnung ändern können. Eine Adresse, die Sie heute freigeben, kann morgen ungültig sein. Verbinden Sie sich in der Cloud mit Benutzername und Passwort.

Wie nutzt man Umgebungsvariablen in einer selbst gehosteten Installation?#

Statt den Proxy in jeden Node einzeln zu schreiben, können Sie ihn für den gesamten n8n-Prozess definieren. Die Seite zu den Umgebungsvariablen für das Deployment nennt vier Variablen:

In einer Installation mit Docker Compose kommen die Variablen in den Abschnitt environment des Dienstes:

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n
    environment:
      - HTTP_PROXY=http://user:pass@pr.proxynet.io:8000
      - HTTPS_PROXY=http://user:pass@pr.proxynet.io:8000
      - NO_PROXY=localhost,127.0.0.1,postgres,redis

Dass der Wert von HTTPS_PROXY mit http:// beginnt, ist kein Tippfehler: Der Name der Variable nennt nicht das Schema des Proxys, sondern den Traffic, der dorthin geht. Wie diese Variablen im Betriebssystem definiert werden, haben wir im Beitrag Proxy-Nutzung mit wget erklärt; hier gehen wir nur auf drei Fallen ein, die n8n betreffen.

Die kleingeschriebene Variable überschreibt die großgeschriebene. Dieselbe Dokumentationsseite weist darauf hin, dass im Paket proxy-from-env, das n8n verwendet, kleingeschriebene Namen wie http_proxy Vorrang vor den großgeschriebenen haben, wenn beide gesetzt sind. Hat jemand anderes eine kleingeschriebene Variable in Ihr Docker-Image oder auf Ihren Server gelegt, wird Ihr Wert für HTTP_PROXY stillschweigend ignoriert. Prüfen Sie im Container mit env | grep -i proxy beide Schreibweisen.

Lassen Sie NO_PROXY nicht leer. Spricht n8n im selben Netz auch per HTTP mit der Datenbank, mit Redis oder mit einer internen API, gehen auch diese Anfragen an den Proxy und bleiben dort sehr wahrscheinlich hängen. Nehmen Sie interne Hostnamen und localhost in die Liste auf.

Nicht jeder Node hält sich an diese Variablen. Nodes, die den HTTP-Helfer von n8n nutzen, sehen die Einstellung. Bei manchen Nodes, die eine eigene Client-Bibliothek mitbringen, gibt es offene Meldungen, dass die Variable nicht beachtet wird (zum Beispiel wurde Issue #19652 im n8n-Repository 2025 für den Node RSS Read eröffnet und später geschlossen). Testen Sie einen kritischen Node mit dem Prüfschritt weiter unten, bevor Sie ihn produktiv einsetzen.

Die Variablen werden beim Start des n8n-Prozesses gelesen; nach einer Änderung müssen Sie den Container oder den Dienst neu starten.

n8n Cloud und self-hosted: Welcher Weg steht wo offen?#

Nutzen Sie Cloud, ist die Option im Node Ihr einziger Weg. In einer selbst gehosteten Installation stehen beide offen; die Umgebungsvariable können Sie als „Standardausgang“ betrachten, die Option im Node als „diese Anfrage soll woanders hinausgehen“.

Beispiel-Workflow: den Preis eines Produkts beobachten#

Das Beispiel bauen wir auf books.toscrape.com auf, einer Website, die zum Üben von Scraping veröffentlicht wurde. Prüfen Sie in Ihrem eigenen Projekt zuerst, ob die Zielseite eine offizielle API oder ein Händlerportal hat; falls ja, nutzen Sie das, statt HTML zu parsen. Falls nicht, lesen Sie die Datei robots.txt und die Nutzungsbedingungen der Seite. Wie die Regeln in robots.txt zu lesen sind, steht im Beitrag Was ist robots.txt.

Der Workflow besteht aus sechs Nodes:

1. Schedule Trigger: startet den Workflow einmal am Tag. Eine Abfrage im Minutentakt ist bei der Preisbeobachtung selten nötig.
2. Produktliste: Holen Sie die Adressen aus einer Google-Sheets-Tabelle oder aus einem Node Edit Fields. Jede Zeile trägt ein Feld url.
3. Loop Over Items: verarbeitet die Liste Eintrag für Eintrag. Lassen Sie Batch Size auf 1.
4. HTTP Request: Tragen Sie in das Feld URL den Ausdruck {{ $json.url }} ein, definieren Sie unter Options den Proxy und lassen Sie in der Option Response das Format auf Text.
5. HTML: Wählen Sie als Operation Extract HTML Content und definieren Sie die gewünschten Felder mit CSS-Selektoren.
6. Wait: wartet einige Sekunden und kehrt an den Anfang der Schleife zurück.

Ist die Schleife durchlaufen, schreiben Sie die Daten in eine Tabelle, vergleichen sie in einem Node If mit dem Preis des Vortags und verschicken bei einer Abweichung eine Benachrichtigung.

So sieht der HTTP-Request-Node im exportierten Workflow-JSON aus:

{
  "parameters": {
    "url": "={{ $json.url }}",
    "options": {
      "proxy": "http://user:pass@pr.proxynet.io:8000",
      "timeout": 20000,
      "response": {
        "response": { "fullResponse": true, "responseFormat": "text" }
      }
    }
  },
  "name": "HTTP Request",
  "type": "n8n-nodes-base.httpRequest",
  "typeVersion": 4.2
}

Im Node HTML reichen für diese Seite drei Zeilen:

Aktivieren Sie unter Options Trim Values und Clean Up Text; so verschwinden die Zeilenumbrüche und überzähligen Leerzeichen in der Bestandszeile. Die Ausgabe ist ein Text wie £51.77; um daraus eine Zahl zu machen, entfernen Sie im nächsten Node das Währungszeichen und korrigieren das Dezimaltrennzeichen.

Einen umfassenderen Aufbau mit Produktabgleich, Preisverlauf und Schwellenwert-Alarm beschreiben wir im Beitrag Wettbewerberpreise im E-Commerce überwachen, die Produktseite dazu auf unserer Seite zur Preisüberwachung.

Wie richtet man Rate-Limits und Wiederholungen in n8n ein?#

Bekommt n8n eine Liste, schickt es die Anfragen für alle Einträge hintereinander und ohne Pause ab, solange Sie nichts anderes festlegen. Ein Proxy macht dieses Verhalten nicht rücksichtsvoll; er ändert nur die Adresse, von der die Anfragen ausgehen. Die Last, die die Zielseite sieht, müssen Sie selbst begrenzen. Die Seite „Handle rate limits“ der n8n-Dokumentation zeigt drei eingebaute Wege:

• Batching (HTTP Request → Options): Mit Items per Batch legen Sie fest, wie viele Anfragen auf einmal hinausgehen, mit Batch Interval (ms) die Pause zwischen den Paketen. Der kürzeste Weg, ganz ohne Code.
• Loop Over Items + Wait: der Aufbau aus dem Beispiel oben. Sie sehen die Pause nach jeder Anfrage ausdrücklich und können weitere Nodes dazwischensetzen.
• Retry On Fail (Reiter Settings des Nodes): wiederholt eine fehlgeschlagene Anfrage; mit Wait Between Tries (ms) geben Sie die Zeit zwischen den Versuchen an.

Retry On Fail für jeden Fehler einzuschalten ist nicht richtig. 429 und 503 lösen sich durch Warten; 403 und 407 nicht, dieselbe Anfrage fünfmal zu schicken erzeugt nur unnötigen Traffic. Bei welchem Code ein neuer Versuch sinnvoll ist und bei welchem nicht, haben wir in der Tabelle im Beitrag HTTP-Statuscodes beim Web Scraping zusammengestellt; die Logik hinter Rate-Limits steht im Beitrag 429 Too Many Requests. Wenn Sie nach Statuscode verzweigen möchten, aktivieren Sie in der Option Response des HTTP Request Include Response Headers and Status und Never Error und prüfen danach in einem If-Node das Feld statusCode.

Braucht man für die Rotation einen eigenen Node oder Code?#

Manche Scraping-Vorlagen für n8n enthalten JavaScript-Stücke, die in einem Code-Node eine Proxy-Liste halten und bei jeder Anfrage den nächsten Eintrag wählen. Haben Sie eine Liste einzelner IP-Adressen, ist das nötig. Bei einem rotierenden Endpunkt nicht: Sie verbinden sich mit einer einzigen Adresse wie pr.proxynet.io:8000, und der Anbieter wechselt bei jeder neuen Verbindung die Ausgangs-IP. Auf der Seite von n8n ändert sich die Adresse im Proxy-Feld nie. Die Einzelheiten des Mechanismus stehen im Beitrag Was ist IP-Rotation und wie funktioniert sie?, die Produktseite dazu unter Rotierender Proxy.

Umgekehrt gibt es Aufgaben, bei denen sich die IP nie ändern darf. Nimmt die API eines Geschäftspartners nur Anfragen von freigegebenen Adressen an und nutzen Sie n8n Cloud, löst es das Problem, statt über die wechselnden Cloud-IPs über eine feste Adresse wie ISP-Proxy hinauszugehen. Dieses Szenario behandeln wir im Beitrag Statische IP für den API-Zugriff.

Wie nutzt man einen Proxy im AI-Agent-Node?#

An den AI-Agent-Node von n8n können Sie HTTP Request als Werkzeug (Tool) anbinden; das Modell ruft es bei Bedarf auf und liest eine Seite oder eine API. Ein als Tool angebundener HTTP Request hat denselben Bereich Options, die Proxy-Option funktioniert hier also genauso. Die Dokumentation nennt für diese Nutzung eine weitere Option: Optimize Response filtert JSON-Felder oder zieht aus HTML nur den Text, bevor die Antwort an das Modell geht, und senkt so die Zahl der verbrauchten Token.

Achten Sie beim Aufbau eines Agenten auf zwei Punkte. Begrenzen Sie in der Tool-Definition die Adressen, die der Agent erreichen darf: Statt die URL ganz dem Modell zu überlassen, definieren Sie eine feste Domain und einen Pfadparameter, den das Modell ausfüllt. Die Anfragen an den Anbieter des Sprachmodells laufen dagegen nicht über HTTP Request; um sie hinter einen Proxy zu stellen, brauchen Sie in einer selbst gehosteten Installation Umgebungsvariablen und sollten gesondert testen, ob der Modell-Node die Variable beachtet. Wie Agenten ins Web gelangen, erklären wir in den Beiträgen Wie funktionieren KI-Agenten? und Sicherer Webzugriff für LLMs. Für Seiten, die einen echten Browser brauchen, siehe Playwright MCP.

Wie prüft man, ob der Proxy funktioniert?#

Weil eine falsch geschriebene Adresse ohne Fehlermeldung ignoriert werden kann, sollten Sie die Einstellung unbedingt testen:

1. Setzen Sie zwei HTTP-Request-Nodes in einen leeren Workflow. Beide zeigen auf einen Dienst, der die IP zurückgibt, von der die Anfrage kam (zum Beispiel https://api.ipify.org?format=json).
2. Lassen Sie beim ersten die Option Proxy leer, füllen Sie sie beim zweiten aus.
3. Führen Sie beide aus. Der erste Node sollte die IP Ihres n8n-Servers (oder der Cloud) zeigen, der zweite die Ausgangs-IP des Proxys. Sind beide Adressen gleich, ist der Proxy nicht aktiv.
4. Nutzen Sie Umgebungsvariablen, machen Sie denselben Test mit einem Node, dessen Proxy-Feld leer ist: Hat sich die IP geändert, wird die Variable gelesen.

Die Schritte im Einzelnen stehen im Beitrag So testen Sie einen Proxy.

Häufige Fehlermeldungen und ihre Bedeutung#

Die Zeile 400 hat eine Vorgeschichte, die n8n betrifft. Der HTTP-Request-Node nutzt im Hintergrund die Bibliothek Axios, und die eingebaute Proxy-Unterstützung von Axios ist dafür bekannt, bei HTTPS-Zielen die Anfrage direkt an den Proxy zu schicken, statt einen CONNECT-Tunnel zu öffnen. Issue #9169 im n8n-Repository belegt, dass dieses Verhalten im Node zu einem 400 führte. Das Issue stammt von 2024. In der aktuellen Version, die wir getestet haben, öffnete der Node für ein HTTPS-Ziel einen CONNECT-Tunnel am Proxy und holte die Seite ohne Probleme. Wenn in einer alten n8n-Version HTTP-Adressen über den Proxy laufen, HTTPS-Adressen aber 400 liefern, ist ein Update der erste Schritt.

Sehen Sie im Browser den Hinweis, dass der Proxyserver nicht antwortet, hat das Problem nichts mit n8n zu tun; siehe unseren Beitrag Der Proxyserver antwortet nicht.

Einsatzbereiche#

• Preis- und Bestandsbeobachtung: Workflows, die einmal am Tag laufen und bei einer Änderung benachrichtigen. Der Aufbau entspricht dem Beispiel oben; die Produktseite dazu ist unsere Seite zur Preisüberwachung.
• Kontrolle standortabhängiger Inhalte: denselben Node mit Proxys aus verschiedenen Ländern ausführen, um zu vergleichen, wie dieselbe Seite jeweils aussieht. Für eine breite Länderabdeckung kommen Residential-Proxy zum Einsatz.
• Inhalte in kleinem Umfang sammeln: Schlagzeilen, Anzeigenzahlen, öffentlich zugängliche Kataloge. Wächst der Umfang, ist der Wechsel zu einer Web-Crawler-Lösung sinnvoller.

Häufige Fehler#

• Das Proxy-Passwort in den Bereich Authentication schreiben. Dieser Bereich geht an die Zielseite. Die Zugangsdaten des Proxys stehen in der Adresse.
• Das Schema weglassen. Schreiben Sie http://pr.proxynet.io:8000 statt pr.proxynet.io:8000; eine Adresse ohne Schema kann ohne Fehlermeldung ignoriert werden.
• Nach dem Einrichten des Proxys das Rate-Limit vergessen. Eine Liste mit hundert Einträgen schickt ohne Batching oder Wait hundert Anfragen gleichzeitig.
• Seiten automatisieren, die eine Anmeldung verlangen oder personenbezogene Daten enthalten. Ein Proxy macht einen Workflow nicht legitim, der gegen Plattformbedingungen oder die DSGVO verstößt; den rechtlichen Rahmen fassen wir im Beitrag Ist Web Scraping legal? zusammen.

Entscheidungshilfe#

Häufige Fragen#

Lässt sich in n8n Cloud ein Proxy nutzen?#

Ja, die Proxy-Option im HTTP-Request-Node gibt es auch in der Cloud; Umgebungsvariablen dagegen stehen nicht zur Verfügung. Weil die ausgehenden IPs der Cloud nicht fest sind, verbinden Sie sich mit dem Proxy nicht per IP-Whitelist, sondern mit Benutzername und Passwort.

Wozu dient N8N_PROXY_HOPS?#

Die Variable gibt an, wie viele Reverse-Proxys (nginx, Caddy, Load Balancer in der Cloud) vor n8n stehen; der Standardwert ist 0. Mit ausgehenden Anfragen und der Proxy-Einstellung aus diesem Beitrag hat sie nichts zu tun.

Hat die Proxy-Einstellung im Node oder die Umgebungsvariable Vorrang?#

Die Einstellung im Node. So steht es in der n8n-Dokumentation; auch in unserem lokalen Test ging ein Node mit ausgefüllter Proxy-Option über seinen eigenen Proxy hinaus, während die Umgebungsvariable auf einen geschlossenen Port zeigte.

Gibt es dieselbe Einstellung in Zapier?#

Nein. Der Webhooks-Schritt von Zapier hat Felder für Adresse, Daten, Header und Basic-Authentifizierung; ein Proxy-Feld gibt es nicht. Um die Anfrage über einen Proxy zu leiten, müssen Sie einen eigenen kleinen Dienst dazwischenschalten: Zapier ruft diesen Dienst auf, und der Dienst geht über den Proxy zum Ziel.

Muss ich mein Proxy-Passwort im Workflow im Klartext halten?#

Wenn Sie die Option im Node nutzen, ja, das Feld ist Klartext. In einer selbst gehosteten Installation sind Umgebungsvariablen der Weg, das Passwort aus dem Workflow herauszuhalten: Die Zugangsdaten bleiben in der Serverkonfiguration und landen nicht im Workflow-JSON. Haben Sie einen Server mit fester IP, macht eine IP-Whitelist das Passwort ganz überflüssig.

Lassen sich mit HTTP Request Daten von jeder Seite holen?#

Nein. Der Node führt kein JavaScript aus, deshalb steht bei Seiten, deren Inhalt im Browser entsteht, das gesuchte Feld nicht in der Antwort. Seiten mit Bot-Schutz können zudem unabhängig vom Proxy eine Prüfseite zurückgeben. In so einem Fall gilt es nicht, gegen den Schutz anzugehen, sondern nach der offiziellen API der Seite oder nach Möglichkeiten einer Datenpartnerschaft zu schauen.

Fazit#

In n8n wird ein Proxy an zwei Stellen definiert: im Feld Proxy im Bereich Options des HTTP-Request-Nodes und über die Variablen HTTP_PROXY, HTTPS_PROXY und NO_PROXY einer selbst gehosteten Installation. Die Zugangsdaten stehen in der Adresse, die Einstellung im Node überschreibt die globale, und N8N_PROXY_HOPS betrifft nur Installationen hinter einem Reverse-Proxy. Ein Proxy ersetzt kein Rate-Limit: Drosseln Sie mit Batching oder Wait, warten Sie bei 429 und wählen Sie die offizielle API, wenn es eine gibt. Die IP-Typen, die zu Ihren Workflows passen, können Sie auf unserer Seite zu den Proxy-Diensten vergleichen.