Hi all — moving this over from GitHub (issue #32927) at the team’s suggestion, as it may be a support/config matter rather than a bug.
Summary: My Anthropic node (Resource: Text, Operation: “Message a Model”) consistently fails on a connection timeout. The node never returns a response and enters an automatic retry loop, so the execution hangs in “Executing node…” and ultimately fails. This has happened continuously for several days regardless of changes I’ve tried. The same credential/node setup was previously working.
Node details:
- Node type: Anthropic (Message a Model), @n8n/n8n-nodes-langchain.anthropic
-
- Model: claude-haiku-4-5-20251001
-
- Resource: Text, Operation: message
-
- Node name: “Key Points Extraction Prompt”
- Error returned:
-
- errorMessage: The connection timed out, consider setting the ‘Retry on Fail’ option in the node settings [item 3]
-
- rawErrorMessage: connect ETIMEDOUT 160.79.104.10:443
- The node times out rather than returning a clear API error, then shows the auto-retry state.
- Environment / debug info:
-
- n8nVersion: 2.27.3 (Cloud)
-
- platform: docker (cloud)
-
- nodeJsVersion: 24.16.0
-
- nodeEnv: production
-
- database: sqlite
-
- executionMode: regular, concurrency: 20
-
- license: enterprise (sandbox)
-
- binaryDataMode: filesystem
- Notes: Workflow export omitted to avoid sharing sensitive data/credentials — happy to provide a sanitized export on request. API key/credentials intentionally not included.
- Has anyone seen connect ETIMEDOUT to the Anthropic API endpoint specifically from n8n Cloud? Any guidance on whether this is an outbound connectivity issue on the Cloud instance side would be appreciated.
Hi @Yitzy_Marcus
Since you are on n8n Cloud, you should escalate this to the n8n support team with the following specific technical details:
- The exact error:
connect ETIMEDOUT 160.79.104.10:443.
- The destination IP: Ask them to verify if
160.79.104.10 is the expected IP for the Anthropic API from their infrastructure.
- Egress Check: Ask them to check if there are any firewall rules or egress filters on the n8n Cloud instance preventing connections to Anthropic’s IP ranges.
- Network Path: Request a
traceroute from the n8n Cloud instance to api.anthropic.com to identify where the connection is dropping.
Hi @Yitzy_Marcus! Welcome to the community. 
A connect ETIMEDOUT to that specific Anthropic IP means your n8n Cloud instance is knocking on the door, but the request is getting dropped at the network layer before Anthropic can even validate your API key. Since it was working previously, this usually points to an upstream routing block or an intermediate firewall issue between the n8n Cloud infrastructure region and Anthropic’s edge network.
A quick test to isolate this: Try dropping a standard HTTP Request node into your workflow and make a basic raw POST request to https://api.anthropic.com/v1/messages with your credentials.
-
If it still times out: The outbound route from your specific n8n Cloud instance to Anthropic is definitively blocked.
-
If it works: There might be an underlying issue with how the LangChain wrapper node is compiling the network request in version 2.27.3.
I’d recommend opening a quick support ticket directly via your n8n Cloud dashboard so the infra team can check the outbound logs for your instance and see if a simple restart or box migration clears the network path!
The IP 160.79.104.10 that’s timing out doesn’t match Anthropic’s standard API endpoint range - that’s worth flagging with n8n support directly.
A quick way to isolate whether this is a node issue or a platform networking block: swap the Anthropic node for an HTTP Request node and call https://api.anthropic.com/v1/messages directly with the same API key and payload. If that also times out, it’s a network-level block on n8n Cloud’s side. If it works, the issue is specific to how the Anthropic node resolves the endpoint.
Also check your n8n Cloud region - sometimes egress routes differ by region and certain IPs end up going through intermediate proxies. Providing traceroute api.anthropic.com output to support will help them narrow this down fast.
The two isolation tests above are the right first move. Two things to add, since both point at why a single fixed IP keeps timing out after it was previously working:
- This looks more like stale DNS than a flat block. api.anthropic.com normally resolves behind a CDN to rotating IPs, so an instance stubbornly hitting one fixed IP (160.79.104.10) and timing out usually means the resolver cached an A record that is now dead. When you open the support ticket, ask them specifically to re-resolve DNS or migrate the box, that re-resolves the host and tends to clear exactly this. A plain restart sometimes is not enough if the cache sits upstream.
- Deal with the auto-retry loop while you debug. The loop is the node’s Retry On Fail hammering the same dead path, which burns executions and buries the real error. Set Retry On Fail off (or maxTries to 1) on that node temporarily so you get a single clean ETIMEDOUT to reason about instead of a storm of them.
If the raw HTTP Request node also times out on that endpoint, it is the network path like the others said, and a DNS re-resolution is the most common fix for the “worked yesterday, one fixed IP, now timing out” pattern specifically.