n8n in Docker: getaddrinfo EAI_AGAIN beim HTTP Request?

Ein HTTP-Request-Node scheitert mit getaddrinfo EAI_AGAIN, obwohl der Dienst vom Host oder Browser aus erreichbar erscheint. Der Fehler entsteht bei der Namensauflösung. Ein Test außerhalb des n8n-Containers untersucht deshalb möglicherweise eine andere Konfiguration als der betroffene Workflow.

Was der dokumentierte Fall zeigt

Ein historischer Bericht aus 2021 betrifft einen lokalen Dienstnamen in einer Docker-Umgebung. Nach Austausch gegen eine IP erschien ein Verbindungsfehler an einem anderen Port. Der Wechsel entfernte damit nicht automatisch das Gesamtproblem. Q1 Docker dokumentiert unterschiedliche DNS-Wege für Standard- und benutzerdefinierte Netzwerke. Node.js unterscheidet außerdem die Namensauflösung über Betriebssystemfunktionen von direkten DNS-Abfragen. Q2 Q3

Diese Anleitung behandelt eine konkrete Diagnoseklasse, keinen behaupteten aktuellen n8n-DNS-Bug. Entscheidend sind tatsächlich verwendeter Hostname, Netzwerk und Resolver.

Schrittweise eingrenzen

1. Hostname unverändert erfassen. Prüfe die nach Ausdrucksauswertung verwendete URL. Achte auf Tippfehler, Schema, Port und lokale Namenszusätze. Ein Name, den nur dein Arbeitsplatz kennt, muss nicht im Container existieren.
2. Im betroffenen Kontext testen. Lasse den Administrator die Auflösung aus dem n8n-Container beziehungsweise einem gleich konfigurierten Diagnosetool prüfen. Vergleiche mehrere zeitlich markierte Versuche mit einem Test auf dem Host. So wird sichtbar, ob der Fehler dauerhaft oder zeitweise auftritt.
3. Zieltyp bestimmen. Ist es ein öffentlicher Hostname, ein privater Firmenname oder ein weiterer Containerdienst? Für einen Docker-Dienst müssen Netzwerkzugehörigkeit und der dort gültige Dienstname zusammenpassen. Ein externer öffentlicher Resolver kennt private Namen nicht automatisch.
4. Resolver und Netzwerk beobachten. Vergleiche Container-DNS-Konfiguration, vorhandene Netzwerkzuordnung und Erreichbarkeit des zuständigen Resolvers. Ändere nicht global DNS-Server, bevor geklärt ist, welche privaten Zonen gebraucht werden.
5. Erst danach Verbindung prüfen. Bei erfolgreicher Auflösung folgt der Test des richtigen Dienstports. ECONNREFUSED, TLS-Fehler und HTTP-Statuscodes sind neue Befunde auf einer anderen Stufe; sie verlangen die jeweils passende Untersuchung.

Geeignete Korrektur

Ein falscher Dienstname wird korrigiert, ein fehlender gemeinsamer Netzwerkpfad gezielt ergänzt und ein nachgewiesener Resolverausfall beim Betreiber behoben. Eine fest eingetragene wechselnde Container-IP ist meist keine belastbare Lösung. Bei HTTPS kann ein IP-Ersatz zusätzlich den vorgesehenen Hostnamenbezug stören.

Häufige Fragen

Hilft ein sofortiger Retry?

Bei vorübergehender Störung möglicherweise; er erklärt die Ursache aber nicht. Begrenze Wiederholungen und beachte die Wirkung des gesamten Workflows.

Welche Informationen werden benötigt?

n8n- und Docker-Version, anonymisierte URL mit Port, Netzwerkaufbau, Zeitstempel und Vergleich der Auflösung innerhalb und außerhalb des Containers. Keine Zugangsdaten und keine vollständige interne Netzwerkliste veröffentlichen.

Unterstützung für diesen Fall

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