n8n HTTP Request: connect ETIMEDOUT trotz erreichbarer API?

Eine wichtige Integration hängt am HTTP-Request-Node. Dort steht connect ETIMEDOUT, während die Adresse vom Arbeitsplatz aus erreichbar wirkt. Wiederholungen und längere Wartezeiten helfen wenig, solange unklar bleibt, ob n8n überhaupt eine Verbindung zum richtigen Ziel herstellen kann.

Das Fehlerbild richtig lesen

Ein Originalbericht betrifft n8n Cloud 2.43.5: Der Workflow meldete einen Verbindungs-Timeout an Port 443, der Browser lieferte dagegen HTTP 405. Eine bestätigte Ursache enthält der Ausgangsbericht nicht. Q1 Node.js ordnet ETIMEDOUT einem nicht rechtzeitig beantworteten Verbindungs- oder Sendevorgang zu. Q2 Der Zusatz connect und der konkrete Zielport sind deshalb wichtige Diagnoseinformationen.

Ein HTTP-Status wie 405 zeigt, dass dieser Browser eine HTTP-Antwort erhalten hat. Das beweist weder die Erreichbarkeit aus n8n Cloud noch dieselbe Adresse, Methode, Weiterleitung oder Zugriffsregel.

Eine aussagekräftige Prüffolge

1. Aufruf festhalten. Sichere Zeitpunkt mit Zeitzone, Hostname, Zielport, Methode und den vollständigen Fehler ohne Geheimnisse. Vergleiche die aufgelöste URL nach Ausdrucksauswertung, nicht nur den sichtbaren Platzhalter im Editor.
2. Fehlerstufe unterscheiden. Liegt wirklich connect ETIMEDOUT vor? Ein zurückgegebenes 401, 403 oder 405 verlangt eine andere Untersuchung als ein Verbindungsabbruch. Ein langsamer Antwortinhalt ist wiederum ein eigener Fall.
3. Zielseite zum gleichen Zeitpunkt prüfen lassen. Der Betreiber kann Firewall-, Proxy- und Anwendungsprotokolle abgleichen. Fehlt der Aufruf schon am Netzrand, prüft er Routing, Adressauflösung und zugelassene Quellen. Ist er dort sichtbar, folgt die Strecke bis zur Anwendung.
4. Vergleich aus dem richtigen Umfeld herstellen. Bei eigener Installation erfolgt ein lesender Test aus dem n8n-Container beziehungsweise dessen Netzwerk. Bei Cloudbetrieb gib dem Support Instanz, Zeitpunkt und Zielhost; ein erfolgreicher Laptop-Test ersetzt diesen Vergleich nicht.
5. Mit einem neutralen Endpunkt eingrenzen. Nutze, sofern vom API-Betreiber vorgesehen, einen lesenden Statusaufruf auf demselben Host. Funktioniert dieser, untersuche anschließend den konkreten Pfad und dessen Verarbeitung. Verwende keine schreibende Bestellung als Netzwerktest.

Welche Maßnahme zum Befund passt

Eine nachgewiesene Quellenbeschränkung erfordert eine passende, möglichst enge Freigabe. Ein falscher Hostname oder Port erfordert eine Konfigurationskorrektur. Erst bei belegter langsamer Verarbeitung lohnt sich die Bewertung des Zeitlimits. Dauernde Retries können den Rückstau vergrößern und bei Schreibzugriffen unklare Doppelwirkungen erzeugen.

Häufige Fragen

Soll ich HTTPS durch HTTP ersetzen?

Nein. Damit änderst du Zielport und Sicherheitsmodell und untersuchst nicht mehr dieselbe Verbindung. Kläre die beabsichtigte HTTPS-Strecke.

Welche Angaben braucht der Support?

Fehlertext, Uhrzeit, n8n-Version, Cloud oder eigene Installation, geschwärzte URL, Methode und ein Ergebnisvergleich vom Zielbetreiber. API-Schlüssel bleiben vertraulich.

Unterstützung für diesen Fall

Wir helfen dir, den betroffenen Ablauf einzugrenzen und die nächste Maßnahme kontrolliert vorzubereiten. Fall A0053 mit KAN KAI WORKS besprechen.