Error: connect ETIMEDOUT — Why the Connection Gets No Answer

ETIMEDOUT is the system error «Connection timed out» (errno 110 on Linux). For a new connection, connect(2) returns it on a «Timeout while attempting connection»; on an established TCP connection, tcp(7) uses it when «The other end didn't acknowledge retransmitted data after some time.» In Node.js:

Error: connect ETIMEDOUT 203.0.113.10:443
  { errno: -110, code: 'ETIMEDOUT', syscall: 'connect', address: '203.0.113.10', port: 443 }

The Node.js docs describe it as «A connect or send request failed because the connected party did not properly respond after a period of time. Usually encountered by http or net.» The key word is no response. If the host had answered with a refusal you would get ECONNREFUSED immediately; a timeout means the SYN packets went unanswered.

How long it takes depends on who gives up first. The Linux kernel retransmits the initial SYN tcp_syn_retries times, 6 by default, «which corresponds to retrying for up to approximately 127 seconds» (tcp(7)). Libraries usually stop sooner: Node's built-in fetch() (undici) has a 10-second connect timeout and reports UND_ERR_CONNECT_TIMEOUT in error.cause.

Drop versus reject explains most cases. A firewall rule that drops packets leaves the client waiting until it times out; a rule that rejects answers at once, and the client sees a refusal. If you control the firewall and want fast failures for blocked ports, reject instead of drop.

Node.js has several timeouts with different meanings. socket.setTimeout() only reports idleness: «When an idle timeout is triggered the socket will receive a 'timeout' event but the connection will not be severed. The user must manually call socket.end() or socket.destroy()» (net docs). Forgetting to destroy the socket in that handler leaves requests hanging forever instead of failing. For outgoing calls, bound the whole request:

const res = await fetch('https://api.example.com/v1/items', {
  signal: AbortSignal.timeout(5000), // rejects with a TimeoutError after 5 s
});

For long-lived connections through NAT gateways or load balancers, enable keep-alive probes so idle connections are not silently dropped: socket.setKeepAlive(true, 30_000).

1. Test the exact address and port from the machine that fails, with a short timeout:

   nc -vz -w 5 203.0.113.10 443
   curl -v --connect-timeout 5 https://api.example.com/

2. Compare with another network. If it connects from your laptop but not from the server (or the reverse), the block is on the failing side's egress or the target's allow list.
3. Check the address. dig +short api.example.com must return the IP in the error. An old IP in DNS or a hard-coded address sends traffic to a machine that is gone.
4. Open the port on the target: host firewall (iptables -S, nft list ruleset, ufw status) and the cloud security group or network ACL.
5. Trace the path when the host is remote: traceroute -T -p 443 203.0.113.10 shows where packets stop.
6. Confirm the service listens on the target: ss -ltn 'sport = :443'. A listening service behind a dropping firewall still times out.

Chrome shows the same failure as ERR_CONNECTION_TIMED_OUT.

nc -vz -w 5 api.example.com 443
# Connection to api.example.com 443 port [tcp/https] succeeded!
curl -sS -o /dev/null -w 'connect %{time_connect}s total %{time_total}s\n' https://api.example.com/

The connect time should be milliseconds, not seconds. The ping and port checker tests the host and port from our server, outside your network; the traceroute tool shows where the route stops.

• curl error 28 — the curl version of a timeout
• ECONNREFUSED — the host answered with a refusal
• ECONNRESET — the connection opened, then was reset
• ERR_ADDRESS_UNREACHABLE — no route to the IP at all
• Cloudflare error 523 — Cloudflare cannot reach the origin