Troubleshooting Sequential HTTP Failures in n8n Cloud: ECONNREFUSED on Second Request

The reported pattern - first HTTP call succeeding and the immediate second failing with ECONNREFUSED - suggests a networking-level problem rather than an application-layer error. Possible root causes include connection pooling/keep-alive interactions with the cloud runtime, ephemeral port exhaustion, improper DNS caching or resolution behavior (IPv4/IPv6 fallback), or an upstream proxy (Cloudflare) closing reused sockets. Misconfigured HTTP client settings in the runtime can also force premature connection closure.

To diagnose quickly, reproduce with controlled tests: replace the second request with a simple curl from the same cloud instance (if possible) to verify network behavior; alternate target domains and IPs; and toggle keep-alive and connection-reuse settings. Enable debug logging in n8n to capture the exact socket error and timestamps. Also test adding a small delay or an explicit new connection flag between nodes to see if the failure disappears - that narrows the problem to reuse or resource throttling.

Workarounds include inserting a short 'Wait' node between HTTP requests, disabling HTTP keep-alive or forcing separate connection contexts, or batching calls differently (parallel instead of sequential). If the issue persists, collect detailed logs (request/response headers, resolved IPs, timestamps) and escalate to n8n Cloud support with reproduction steps. They can inspect platform-side connection handling, Cloudflare rules, and instance-level networking.

For product and platform teams, this incident underscores the need for robust diagnostics around connection pooling, clear documentation of runtime networking behavior, and configurable HTTP client settings. For users, implement observability on workflow failures and prefer idempotent, retryable patterns until the root cause is resolved.