n8n Webhook 404 beheben: Test-URL bis Dynamic Path

Was bedeutet ein 404 vor der Workflow-Ausführung?

Ein n8n Webhook kann korrekt eingerichtet aussehen und trotzdem mit einem 404 antworten. Besonders verwirrend wird es, wenn der Workflow aktiv ist, die URL plausibel aussieht und trotzdem keine einzige Workflow-Ausführung erzeugt wird.

Die gute Nachricht: Ein 404 bedeutet nicht automatisch, dass dein Workflow falsch konfiguriert ist.

Bei n8n kann der Fehler bereits auf der Ebene der Webhook-Registrierung oder des Routings entstehen. Deshalb solltest du nicht einfach Nodes ändern oder den Workflow mehrfach veröffentlichen, sondern die möglichen Fehlerquellen systematisch von außen nach innen prüfen.

In diesem Leitfaden gehen wir genau diese Reihenfolge durch: Test-URL → Production-URL → Workflow-Status → HTTP-Methode → Webhook-Pfad → Dynamic Paths → Self-Hosting → Reverse Proxy → n8n Cloud.

Warum gibt n8n beim Webhook einen 404-Fehler zurück?

Ein Webhook ist ein HTTP-Endpunkt, über den ein externer Dienst einen n8n-Workflow auslösen kann.

Wenn du eine URL aufrufst, muss n8n zunächst den eingehenden Request einer registrierten Webhook-Route zuordnen. Erst danach kann der eigentliche Workflow ausgeführt werden.

Deshalb ist ein wichtiger Unterschied:

404 vor der Workflow-Ausführung ist etwas anderes als ein Fehler innerhalb des Workflows.

Wenn n8n beispielsweise meldet:

The requested webhook is not registered

und gleichzeitig keine Execution entsteht, deutet das darauf hin, dass der Request die Workflow-Logik noch gar nicht erreicht hat.

Genau dieses Verhalten wurde auch in einem aktuellen n8n-Cloud-Fall aus August 2026 dokumentiert: Der Production Webhook antwortete mit 404, obwohl der Workflow aktiv war. Laut der dort gegebenen technischen Erklärung lag das Problem bei der registrierten Webhook-Route.

1. Test-URL und Production-URL sind nicht dasselbe

Das ist die erste Prüfung, wenn ein n8n Webhook nicht funktioniert.

Der Webhook Node stellt unterschiedliche URLs für Tests und den produktiven Betrieb bereit.

Test-URL

Die Test-URL verwendest du während der Entwicklung eines Workflows.

Sie ist dafür gedacht, einen Webhook während des Testens zu empfangen und die eingehenden Daten direkt im Editor zu prüfen.

Production-URL

Die Production-URL ist für den tatsächlich aktivierten Workflow vorgesehen.

Wenn ein externer Dienst dauerhaft deinen Workflow aufrufen soll, musst du die Production-URL verwenden.

Warum ist diese Unterscheidung wichtig?

Ein häufiger Fehler ist:

1. Webhook Node erstellen
2. Test-URL kopieren
3. Request funktioniert
4. Workflow später aktivieren
5. dieselbe URL als dauerhaften Endpoint verwenden

Das führt zu einem falschen Testaufbau.

Merksatz:

Test-Webhook für Tests, Production-Webhook für den laufenden Workflow.

Auch bei Self-Hosting solltest du wissen: Sowohl Test- als auch Production-URL werden aus derselben Basis-URL gebildet (N8N_WEBHOOK_URL, ersatzweise N8N_HOST/N8N_PORT). Verwechsle das nicht mit N8N_EDITOR_BASE_URL – diese Variable betrifft nur die Editor-Oberfläche bei Subpath-Deployments, nicht die Webhook-URLs.

2. Ist der Workflow aktiviert?

Für einen Production Webhook reicht es nicht, dass der Workflow im Editor gespeichert ist.

Prüfe deshalb:

• Ist der Workflow aktiviert?
• Verwendest du tatsächlich die Production-URL?
• Hast du nach Änderungen die aktuelle Version veröffentlicht bzw. aktiviert?
• Testest du nicht versehentlich noch eine alte URL?

Wenn du einen Workflow gerade erst geändert hast, solltest du außerdem sicherstellen, dass der Endpoint aus der aktuell verwendeten Webhook-Konfiguration stammt.

Ein wichtiger Hinweis:

Ein wiederholtes Deaktivieren und Aktivieren ist kein universelles Heilmittel für einen 404.

In einem aktuellen n8n-Cloud-Fall wurde genau dieses Vorgehen mehrfach getestet, ohne das Routing-Problem zu lösen.

Wenn der Request überhaupt keine Execution erzeugt, solltest du deshalb die Webhook-Route prüfen, bevor du die Workflow-Logik veränderst.

3. Stimmt die HTTP-Methode?

Der nächste Punkt wird häufig übersehen.

Ein Webhook kann beispielsweise für:

• GET
• POST
• PUT
• PATCH
• DELETE

konfiguriert sein.

Wenn dein Webhook Node auf POST eingestellt ist, du aber einen GET-Request sendest, passt die Anfrage nicht zur erwarteten Route.

Beispiel

Dein Webhook erwartet:

POST /webhook/kunden

Du testest aber:

GET /webhook/kunden

Dann ist die URL allein noch nicht ausreichend. HTTP-Methode und Webhook-Konfiguration müssen zusammenpassen.

Auch in der n8n Community finden sich Fälle, in denen ein vermeintlicher Webhook-404 auf eine falsche HTTP-Methode zurückgeführt wurde.

Deshalb:

Nicht nur die URL prüfen. Immer auch die HTTP-Methode prüfen.

4. Stimmt der Webhook-Pfad?

Jetzt wird es interessanter.

Angenommen, dein Webhook Path lautet:

kunden

Dann ist die erwartete Route grundsätzlich einfach:

/webhook/kunden

Wenn du den Path später änderst, muss auch der externe Dienst die neue URL verwenden.

Das betrifft beispielsweise:

• Formulare
• CRM-Systeme
• Zahlungsanbieter
• API-Clients
• eigene Anwendungen
• HTTP Request Nodes

Wichtig: Nicht raten

Wenn du die richtige URL nicht sicher kennst, öffne den Webhook Node und lasse dir die Production URL anzeigen.

Verwende genau diese URL.

Das ist zuverlässiger als eine URL manuell aus:

Domain + /webhook/ + Path

zusammenzubauen.

5. Dynamic Paths können einen 404 besonders schwer nachvollziehbar machen

Hier liegt eine der interessanteren Ursachen für einen n8n Webhook 404.

Ein Webhook Path kann nicht nur statisch sein.

Beispielsweise:

kunden/:customer_id

Auf den ersten Blick könnte man daraus ableiten:

/webhook/kunden/123

Doch genau hier solltest du vorsichtig sein.

Warum?

Bei bestimmten Route-Parameter-Konfigurationen kann n8n die Webhook-Route intern anders registrieren.

Ein aktueller Fall aus der n8n Community vom 26. August 2026 zeigt genau dieses Problem. Der Webhook hatte den Path:

ai-secretary/:business_id

und war aktiv.

Der entscheidende Hinweis der Antwort war, dass n8n bei einem solchen Route Parameter die Webhook Node ID vor dem eigentlichen Path in die registrierte Route aufnehmen kann. In dem konkreten Fall wurde die Route daher sinngemäß mit einer Struktur wie dieser registriert:

/webhook/<webhook-node-id>/ai-secretary/:business_id

während der Nutzer eine URL ohne diesen ID-Teil aufrief.

Das Ergebnis war:

HTTP 404
The requested webhook ... is not registered.

Und besonders wichtig: Es wurde keine Workflow Execution erzeugt, weil der Request bereits auf der Routing-Ebene scheiterte.

Diese Erklärung stammt aus der n8n-Community und deckt sich mit einem unabhängigen, älteren Bugreport zum gleichen Verhalten – die offizielle n8n-Dokumentation beschreibt diesen Mechanismus derzeit nicht explizit.

Was solltest du daraus lernen?

Wenn du einen Dynamic Path verwendest und ein Production Webhook plötzlich 404 liefert:

1. Öffne den Webhook Node.
2. Schalte auf Production URL.
3. Kopiere die dort angezeigte URL vollständig.
4. Vergleiche sie mit der URL, die dein externer Dienst tatsächlich aufruft.
5. Prüfe insbesondere den Bereich zwischen /webhook/ und deinem eigentlichen Path.
6. Ersetze den Route Parameter durch einen echten Wert, beispielsweise 123 oder abc123.

Nicht die URL aus dem Path-Feld selbst rekonstruieren.

Das ist besonders wichtig bei produktiven Integrationen.

6. Woran erkennst du, ob der Fehler vor dem Workflow liegt?

Das ist einer der wichtigsten Diagnosepunkte.

Öffne in n8n die Executions und prüfe, ob dein Request dort auftaucht.

n8n stellt eine eigene Übersicht für Workflow Executions bereit, über die du unter anderem nach Workflow und Status filtern kannst.

Fall A: Eine Execution existiert

Dann hat der Request den Workflow erreicht.

Der Fehler kann jetzt innerhalb des Workflows liegen, beispielsweise bei:

• Credentials
• Expressions
• HTTP Requests
• Datenverarbeitung
• einem anderen Node

Der Webhook selbst ist dann wahrscheinlich nicht mehr deine erste Fehlerquelle.

Fall B: Keine Execution existiert

Wenn dein Request 404 zurückgibt und überhaupt keine Execution entsteht, solltest du zuerst die Webhook-Schicht untersuchen:

Request
   ↓
Webhook Routing
   ↓
Workflow
   ↓
Execution

Wenn der Request bereits beim Routing abgewiesen wird, helfen Änderungen an nachfolgenden Nodes nicht.

Genau dieses Muster wurde auch im genannten Production-Webhook-Fall beobachtet.

7. n8n Webhook funktioniert trotz aktivem Workflow nicht

Jetzt kommen wir zu dem Fall, der besonders verwirrend ist:

• Workflow ist aktiv
• Webhook Node existiert
• HTTP-Methode stimmt
• URL sieht korrekt aus
• trotzdem 404

Hier solltest du nicht automatisch davon ausgehen, dass die Workflow-Logik defekt ist.

Prüfe stattdessen erneut die tatsächlich registrierte Route.

„The requested webhook is not registered“

Diese Meldung ist diagnostisch wichtig.

Sie bedeutet nicht einfach:

„Irgendwas im Workflow ist kaputt.“

Sie weist vielmehr darauf hin, dass n8n die angeforderte Webhook-Route zum Zeitpunkt des Requests nicht passend registriert bzw. gefunden hat.

Bei Dynamic Paths kann die tatsächlich registrierte Route von der URL abweichen, die du selbst aus dem Path ableitest.

8. Self-Hosting: Reverse Proxy als Fehlerquelle

Wenn du n8n selbst hostest, kommt eine weitere Ebene hinzu.

Typischer Aufbau:

Internet
   ↓
HTTPS / Port 443
   ↓
Nginx / Caddy / anderer Reverse Proxy
   ↓
n8n intern

n8n läuft intern beispielsweise auf Port 5678, während dein Reverse Proxy die öffentliche HTTPS-Adresse bereitstellt.

Das kann dazu führen, dass die intern erzeugte Webhook-Adresse nicht der tatsächlich öffentlich erreichbaren Adresse entspricht.

Die offizielle n8n-Dokumentation beschreibt genau dieses Szenario: Hinter einem Reverse Proxy sollte die öffentliche Webhook-Adresse explizit konfiguriert werden. In der aktuellen Dokumentation wird dafür N8N_WEBHOOK_URL verwendet; WEBHOOK_URL ist inzwischen als veraltet (deprecated) gekennzeichnet. Zusätzlich wird N8N_PROXY_HOPS sowie die Weitergabe bestimmter X-Forwarded-* Header beschrieben.

Wichtiger Punkt zur aktuellen Konfiguration

Bei aktuellen n8n-Versionen solltest du nicht blind alte Tutorials kopieren, die ausschließlich:

WEBHOOK_URL

empfehlen.

Die aktuelle Dokumentation führt:

N8N_WEBHOOK_URL

als bevorzugte Variable und weist darauf hin, dass WEBHOOK_URL ab n8n 2.35.0 deprecated ist.

Zusätzlich relevant

Bei einem Reverse Proxy nennt die n8n-Dokumentation unter anderem:

N8N_PROXY_HOPS=1

für einen einzelnen Proxy sowie die Weitergabe von:

X-Forwarded-For
X-Forwarded-Host
X-Forwarded-Proto

an n8n.

Wenn du Self-Hosting verwendest und die im Editor angezeigte Production URL nicht zu deiner tatsächlich öffentlichen Domain passt, solltest du deshalb zuerst die Reverse-Proxy-Konfiguration überprüfen.

9. n8n Cloud: Was, wenn deine Konfiguration korrekt ist?

Auch bei n8n Cloud solltest du nicht automatisch davon ausgehen, dass jeder 404 durch deine Workflow-Konfiguration verursacht wird.

Ein aktueller Community-Fall aus August 2026 zeigt ein Szenario, bei dem:

• der Workflow aktiv war,
• die Version korrekt erschien,
• die Webhook-Methode stimmte,
• der Path plausibel war,
• trotzdem 404 zurückkam,
• und keine Execution entstand.

In so einem Fall liegt die relevante Fehlerquelle möglicherweise außerhalb der eigentlichen Workflow-Logik, beispielsweise in der Webhook-Registrierung oder Routing-Schicht.

Das bedeutet nicht, dass jeder Cloud-404 ein n8n-Problem ist.

Es bedeutet:

Wenn du alle lokalen Konfigurationspunkte geprüft hast und der Request weiterhin vor jeder Execution mit 404 abgewiesen wird, solltest du auch die Cloud-Seite als mögliche Fehlerquelle berücksichtigen.

10. Die schnelle Checkliste für n8n Webhook 404

Wenn dein Webhook 404 zurückgibt, arbeite diese Reihenfolge ab:

Basisprüfung

• Verwende ich die Production URL oder absichtlich die Test-URL?
• Ist der Workflow aktiviert?
• Stimmt die HTTP-Methode?
• Stimmt der Webhook Path?
• Kopiere ich die URL direkt aus dem Webhook Node?

Dynamic Path

• Enthält der Path einen Route Parameter wie :id?
• Habe ich die vollständige Production URL aus n8n übernommen?
• Enthält die registrierte Route zusätzliche Elemente wie die Webhook Node ID?
• Ersetze ich :id beim tatsächlichen Request durch einen konkreten Wert?

Diagnose

• Wird eine Execution erzeugt?
• Wenn nein: liegt der Fehler möglicherweise vor der Workflow-Ausführung?
• Wenn ja: liegt das Problem wahrscheinlich innerhalb des Workflows?

Self-Hosting

• Läuft n8n hinter einem Reverse Proxy?
• Ist N8N_WEBHOOK_URL korrekt gesetzt?
• Ist N8N_PROXY_HOPS korrekt?
• Werden die benötigten X-Forwarded-* Header weitergereicht?

Cloud

• Ist der Workflow wirklich aktiv?
• Ist die Production URL aktuell?
• Wurde die Route nach Änderungen korrekt veröffentlicht?
• Besteht der 404 weiterhin ohne irgendeine Execution?

Häufige Fragen zu n8n Webhooks

Warum funktioniert der n8n Test-Webhook, aber die Production-URL nicht?

Weil Test- und Production-Webhooks unterschiedliche Betriebsbedingungen haben.

Der Test-Webhook ist für die Entwicklung und das Testen im Editor gedacht. Der Production Webhook ist an den aktivierten Workflow gebunden.

Bei Self-Hosting kommt zusätzlich die Konfiguration der öffentlichen Webhook-URL hinzu. n8n dokumentiert dafür die separate Konfiguration von N8N_WEBHOOK_URL.

Warum zeigt n8n beim Webhook 404 statt 401 oder 403?

Ein 401 oder 403 weist typischerweise auf eine Authentifizierungs- bzw. Berechtigungsprüfung hin.

Ein 404 mit einer Meldung wie:

The requested webhook is not registered

ist dagegen zunächst ein Hinweis darauf, dass die angeforderte Webhook-Route nicht gefunden bzw. nicht passend registriert wurde.

Deshalb solltest du bei einem solchen Fehler zuerst URL, Methode, Path und Registrierung prüfen.

Kann ein Reverse Proxy einen n8n Webhook kaputt machen?

Ja, eine fehlerhafte Reverse-Proxy-Konfiguration kann dazu führen, dass n8n die öffentliche Webhook-Adresse nicht korrekt kennt oder Requests nicht korrekt weitergeleitet werden.

Die n8n-Dokumentation beschreibt für Reverse-Proxy-Setups ausdrücklich die Konfiguration von N8N_WEBHOOK_URL, N8N_PROXY_HOPS und den relevanten Forwarding-Headern.

Was bedeutet ein Dynamic Path wie :customer_id?

Ein Dynamic Path ermöglicht es, einen variablen Wert als Teil des Webhook-Pfads zu verwenden.

Beispielsweise:

kunden/:customer_id

kann bei einem echten Request einen konkreten Wert enthalten.

Bei solchen Pfaden solltest du die tatsächlich von n8n angezeigte Production URL verwenden, statt den Endpoint manuell aus dem Path-Feld zu konstruieren.

Der aktuelle Community-Fall vom August 2026 zeigt, warum diese Unterscheidung wichtig sein kann: Bei einem Route Parameter war die registrierte Route mit der Webhook Node ID aufgebaut, während der aufgerufene Endpoint diese Komponente nicht enthielt.

Warum sehe ich keine Execution?

Wenn der Request bereits auf der Webhook-Routing-Ebene mit 404 abgewiesen wird, erreicht er den Workflow nicht.

Deshalb kann eine fehlende Execution selbst ein wichtiger Diagnosehinweis sein.

Prüfe zuerst die Webhook-Route, bevor du Nodes innerhalb des Workflows änderst.

Fazit: n8n Webhook 404 Schritt für Schritt lösen

Ein 404 bei einem n8n Webhook ist nicht automatisch ein Fehler in deiner Workflow-Logik.

Die effizienteste Diagnose beginnt außen und arbeitet sich nach innen:

1. Test-URL oder Production-URL?
2. Workflow aktiv?
3. HTTP-Methode korrekt?
4. Webhook Path korrekt?
5. Dynamic Path vorhanden?
6. Tatsächliche Production URL aus dem Webhook Node geprüft?
7. Wird eine Execution erzeugt?
8. Bei Self-Hosting: Reverse Proxy und N8N_WEBHOOK_URL geprüft?
9. Bei Cloud: Besteht der Fehler trotz korrekter Konfiguration weiterhin auf Routing-Ebene?

Besonders bei Dynamic Paths solltest du nicht versuchen, die Webhook-URL selbst zu erraten. Kopiere die aktuelle Production URL direkt aus n8n und vergleiche sie mit dem Endpoint, den dein externer Dienst tatsächlich aufruft.

Wenn ein Request weiterhin mit 404 abgewiesen wird und keine Execution entsteht, ist die Webhook-Routing-Ebene der wichtigste nächste Prüfpunkt.

Für die aktuelle technische Referenz solltest du bei Self-Hosting die offizielle n8n-Dokumentation zur Konfiguration von Webhooks hinter einem Reverse Proxy heranziehen.