2nd sequential HTTP Request in the same execution fails with ECONNREFUSED, regardless of destination

Questions
1

On my Cloud instance (die.app.n8n.cloud), when I chain 2+ HTTP Request nodes sequentially in the same workflow execution, the first one always succeeds, but the second one always fails with ECONNREFUSED.
This happens even when the two requests target completely unrelated domains — I confirmed this by pointing the second request at https://jsonplaceholder.typicode.com/posts (a public test API, unrelated to my main use case), and it still failed the same way, with the correct Cloudflare IP resolved (188.114.96.3) but connection refused.
n8n version: 2.31.5 (Cloud)
Node type: HTTP Request, version 4.2
Error: NodeApiError: The service refused the connection - perhaps it is offline / connect ECONNREFUSED [ip]:443

Describe the problem/error/question

What is the error message (if any)?

Please share your workflow

(Select the nodes on your canvas and use the keyboard shortcuts CMD+C/CTRL+C and CMD+V/CTRL+V to copy and paste the workflow.)

Share the output returned by the last node

Information on your n8n setup

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:
2

Hey @Dorian_BRIANCON, while you wait for a response, here are some things that might help:

Suggested resources

Automatically matched to your question.

Docs:

Forum:

@Buggy_Arbor, @MutedJam - you’ve helped with similar issues before, can you take a look?

Automatically suggested by n8n’s community bot. It’s a pilot - please share feedback here.

3

Hi @Dorian_BRIANCON Welcome!
ECONNREFUSED is an active TCP reset on connect, not a timeout or a firewall drop, and Cloudflare’s edge does not refuse 443 from n8n Cloud. The request is not leaving where you think it is, which points at the node rather than the execution. Check Options on the failing node for a Proxy entry. A proxy set there overrides everything else and refuses at connect no matter which host you target, while the error still prints the resolved destination IP, which matches what you saw with jsonplaceholder.
To confirm it is the node and not the position, swap the two HTTP Request nodes so the failing one runs first. If the failure follows the node, it is that node’s config. If it stays on the second position, it is instance-side, so send help@n8n.io the execution ID and timestamp of a failed run.

4

Hi @Dorian_BRIANCON

ECONNREFUSED usually indicates a network-level rejection. Since it happens across unrelated domains and only on the second sequential node, this is likely not a DNS or target-server issue, but a socket exhaustion or connection pooling conflict within the specific execution container assigned to your Cloud instance.

The most common cause for sequential ECONNREFUSED in shared environments is the rapid opening/closing of sockets. Adding a small delay between requests often clears the socket state.

  • Action: Insert a Wait Node between the first and second HTTP Request nodes.
  • Setting: Set the wait time to 1 or 2 seconds​.
  • Why: This allows the underlying Node.js event loop and the Cloud instance’s network proxy to fully release the previous connection before attempting the next.

If you are processing a list of items, avoid chaining HTTP nodes in a linear sequence. Instead, use a Split In Batches node or a Loop to handle requests.

  • Action:
    1. Use a Split In Batches node (Batch Size: 1).
    2. Place the HTTP Request node inside the loop.
    3. Loop back to the Split In Batches node.
  • Why: This forces n8n to handle the execution in distinct chunks, which can prevent the “pile-up” of connection attempts that triggers the refusal.

If the requests are logically linked, you can bypass the overhead of multiple n8n node wrappers by using a single Code Node with axios or fetch.

  • Action: Replace the two HTTP Request nodes with one Code node.
  • Snippet:
const axios = require('axios');

const res1 = await axios.get('https://api.first.com/data');
const res2 = await axios.get('https://jsonplaceholder.typicode.com/posts');

return {
  firstRequest: res1.data,
  secondRequest: res2.data
};
  • Why: This uses a single Node.js process context for both requests, which is significantly more efficient than the n8n node-to-node handoff.

Does that help?

6

Hi,

Quick follow-up: the fix that worked was replacing the HTTP Request nodes entirely with a Code node using this.helpers.httpRequest for the sequential calls, wrapped in an await loop with a 1s delay between requests. This ran 5 sequential GET requests to the same domain (100 items each, ~423 items total) successfully in the same execution — no ECONNREFUSED.

So to narrow it down further for you: the bug seems specific to the HTTP Request node itself (v4.2, likely tied to its legacy request-based internals as mentioned in the stack trace — useStream, resolveWithFullResponse, etc.), not to n8n Cloud’s networking layer as a whole. this.helpers.httpRequest from within a Code node uses what I’d assume is the same underlying HTTP client, yet it worked fine every time — so possibly the issue is specifically in how the HTTP Request node (as a standalone visual node) manages its connection/socket state between separate node executions in the same workflow run, rather than a raw networking/instance-level problem.

This might help you reproduce/isolate it: it’s not about the destination, the payload, or timing — it’s specifically about chaining 2+ HTTP Request nodes (the visual node) sequentially. Wrapping the same logic in a single Code node sidesteps it completely.

Hope this helps narrow down the root cause for others hitting the same wall. Thanks for the guidance!

7

Two points in the replies are worth separating. A Wait node can be useful as an experiment, but it does not prove that Node.js needed time to release a socket. These HTTP nodes already run sequentially. Moving the calls into a Code node is not an option on n8n Cloud either. The Cloud Code node cannot make HTTP requests or import axios.

I would reduce this to a minimal workflow with a Manual Trigger and two HTTP Request nodes. Point both request nodes at the same stable public HTTPS endpoint and give them identical settings. Run the second node alone first. Then connect the first request to the second and repeat with their order reversed.

If the failure stays with one node, compare its Options and credentials against the working copy. If either node fails only when it runs second, save the execution ID with its timestamp and send the minimal workflow to Cloud support. That isolates execution position from the destination and from your original API.

The resolved Cloudflare IP tells you DNS succeeded. ECONNREFUSED means the TCP connection was actively refused. A delay may hide the symptom, but it does not explain a deterministic second-request failure.

n8n error reference: Common Issues | Nodes | n8n Docs

n8n Cloud Code-node limits: Code | Nodes | n8n Docs