Am 29. April hat meine Mutter den Workflow von der Webseite aus ausgelöst, aber diese Ausführung wird in n8n nicht angezeigt und hat auch nicht ordnungsgemäß funktioniert. Wenn ich jedoch denselben Workflow von der Webseite aus selbst ausführe, funktioniert er ohne Probleme.
Ich möchte verstehen, warum das passieren kann:
warum eine Ausführung möglicherweise nicht gespeichert oder angezeigt wird,
warum es bei mir funktioniert, aber nicht bei einer anderen Person,
und ob dies mit Berechtigungen, Authentifizierung, Sitzung oder der Art der Workflow-Auslösung zusammenhängen könnte.
Wenn jemand etwas Ähnliches erlebt hat, würde ich mich wirklich über Hilfe freuen.
Dies ist ein häufiges Szenario in der Automatisierung, bei dem “Es funktioniert auf meinem Rechner” zur Realität der Fehlerbehebung wird. Da die Ausführung überhaupt nicht in der n8n-Verlauf angezeigt wird, deutet dies darauf hin, dass das Problem vor der vollständigen Verarbeitung der Workflow-Logik oder während der Übergabe zwischen der Webseite und dem n8n-Webhook auftritt.
Hier ist eine Aufschlüsselung der möglichen Gründe, kategorisiert danach, wo der Fehler wahrscheinlich aufgetreten ist.
1. Warum eine Ausführung möglicherweise nicht gespeichert oder angezeigt wird
Wenn eine Ausführung nicht im n8n-Tab “Executions” angezeigt wird, bedeutet dies normalerweise eines von drei Dingen:
o Die Anfrage hat n8n nie erreicht: Der Trigger (Webhook-Node) hat die HTTP-Anfrage nie erfolgreich empfangen. Wenn die Anfrage durch eine Firewall, einen CORS-Fehler oder ein Netzwerkproblem blockiert wurde, hat n8n sie nie “gesehen”, daher konnte kein Ausführungsdatensatz erstellt werden.
o Fehler während der “Trigger”-Phase: Wenn der Fehler im Webhook-Node selbst auftritt (z. B. eine Nichtübereinstimmung in erwarteten Headern oder ein Authentifizierungsfehler auf Serverebene), kann n8n die Anfrage mit einem 401-, 403- oder 404-Fehler ablehnen, bevor die Workflow-Engine überhaupt eine formale “Ausführung” startet.
o n8n-Konfigurationseinstellungen: In n8n gibt es eine Einstellung zum “Speichern erfolgreicher Ausführungen”. Wenn der Workflow tatsächlich erfolgreich war, aber einen Fehler hatte, der ihn fehlerhaft aussehen lässt, und Sie “Erfolgreiche Ausführungen speichern” deaktiviert haben, werden Sie ihn nicht sehen. Da Sie jedoch erwähnt haben, dass es “nicht ordnungsgemäß funktioniert hat”, ist ein Fehler wahrscheinlicher.
2. Warum es für Sie funktioniert, aber nicht für eine andere Person
Dies weist auf Unterschiede in der Client-Seite (dem Browser/Gerät) oder der Netzwerkumgebung hin.
o CORS-Probleme (Cross-Origin Resource Sharing): Dies ist der wahrscheinlichste Schuldige. Wenn die Webseite auf domain-a.com gehostet wird und Ihr n8n auf domain-b.com läuft, führt der Browser eine “Preflight”-Überprüfung durch. Wenn Ihr Browser eine zwischengespeicherte Berechtigung oder eine andere Sicherheitskonfiguration hat, kann diese bestanden werden, während ihr Browser (möglicherweise mit strengeren Datenschutzeinstellungen oder anderen Erweiterungen) die Anfrage blockiert.
o Nutzlast-/Datenschiede: Wenn Ihre Mutter den Workflow auslöst, gibt sie genau die gleichen Daten wie Sie ein? Wenn die Webseite ein Formular sendet und sie ein Sonderzeichen eingibt, ein Feld leer lässt oder einen Wert eingibt, der ein Schema verletzt (z. B. eine Zeichenkette, wenn eine Zahl erwartet wird), kann der Workflow beim ersten Node abstürzen.
o Authentifizierung & Sitzungen:
o Cookies/Token: Wenn die Webseite auf einem Sitzungs-Cookie oder einem Bearer-Token angewiesen ist, um den Trigger zu autorisieren, und ihre Sitzung ist abgelaufen oder sie ist nicht korrekt angemeldet, wird die Anfrage abgelehnt.
o IP-Whitelist: Wenn sich Ihre n8n-Instanz hinter einer Firewall befindet, die nur bestimmte IP-Adressen zulässt, kann Ihre IP zugelassen sein, während die ihre (in einem anderen Netzwerk oder VPN) blockiert wird.
o Browser-Erweiterungen/Ad-Blocker: Viele Ad-Blocker oder Datenschutzerweiterungen (wie uBlock Origin oder Brave Browser Shields) unterbrechen “ungewöhnliche” ausgehende Anfragen. Wenn die Webhook-URL wie ein Tracking-Script in ihrem Browser aussieht, wird sie blockiert, bevor sie ihren Computer verlässt.
3. Zusammenfassung Checkliste zur Fehlerbehebung
Um die genaue Ursache zu finden, empfehle ich, in dieser Reihenfolge zu untersuchen:
Sehr gründlich, @Rafael_Van_Meerbeek ich bin zu 95% sicher, dass dein Problem behoben wird, wenn du die Empfehlungen von @kjooleng befolgst. Was die restlichen 5% betrifft, könntest du versuchen, den Trigger-Knoten zu löschen und mit einem neuen zu beginnen.
Hey, vielen Dank, das hat mir sehr geholfen, jetzt funktioniert es wieder. Mir ist aber aufgefallen, dass wenn ich den Workflow offen habe, der Status zwischen “Verbindung unterbrochen” und “Normal” jede Sekunde wechselt, wie in den Screenshots und den Prod.-Ausführungen zu sehen ist. Kannst du mir erklären, warum das passiert?
die Verbindungsunterbrechungen mit Flimmern während des offenen Workflows sind normalerweise ein Websocket-Stabilitätsproblem. häufige Ursachen bei selbst gehostet docker: nginx nicht für websocket-upgrades konfiguriert, oder ein proxy-timeout kürzer als das keepalive-intervall.
prüfe, ob deine nginx-konfiguration proxy_http_version 1.1 und die Upgrade- und Connection-header korrekt gesetzt hat. wenn du einen load balancer oder reverse proxy mit kurzem timeout hast, ist das fast immer die ursache. die verbindung wird unterbrochen, reconnektiert, wird unterbrochen alle paar sekunden wiederholt.
Die „Verbindung unterbrochen