Bei meiner Cloud-Instanz (die.app.n8n.cloud) schlägt die zweite HTTP-Request fehl, wenn ich 2 oder mehr HTTP Request-Knoten nacheinander in derselben Workflow-Ausführung verkette. Die erste ist immer erfolgreich, die zweite schlägt jedoch immer mit ECONNREFUSED fehl.
Dies geschieht auch dann, wenn die beiden Anfragen auf völlig unabhängige Domains abzielen — ich habe dies bestätigt, indem ich die zweite Anfrage auf https://jsonplaceholder.typicode.com/posts (eine öffentliche Test-API, nicht mit meinem Hauptanwendungsfall verbunden) verwiesen habe, und sie schlug auf die gleiche Weise fehl, wobei die korrekte Cloudflare-IP aufgelöst wurde (188.114.96.3), aber die Verbindung verweigert wurde.
n8n-Version: 2.31.5 (Cloud)
Knotentyp: HTTP Request, Version 4.2
Fehler: NodeApiError: Der Dienst hat die Verbindung verweigert — möglicherweise ist er offline / connect ECONNREFUSED [ip]:443
Beschreiben Sie das Problem/den Fehler/die Frage
Welche Fehlermeldung erhalten Sie (falls vorhanden)?
Bitte teilen Sie Ihren Workflow
(Wählen Sie die Knoten auf Ihrer Leinwand aus und verwenden Sie die Tastaturkürzel CMD+C/STRG+C und CMD+V/STRG+V, um den Workflow zu kopieren und einzufügen.)
Geben Sie die von dem letzten Knoten zurückgegebene Ausgabe an
Hallo @Dorian_BRIANCON Willkommen!
ECONNREFUSED ist ein aktives TCP-Reset bei der Verbindung, kein Timeout oder ein Firewall-Drop, und Cloudflares Edge weigert sich nicht, 443 von n8n Cloud zu akzeptieren. Die Anfrage verlässt nicht den Ort, wo du denkst, dass sie es tut, was auf den Node und nicht auf die Ausführung hindeutet. Überprüfe die Optionen auf dem fehlerhaften Node auf einen Proxy-Eintrag. Ein Proxy, der dort gesetzt ist, überschreibt alles andere und weigert sich bei der Verbindung, egal welchen Host du anvisierst, während der Fehler immer noch die aufgelöste Ziel-IP ausgibt, die mit dem übereinstimmt, was du mit jsonplaceholder gesehen hast.
Um zu bestätigen, dass es der Node und nicht die Position ist, vertausche die beiden HTTP-Request-Nodes, damit der fehlerhafte zuerst ausgeführt wird. Wenn der Fehler dem Node folgt, ist es die Konfiguration dieses Nodes. Wenn es an der zweiten Position bleibt, ist es instanzseitig, also sende help@n8n.io die Execution ID und den Zeitstempel eines fehlgeschlagenen Laufs.
ECONNREFUSED deutet normalerweise auf eine Ablehnung auf Netzwerkebene hin. Da dies über unabhängige Domains hinweg auftritt und nur beim zweiten sequenziellen Node passiert, ist dies wahrscheinlich kein DNS- oder Zielserver-Problem, sondern ein Socket-Erschöpfungs- oder Connection-Pooling-Konflikt innerhalb des spezifischen Execution-Container, der deiner Cloud-Instanz zugewiesen ist.
Die häufigste Ursache für sequenzielle ECONNREFUSED in gemeinsam genutzten Umgebungen ist das schnelle Öffnen/Schließen von Sockets. Das Hinzufügen einer kleinen Verzögerung zwischen Anfragen behebt oft den Socket-Status.
Aktion: Füge einen Wait Node zwischen dem ersten und zweiten HTTP Request Node ein.
Einstellung: Stelle die Wartezeit auf 1 oder 2 Sekunden ein.
Grund: Dies ermöglicht es der zugrunde liegenden Node.js Event Loop und dem Netzwerk-Proxy deiner Cloud-Instanz, die vorherige Verbindung vollständig freizugeben, bevor die nächste versucht wird.
Wenn du eine Liste von Elementen verarbeitest, verkette HTTP-Nodes nicht linear. Verwende stattdessen einen Split In Batches Node oder eine Loop, um Anfragen zu verarbeiten.
Aktion:
Verwende einen Split In Batches Node (Batch Size: 1).
Platziere den HTTP Request Node innerhalb der Schleife.
Schleife zurück zum Split In Batches Node.
Grund: Dies zwingt n8n, die Ausführung in unterschiedlichen Chunks zu verarbeiten, was die „Stauung
Kurzes Follow-up: Die Lösung, die funktioniert hat, war, die HTTP Request-Knoten vollständig durch einen Code-Knoten zu ersetzen, der this.helpers.httpRequest für die sequenziellen Aufrufe verwendet, eingebunden in eine await-Schleife mit 1-Sekunden-Verzögerung zwischen den Anfragen. Dies führte 5 sequenzielle GET-Anfragen an die gleiche Domain (jeweils 100 Elemente, ~423 Elemente insgesamt) erfolgreich in der gleichen Ausführung durch — kein ECONNREFUSED.
Um es weiter einzugrenzen: Der Bug scheint spezifisch für den HTTP Request-Knoten selbst zu sein (v4.2, wahrscheinlich gebunden an seine veralteten request-basierten Interna, wie im Stack Trace erwähnt — useStream, resolveWithFullResponse usw.), nicht für n8n Clouds Netzwerkebene als Ganzes. this.helpers.httpRequest von innerhalb eines Code-Knotens verwendet vermutlich den gleichen zugrunde liegenden HTTP-Client, funktionierte aber jedes Mal einwandfrei — daher könnte das Problem spezifisch darin liegen, wie der HTTP Request-Knoten (als eigenständiger visueller Knoten) seinen Verbindungs-/Socket-Status zwischen separaten Knotenausführungen in der gleichen Workflow-Ausführung verwaltet, statt ein rohes Netzwerk-/Instanz-Level-Problem zu sein.
Das könnte dir dabei helfen, es zu reproduzieren/isolieren: Es geht nicht um das Ziel, die Payload oder das Timing — es geht spezifisch um die Verkettung von 2+ HTTP Request-Knoten (der visuelle Knoten) nacheinander. Die gleiche Logik in einen einzelnen Code-Knoten zu wrappen umgeht das Problem vollständig.
Hoffentlich hilft das, die Grundursache für andere einzugrenzen, die auf die gleiche Hürde stoßen. Danke für die Anleitung!
Zwei Punkte in den Antworten sind es wert, sie zu trennen. Ein Wait-Node kann als Experiment nützlich sein, aber er beweist nicht, dass Node.js Zeit brauchte, um einen Socket freizugeben. Diese HTTP-Nodes laufen bereits sequenziell. Die Aufrufe in einen Code-Node zu verschieben ist auch in n8n Cloud keine Option. Der Cloud Code-Node kann keine HTTP-Anfragen stellen oder axios importieren.
Ich würde dies auf einen minimalen Workflow mit einem Manual Trigger und zwei HTTP Request-Nodes reduzieren. Verweise beide Request-Nodes auf denselben stabilen öffentlichen HTTPS-Endpunkt und gib ihnen identische Einstellungen. Führe zuerst nur den zweiten Node aus. Verbinde dann die erste Anfrage mit der zweiten und wiederhole mit umgekehrter Reihenfolge.
Wenn der Fehler bei einem Node bleibt, vergleiche seine Optionen und Anmeldedaten mit der funktionierenden Kopie. Wenn einer der Nodes nur dann ausfällt, wenn er zweiten ausgeführt wird, speichere die Execution ID mit ihrem Zeitstempel und sende den minimalen Workflow an Cloud-Support. Das isoliert die Ausführungsposition vom Ziel und von deiner ursprünglichen API.
Die aufgelöste Cloudflare IP zeigt dir, dass DNS erfolgreich war. ECONNREFUSED bedeutet, dass die TCP-Verbindung aktiv abgelehnt wurde. Eine Verzögerung kann das Symptom verbergen, erklärt aber keinen deterministischen Fehler bei der zweiten Anfrage.