---
title: "Web Scraping mit n8n: HTTP Request und Proxy-Einstellungen"
description: "In n8n legen Sie den Proxy in den Optionen des HTTP-Request-Nodes oder über Umgebungsvariablen fest. Einrichtung, Authentifizierung und häufige Fehler."
url: https://proxynet.io/de/blog/n8n-proxy
date: 2026-09-19
author: "Acar Diveroli"
category: "Integration, Anleitungen"
lang: de
---

# 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.

> **Hinweis: Kurzantwort**
>
> Im HTTP-Request-Node genügt es, unter **Options → Add option → Proxy** eine Adresse der Form `http://user:pass@pr.proxynet.io:8000` einzutragen; diese Einstellung wirkt nur auf diesen Node und funktioniert auch in n8n Cloud. Bei n8n auf dem eigenen Server gelten die Umgebungsvariablen `HTTP_PROXY`, `HTTPS_PROXY` und `NO_PROXY` für alle Nodes. Ist beides definiert, überschreibt die Einstellung im Node die Umgebungsvariable. `N8N_PROXY_HOPS` ist ein völlig anderes Thema: Die Variable brauchen Sie, wenn Sie n8n selbst hinter einen Reverse-Proxy wie nginx stellen.

## 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](/de/blog/static-vs-dynamic-pages) erklärt. Zum Schreiben von Selektoren siehe [CSS-Selektor oder XPath](/de/blog/css-selector-vs-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](/de/blog/scrapy-proxy) oder eine Infrastruktur für [Data Scraping](/de/data-scraping). Welche Methode wann ausreicht, haben wir im Beitrag [Daten von Websites extrahieren](/de/blog/extract-data-from-website) 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:

| | Forward-Proxy | Reverse-Proxy |
|---|---|---|
| Richtung des Traffics | Anfragen, die n8n verlassen | Anfragen, die bei n8n ankommen |
| Wozu er dient | Bestimmt IP-Adresse und Land, aus dem die Anfrage kommt | Stellt n8n unter einer Domain mit HTTPS bereit |
| Typisches Werkzeug | Endpunkt des Proxy-Anbieters | nginx, Caddy, Traefik |
| Einstellung in n8n | HTTP Request → Proxy, `HTTP_PROXY`, `HTTPS_PROXY` | `N8N_PROXY_HOPS`, Variable für die Webhook-Adresse |
| Symptom | `407`, `ECONNREFUSED`, `403` / `429` von der Zielseite | Webhook-Adresse zeigt `localhost`, falsche Client-IP |

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](/de/blog/forward-vs-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](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest/) 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](/de/blog/proxy-authentication-methods).

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](https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/deployment) nennt vier Variablen:

| Variable | Aufgabe |
|---|---|
| `HTTP_PROXY` | Unverschlüsselter HTTP-Traffic der Nodes läuft über diese Adresse |
| `HTTPS_PROXY` | TLS-verschlüsselter Traffic (HTTPS) der Nodes läuft über diese Adresse |
| `ALL_PROXY` | Gilt für beides, wenn die beiden spezifischeren Variablen nicht gesetzt sind |
| `NO_PROXY` | Kommagetrennte Liste von Hosts, die direkt und ohne Proxy angesprochen werden |

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

```yaml
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](/de/blog/wget-proxy) 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](https://github.com/n8n-io/n8n/issues/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?

| | n8n Cloud | Self-hosted (Docker, npm) |
|---|---|---|
| HTTP Request → Option Proxy | Vorhanden | Vorhanden |
| `HTTP_PROXY` / `HTTPS_PROXY` | Nicht definierbar, weil die Serverumgebung nicht bei Ihnen liegt | Definierbar, wirkt auf den gesamten Prozess |
| Proxy mit IP-Whitelist | Nicht empfohlen: ausgehende IPs ändern sich ohne Vorwarnung | Funktioniert auf einem Server mit fester IP |
| Ausgehende IP ohne Proxy | Wechselnde Adressen in der Cloud-Infrastruktur von n8n | Die eigene Adresse Ihres Servers |

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](/de/blog/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:

```json
{
  "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:

| Key | CSS Selector | Return Value |
|---|---|---|
| `titel` | `h1` | Text |
| `preis` | `p.price_color` | Text |
| `bestand` | `p.availability` | Text |

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](/de/blog/competitor-price-tracking), die Produktseite dazu auf unserer Seite zur [Preisüberwachung](/de/price-monitoring).

## 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](/de/blog/http-status-codes-web-scraping) zusammengestellt; die Logik hinter Rate-Limits steht im Beitrag [429 Too Many Requests](/de/blog/http-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?](/de/blog/ip-rotation-explained), die Produktseite dazu unter [Rotierender Proxy](https://proxynet.io/de/rotating-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](https://proxynet.io/de/static-isp-residential-proxy) hinauszugehen. Dieses Szenario behandeln wir im Beitrag [Statische IP für den API-Zugriff](/de/blog/static-ip-for-api-access).

## 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?](/de/blog/how-ai-agents-work) und [Sicherer Webzugriff für LLMs](/de/blog/llm-safe-web-access). Für Seiten, die einen echten Browser brauchen, siehe [Playwright MCP](/de/blog/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](/de/blog/how-to-test-a-proxy).

## Häufige Fehlermeldungen und ihre Bedeutung

| Fehler | Woher er kommt | Mögliche Ursache | Was zu tun ist |
|---|---|---|---|
| `ECONNREFUSED` | n8n-Server | Proxy-Port falsch oder Firewall sperrt den Ausgang | Adresse erneut aus dem Dashboard kopieren, Freigabe für diesen Port prüfen |
| `407 Proxy Authentication Required` | Proxy | Passwort falsch, Sonderzeichen nicht kodiert oder IP fehlt in der Whitelist | Zugangsdaten in die Adresse schreiben, prozentkodiert |
| `400 Bad Request` (nur bei HTTPS-Zielen) | Proxy | Der Client schickt die Anfrage direkt an den Proxy, statt einen Tunnel zu öffnen | n8n aktualisieren; siehe Hinweis unten |
| `ETIMEDOUT` / `ECONNRESET` | Netzwerk | Proxy nicht erreichbar oder Ziel sehr langsam | Options → Timeout erhöhen, einen näheren Ausgangsstandort wählen |
| `ENOTFOUND` | DNS | Hostname des Proxys falsch geschrieben | Namen aus dem Dashboard kopieren und neu eintragen |
| `403` / `429` vom Ziel | Zielseite | Der Proxy funktioniert; das Problem ist Tempo oder IP-Typ | Mit Batching und Wait drosseln, Ursache eingrenzen |

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](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/CONNECT) zu öffnen. [Issue #9169](https://github.com/n8n-io/n8n/issues/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](/de/blog/proxy-server-not-responding).

## 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](/de/price-monitoring).
- **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](https://proxynet.io/de/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](/de/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?](/de/blog/is-data-web-scraping-legal) zusammen.

## Entscheidungshilfe

| Bedarf | Empfehlung |
|---|---|
| Ich nutze n8n Cloud, ein einzelner Node soll über den Proxy hinausgehen | HTTP Request → Options → Proxy, mit Benutzername und Passwort |
| In n8n self-hosted sollen alle Nodes über den Proxy hinausgehen | `HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY`; danach Node für Node prüfen |
| Es gibt eine globale Einstellung, aber ein Node soll aus einem anderen Land kommen | Option Proxy in diesem Node; sie überschreibt die globale Einstellung |
| Bei jeder Anfrage eine andere IP | Rotierender Endpunkt; keine Rotation im Code-Node schreiben |
| Die Gegenseite gibt meine IP frei | Proxy mit fester IP (ISP) oder eigener Server mit fester IP |
| Die Seite lädt per JavaScript, der HTML-Node bleibt leer | HTTP Request reicht nicht; Browser-Automatisierung oder der JSON-Endpunkt im Hintergrund der Seite |

## 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](/de/proxy) vergleichen.