After a recent server migration, my n8n Cloud workflows stopped working. The HTTP Request node returns the following error when trying to reach my server:
getaddrinfo EAI_AGAIN server1.myserver.com
What I tested:
Postman: works fine, returns 200
curl from the server itself: works fine
Browser: works fine
DNS lookup via 8.8.8.8: resolves correctly
IP is not blacklisted (checked AbuseIPDB: 0% abuse confidence)
Firewall is open to all IPs
Tried using the IP directly: SSL error
Tried the server reverse hostname: same EAI_AGAIN
Everything was working before the migration. The server is hosted on a cloud provider in Brazil.
Has anyone experienced this? Could n8n Cloud have any internal DNS restriction or cache issue that would explain this?
@VianaCom_Publicidade EAI_AGAIN is a temporary resolver failure, not “domain not found”, so n8n Cloud’s resolver is timing out on the lookup rather than the domain being missing. since it only broke after the migration and works everywhere else, its usually either n8n’s resolver holding a stale negative-cache from while the domain was moving, or your new nameservers not answering every resolver the same. quick check, does it resolve cleanly across all the resolvers on dnschecker.org, not just 8.8.8.8? if its green everywhere then its n8n Cloud’s resolver cache, and since you cant flush that on Cloud its worth a ticket to help@n8n.io.
Since Postman/browser work and only n8n Cloud fails after the migration, treat this as resolver/cache until proven otherwise. Check the domain at the authoritative nameservers and one non-Google resolver; if both are clean, keep the execution id and timestamp for the n8n support ticket, not the public thread.
Do not switch the HTTP node to the raw IP unless the server has a cert for that IP. That test creates a separate TLS error and hides the DNS problem.
Since Postman and external browsers resolve the domain perfectly fine, the issue is narrowed down to how n8n Cloud’s infrastructure is communicating with your new server’s DNS setup. EAI_AGAIN means the DNS lookup is timing out, which typically points to one of two things after a server migration:
Stale Resolver Cache: n8n Cloud’s DNS cache may be holding an old lookup record from during the migration window. If it doesn’t clear up automatically, you will likely need to open a quick ticket with support (help@n8n.io) to have them look at the instance routing table.
Data Center/Firewall Dropping Queries: Ensure your new hosting provider in Brazil isn’t dropping inbound API traffic or DNS validation checks originating from typical cloud subnets (AWS/Hetzner) where n8n infrastructure lives.
This video provides general insight into installing and configuring nodes within n8n Cloud environments, which can be helpful if you need to set up alternative HTTP or custom network tracking methods.
