Proxy für n8n: HTTP-Anfrage ohne 403 einrichten (2026)

```html

Sie haben einen Workflow in n8n erstellt, der zwei Wochen lang funktionierte, und dann begann er stabil mit 403 Forbidden zu fallen. Der erste Gedanke ist: „Die Seite ist kaputt“ oder „Die Anmeldedaten sind abgelaufen“. Meistens liegt es jedoch an etwas anderem: Der Zielserver hat erkannt, dass die Anfrage nicht von einem Browser, sondern von einer Automatisierung kommt, die mit der Rechenzentrums-IP Ihres VPS arbeitet. n8n verfügt über einen integrierten Proxy-Mechanismus – er ist nur standardmäßig nicht aktiviert, und einige Einstellungen befinden sich nicht dort, wo man sie sucht.

Schauen wir uns Schritt für Schritt an: Wo genau der Proxy in n8n festgelegt wird, was der Unterschied zwischen self-hosted und Cloud ist und welche drei Fallen am meisten Zeit kosten.

Warum n8n häufiger blockiert wird als Ihr Browser

n8n ist die größte Open-Source-Automatisierungsplattform: fast 198.000 Sterne und 59,6 Tausend Forks auf GitHub, die aktuelle Version zum Zeitpunkt der Veröffentlichung ist [email protected] (24. Juli 2026). Die Popularität hat eine Kehrseite: Anti-Bot-Systeme kennen ihren Netzwerkstil sehr gut.

Es gibt drei Faktoren:

User-Agent verrät Sie sofort. Das ist keine Vermutung, sondern ein offiziell dokumentiertes Verhalten. In n8n gibt es eine Variable N8N_ENFORCE_GLOBAL_USER_AGENT (standardmäßig false), und die Dokumentation beschreibt direkt ihren Zweck: die „nackte“ User-Agent-Zeile n8n durch eine RFC-konforme Mozilla/5.0 (compatible; n8n/<version>; +https://n8n.io/) zu ersetzen, um die Blockierung von Anfragen durch Webanwendungsfirewalls zu verhindern. Das Problem führte zu Bug-Reports: In dem Issue #28280 (geöffnet am 10. April 2026, geschlossen) wurde beschrieben, wie native Nodes bare-UA n8n zurückgaben, während die Seiten mit 403 und dem Grund „Bad User-Agent“ antworteten. Die HTTP Request Node verwendet unter der Haube axios und ist ohne manuelle Header leicht zu erkennen.
Die IP Ihres Servers ist Rechenzentrums-IP. n8n läuft fast immer auf VPS oder in der Cloud. Diese Bereiche sind öffentlich bekannt und als „nicht benutzerdefiniert“ gekennzeichnet: Einige Plattformen schränken sie strenger ein, bis hin zu deutlich niedrigeren Anfrage-Limits als für Heimverbindungen.
Die Anfragegeschwindigkeit ist unnatürlich. Eine Node gibt in einer Schleife Dutzende von Anfragen pro Sekunde von einer Adresse aus – das ist der klassische Trigger für Rate-Limits und anschließende IP-Sperren.

Schritt 1. Proxy in der Node selbst (funktioniert auch in Cloud)

Der schnellste Weg ist, den Proxy gezielt für eine HTTP Request festzulegen:

Öffnen Sie die Node HTTP Request.
Unten klicken Sie auf Add Option und wählen Proxy – dies ist ein Textfeld für die URL des Proxy-Servers.
Geben Sie die Zeile im Standardformat mit Authentifizierung ein: http://BENUTZERNAME:PASSWORT@host:port.
Fügen Sie dort auch die Header-Option hinzu: Aktivieren Sie Send Headers und legen Sie User-Agent eines echten Browsers fest – kopieren Sie manuell die aktuelle Zeile aus den DevTools Ihres Chrome.

Diese Methode ist die einzige, die in n8n Cloud verfügbar ist: Dort verwalten Sie die Ausführungsumgebung nicht, daher sind Ihnen die systemweiten Umgebungsvariablen nicht zugänglich, und die ausgehende IP ist nicht festgelegt und ändert sich von Ausführung zu Ausführung. Der Vorteil dieser Methode ist die Granularität: Verschiedene Nodes eines Workflows können über unterschiedliche Proxys und verschiedene Geos laufen. Der Nachteil ist, dass Sie bei zwanzig Nodes zwanzig Stellen anpassen müssen.

Schritt 2. Globaler Proxy über Umgebungsvariablen (self-hosted)

Auf Ihrem eigenen Server ist es logischer, den gesamten ausgehenden Verkehr auf einmal zu verpacken. n8n liest die Standardvariablen:

HTTP_PROXY – URL des Proxys für unverschlüsselten HTTP-Verkehr der Nodes;
HTTPS_PROXY – dasselbe für TLS/SSL-Anfragen (in der Praxis ist dies Ihr Hauptparameter);
ALL_PROXY – wird verwendet, wenn keine spezifischeren HTTP_PROXY/HTTPS_PROXY festgelegt sind;
NO_PROXY – eine durch Kommas getrennte Liste von Hosts, zu denen n8n direkt ohne Proxy gehen wird.

In docker-compose.yml sieht das so aus:

HTTPS_PROXY=http://BENUTZERNAME:[email protected]:8080
NO_PROXY=localhost,127.0.0.1,postgres,n8n.example.com
N8N_ENFORCE_GLOBAL_USER_AGENT=true

Füllen Sie unbedingt NO_PROXY aus. Andernfalls gehen auch interne Anfragen über den externen Proxy – zu Ihrer Postgres, zu benachbarten Containern, zu Ihrer eigenen Webhook-Domain. Ein Symptom ist: „Alles ist kaputt gegangen, nachdem der Proxy aktiviert wurde“, obwohl die Zielseiten gerade erst zu laden begannen.

Wenn Sie die Version von n8n nicht nach außen offenlegen möchten, geben Sie anstelle der RFC-Zeile Ihre eigene über N8N_GLOBAL_USER_AGENT_VALUE an – diese überschreibt den Standardwert. Die allgemeine Logik zur Konfiguration des Containerverkehrs ist dieselbe wie in anderen Szenarien: Eine Analyse der Formate und Fallstricke finden Sie im Leitfaden zum Proxy für Docker-Container.

Schritt 3. Drei Fallen, die den Abend stehlen

Falle 1: Die Registrierung der Variablen entscheidet

Das ist nicht offensichtlich und kommt in Tutorials fast nie vor. n8n verarbeitet Variablen, die auf _PROXY enden, über das npm-Paket proxy-from-env, und dieses zwingt seine eigene Prioritätsreihenfolge auf: Die Kleinbuchstabenvarianten (http_proxy) haben Vorrang vor den Großbuchstabenvarianten (HTTP_PROXY), wenn beide festgelegt sind. Ein klassisches Schmerzszenario: In der Systemumgebung liegt schon lange ein vergessenes https_proxy, Sie schreiben sorgfältig HTTPS_PROXY in das Compose – und der Verkehr geht hartnäckig zur alten Adresse. Überprüfen Sie beide Schreibweisen.

Ein separates Detail für Enterprise: Die Proxy-Variable für Anfragen an den Lizenzserver https_proxy_license_server muss nur in Kleinbuchstaben sein, das Format ist https://user:pass@proxy:port.

Falle 2: Code Node kann nicht das, was Sie sich vorgestellt haben

Ein häufiger Rat aus Foren ist: „Schreiben Sie in der Code Node Ihre Anfrage über axios mit einem Proxy-Agenten“. Standardmäßig funktioniert das nicht: n8n deaktiviert den Import von Modulen in der Code Node. Sie müssen sie explizit erlauben – NODE_FUNCTION_ALLOW_BUILTIN für eingebaute und NODE_FUNCTION_ALLOW_EXTERNAL für externe (aus n8n/node_modules). Ein zusätzlicher Punkt: Wenn Sie Task Runner im externen Modus haben, werden diese Variablen nicht in der Containerumgebung, sondern in der Konfiguration der Runner /etc/n8n-task-runners.json als env-override festgelegt. Es ist einfacher und sicherer, bei der Standardoption Proxy in der Node zu bleiben.

Falle 3: Proxy ist vorhanden, aber das Tempo bleibt gleich

Der Proxy ändert die Adresse, aber nicht das Verhalten. Wenn der Workflow weiterhin einen Schwall von Anfragen abgibt, verbrennen Sie einfach neue IPs. In derselben Node gibt es integrierte Bremsen:

Batching – Items per Batch (wie viele Elemente in einem Batch) und Batch Interval in Millisekunden (0 = ohne Pause). Stellen Sie ein Batch von 1–5 und ein Intervall von 1000–3000 ms ein.
Timeout – in Millisekunden; residentielle Kanäle sind langsamer als Rechenzentrumsverbindungen, der Standardwert sollte erhöht werden.
Response → Never Error – lässt den gesamten Workflow nicht beim ersten 403 abstürzen, ermöglicht die Verarbeitung des Antwortcodes durch Verzweigung.
Pagination – Modi Update a Parameter und Response Contains Next URL anstelle von selbstgebauten Schleifen.

Auf Instanzebene begrenzt N8N_CONCURRENCY_PRODUCTION_LIMIT die Geschwindigkeit (standardmäßig -1, also ohne Limit) – ein vernünftiger Wert schützt sowohl den Proxy-Pool als auch den Server selbst. Weitere Informationen darüber, wie Plattformen Ihre Anfragen zählen und was mit Limits zu tun ist, finden Sie in der Analyse zum Umgehen von Rate-Limits über Proxys.

Welche Proxys für n8n verwenden

Die Wahl hängt nicht von der „Coolness“ ab, sondern davon, wer auf der anderen Seite sitzt.

Rechenzentrums-Proxys. Günstig und schnell. Geeignet für offizielle APIs, interne Dienste, botfreundliche Websites und alle Aufgaben, bei denen einfach eine stabile statische Adresse benötigt wird – zum Beispiel, um Ihre IP auf die Whitelist eines Partners zu setzen. Auf geschützten Plattformen erhalten Sie genau denselben 403 wie bei einem nackten VPS: Ihre Bereiche sind bekannt. Dies ist die Basis für Batch-Aufgaben ohne Anti-Bot.
Residential Proxys. Adressen realer Heimprovider – das, was für das Scraping von Seiten mit ernsthaften Schutzmaßnahmen, für geoabhängige Inhalte und zur Preisüberwachung benötigt wird. Für Workflows, die öffentliche Websites besuchen, sind residential proxies der funktionale Standard: Nehmen Sie eine Rotation pro Anfrage für massenhaftes Scraping und sticky Sessions, wenn eine Sitzung über eine Kette von Nodes gehalten werden muss.
Mobile Proxys. Das höchste Vertrauensniveau: Hinter einem Anbieter sitzen Tausende von echten Abonnenten, es ist teuer, eine solche IP zu sperren. Sie sind dort gerechtfertigt, wo es am härtesten geschnitten wird – bei der Arbeit mit sozialen Netzwerken und Messengern. Dafür zahlen Sie mit Geschwindigkeit und Preis.

Ein praktisches Schema für einen gemischten Workflow: offizielle APIs – direkt oder über Rechenzentrums-Proxys, öffentliche Websites – über residential Proxys, soziale Netzwerke – über mobile Proxys. Die Proxy-Option wird in jeder Node separat konfiguriert, sodass Sie all dies in einem Szenario ohne Umwege kombinieren können.

Checkliste vor dem Start

Proxy festgelegt – entweder über die Option Proxy in der Node oder über HTTPS_PROXY; in der Cloud ist nur die erste Option verfügbar.
Beide Schreibweisen der Variablen überprüft – Kleinbuchstaben überschreiben Großbuchstaben.
NO_PROXY schließt localhost, die Datenbank und interne Hosts aus.
User-Agent ersetzt: N8N_ENFORCE_GLOBAL_USER_AGENT=true oder eigener Header in der Node. Überprüfen Sie auch die Konsistenz der anderen Header – inkonsistente Header-Sets geben Automatisierung nicht schlechter als der User-Agent selbst aus.
Batching mit einem nicht nullen Intervall aktiviert.
Ein Testlauf wurde mit 3–5 Elementen und nicht mit der gesamten Liste durchgeführt.

Fazit

403 in n8n ist fast immer nicht nur ein Grund, sondern die Summe von drei: ein erkennbarer User-Agent, eine Rechenzentrums-IP und ein zu gleichmäßiges Anfrage-Tempo. Dies wird ebenfalls mit einem Set von Maßnahmen behoben und nicht mit einem einzigen Häkchen: UA ersetzen, den Verkehr über den richtigen Proxy leiten und die Node über Batching bremsen. Alle drei Hebel sind bereits in die Plattform integriert – sie müssen nur gefunden und aktiviert werden.

Am einfachsten beginnt man mit einem residential Proxy für die problematischsten Nodes und einem Rechenzentrums-Proxy für die anderen: Die Bezahlung bei ProxyCove erfolgt nach Verkehr, daher können Sie für Tests ein minimales Volumen nehmen und sehen, wie sich Ihr spezifischer Workflow verhält. Wählen Sie einen Proxy für die Aufgabe aus und geben Sie die Zeile im Proxy-Feld ein – das ist eine Sache von ein paar Minuten.