n8n HTTP Request: connect ETIMEDOUT while the API works elsewhere?

An important integration stops at the HTTP Request node. It reports connect ETIMEDOUT, although the address appears reachable from your workstation. Repeating the request or increasing a timeout provides little clarity until you know whether n8n can establish the intended connection.

Read the failure at the correct layer

The original report concerns n8n Cloud 2.43.5: a connection attempt to port 443 timed out while a browser received HTTP 405. The initial report does not establish a confirmed cause. Q1 Node.js describes ETIMEDOUT as a connection or send operation that did not receive a timely response. Q2 The connect part and destination port are therefore useful evidence.

A browser receiving 405 has obtained an HTTP response. That does not establish reachability from n8n Cloud or prove that both clients used the same resolved address, method, redirects and access rules.

A useful diagnostic sequence

1. Capture the actual request. Record a timestamp with timezone, hostname, destination port, method and complete redacted error. Check the resolved URL after expression evaluation, rather than only the placeholder shown in the editor.
2. Separate failure stages. Confirm that the error is actually connect ETIMEDOUT. An HTTP 401, 403 or 405 requires a different investigation from a failed connection. Slow response-body processing is another distinct situation.
3. Correlate destination logs. Ask the endpoint operator to inspect firewall, reverse-proxy and application logs for that timestamp. If nothing reaches the network edge, examine routing, address resolution and allowed sources. If a request is recorded there, follow it towards the application.
4. Compare from the relevant environment. On a self-hosted installation, use a read-only request from the n8n container or its network. On Cloud, give support the instance, timestamp and destination hostname. A successful laptop request is useful context but does not replace this comparison.
5. Narrow the test safely. If the API operator provides a read-only health endpoint on the same host, use it to separate connectivity from application processing. If it succeeds, investigate the specific path next. Do not use an order-creation request as a network probe.

Match the change to the evidence

A proven source restriction calls for an appropriately narrow allowlist change. An incorrect hostname or port calls for configuration correction. Consider a longer timeout only after establishing that legitimate processing takes longer. Repeated retries can increase a backlog and create uncertain external effects for write operations.

Frequently asked questions

Should I replace HTTPS with HTTP?

No. That changes the destination port and security model, so it no longer tests the same connection. Diagnose the intended HTTPS route.

What should I send to support?

Send the error, timestamp, n8n version, hosting type, redacted URL, method and destination-side observations. Keep API keys and customer payloads out of the report.

Help with this case

We can help isolate the affected process and prepare a controlled next step. Discuss case A0053 with KAN KAI WORKS.