G’day team – am running n8n@2.15.1 cloud hosted. Flows include several http node POST and GET calls to solutions including Klaviyo and TANDA.
Around a month ago started to get occaisional Message: connect ENETUNREACH errors on selected nodes and flows… not all of them, but enough to be getting ~6 failures per day across several hundred executions.
Have checked end points and no changes there. A ‘Retry’ of the node gets through it, so I’ve retrospectively switched on retry-on-failure and will monitor.
Has anyone else see an increase in such connectivity errors, with no other known changes to flows to integration points?
welcome to the n8n community @mr-alistair
I would keep Retry on Fail enabled on the affected HTTP nodes and add a short wait between retries (and, if those calls run in bursts, also use batching/throttling) since the n8n docs recommend retries and batch intervals for intermittent HTTP connectivity issues.
Thats almost certainly an IPv6 routing issue on the cloud side, I’d reach out to n8n support and ask them to force IPv4 on your instance. The retries will get you through for now but that should actually fix it
Adding to what achamm correctly pointed out — this is a classic Node.js behavior. Under the hood, the system occasionally tries to resolve the DNS over IPv6 (AAAA record) first. If the cloud container isn’t fully configured for IPv6 routing, it hits a dead end and throws the ENETUNREACH error. Reaching out to n8n Cloud support to force an IPv4 preference (--dns-result-order=ipv4first) is definitely the permanent fix.
A quick pro-tip for your temporary fix: You mentioned you turned on ‘Retry on Fail’. That is the perfect band-aid. However, if the node eventually succeeds on the 2nd or 3rd try, n8n will mark the execution as a “Success” and you won’t actually know how often this is happening anymore.
If you want to gather concrete data to show n8n support exactly how many times their network is dropping your calls, you can:
Turn on “Continue On Fail” in the HTTP node settings instead of just Retry.
Route the output to an IF node.
Check if the JSON contains "error": "ENETUNREACH".
If true, send a quick ping to Slack or a Google Sheet, then loop it back to retry.
This way, your flow still finishes successfully, but you get a precise log of the cloud network drops. Hope support sorts the routing out for you quickly!
