Bonjour à tous,
Après une migration récente de serveur, mes workflows n8n Cloud ont cessé de fonctionner. Le nœud HTTP Request renvoie l’erreur suivante en essayant d’atteindre mon serveur :
getaddrinfo EAI_AGAIN server1.myserver.com
Ce que j’ai testé :
- Postman : fonctionne correctement, renvoie 200
- curl depuis le serveur lui-même : fonctionne correctement
- Navigateur : fonctionne correctement
- Recherche DNS via 8.8.8.8 : se résout correctement
- L’IP n’est pas sur liste noire (vérification sur AbuseIPDB : confiance en cas d’abus de 0 %)
- Le pare-feu est ouvert à toutes les IPs
- Tentative avec l’IP directement : erreur SSL
- Tentative avec le nom d’hôte inversé du serveur : même EAI_AGAIN
Tout fonctionnait avant la migration. Le serveur est hébergé chez un fournisseur de cloud au Brésil.
Quelqu’un d’entre vous a-t-il rencontré ce problème ? n8n Cloud pourrait-il avoir une restriction DNS interne ou un problème de cache qui expliquerait cela ?
@VianaCom_Publicidade EAI_AGAIN est une défaillance temporaire du résolveur, pas « domaine non trouvé », donc le résolveur d’n8n Cloud expire sur la requête au lieu que le domaine soit manquant. puisque cela n’a cessé de fonctionner qu’après la migration et que ça marche partout ailleurs, c’est généralement soit le résolveur d’n8n qui conserve un cache négatif obsolète depuis que le domaine était en transit, soit vos nouveaux serveurs de noms qui ne répondent pas de la même façon à chaque résolveur. vérification rapide, est-ce que c’est résolu correctement sur tous les résolveurs sur dnschecker.org, pas seulement sur 8.8.8.8 ? si c’est au vert partout alors c’est le cache du résolveur d’n8n Cloud, et comme tu ne peux pas le vider sur Cloud, ça vaut le coup de soumettre un ticket à help@n8n.io.
Puisque Postman/navigateur fonctionnent et seul n8n Cloud échoue après la migration, traitez ceci comme un problème de resolver/cache jusqu’à preuve du contraire. Vérifiez le domaine auprès des serveurs de noms autoritaires et d’un resolver non-Google ; si les deux sont corrects, conservez l’ID d’exécution et l’horodatage pour le ticket de support n8n, pas pour le fil public.
Ne basculez pas le nœud HTTP vers l’IP brute sauf si le serveur dispose d’un certificat pour cette IP. Ce test crée une erreur TLS distincte et masque le problème DNS.
Puisque Postman et les navigateurs externes résolvent le domaine sans problème, le problème se limite à la façon dont l’infrastructure n8n Cloud communique avec la configuration DNS de votre nouveau serveur. EAI_AGAIN signifie que la requête DNS expire, ce qui pointe généralement vers l’une de ces deux choses après une migration de serveur :
Cache de résolveur obsolète : Le cache DNS d’n8n Cloud peut conserver un ancien enregistrement de recherche de la période de migration. S’il ne s’efface pas automatiquement, vous devrez probablement ouvrir un ticket rapide auprès du support (help@n8n.io) pour qu’ils examinent la table de routage de l’instance.
Data Center/Firewall supprimant les requêtes : Assurez-vous que votre nouveau fournisseur d’hébergement au Brésil ne supprime pas le trafic API entrant ou les vérifications de validation DNS provenant des sous-réseaux cloud typiques (AWS/Hetzner) où réside l’infrastructure n8n.
Cette vidéo fournit des informations générales sur l’installation et la configuration de nœuds dans les environnements n8n Cloud, ce qui peut être utile si vous devez configurer des méthodes HTTP alternatives ou un suivi réseau personnalisé.