Deploy Error Decoder

'connect ETIMEDOUT' — why connections time out and how to fix it

Quick answer: connect ETIMEDOUT means your app tried to open a connection and got no response at all before timing out. Unlike ECONNREFUSED (something actively said "no"), a timeout usually means a firewall or security group is dropping packets, the host/port is wrong, or the upstream is overloaded. Check reachability and network rules — not just whether the service is running.

What the error looks like

The connection attempt hangs, then fails after the timeout window:

Error: connect ETIMEDOUT 10.0.0.5:443
    at Timeout._onTimeout (node:net:120:19)
  errno: -110, code: 'ETIMEDOUT', address: '10.0.0.5', port: 443

Silence is the signal. ECONNREFUSED means something answered "nothing here"; ETIMEDOUT means nothing answered at all — packets went into a void, which points at the network path, not the service.

Why it happens

Firewall / security group blocks the port

A cloud security group or firewall silently drops the packets, so the connection never completes.

Wrong host or unreachable IP

The address resolves but routes nowhere your packets can reach (wrong subnet, VPC, or private IP).

Upstream overloaded

The service is up but so saturated it can't accept the connection in time.

Routing / NAT problem

A VPN, NAT, or peering gap means there's no working path between you and the host.

Diagnose it in three steps

1

Refused or just silent?

nc -zv 10.0.0.5 443
# 'Connection refused' -> service/port issue (see ECONNREFUSED).
# Hangs then times out -> a firewall is dropping packets.
2

Check network rules and routing

# Is the port open in the security group / firewall?
# Can a different host in the same network reach it?
traceroute 10.0.0.5
3

Add sane timeouts + retries

// fail fast instead of hanging, and retry idempotent calls
fetch(url, { signal: AbortSignal.timeout(5000) });
The real fix

Open the path, then fail fast

A timeout is a network-path problem first. Open the port in the security group/firewall, confirm the host is actually routable from your service, and only then tune the app. In code, set explicit connect timeouts and retry idempotent requests so one unreachable dependency doesn't hang every request.

How Infraveil handles this

Unreachable dependencies, made visible

Infraveil health-checks your services and their dependencies on your own servers, so an upstream that's gone unreachable shows up in one status view instead of as a pile of identical timeouts. Recovery is approval-gated and recorded, and you can roll back while you fix the network path.

Dependency and service health surfaced in one status view
Automatic restart and recovery, approval-gated and recorded
Runs on servers you control, with request tracing for slow/stuck calls

Frequently asked questions

What does 'connect ETIMEDOUT' mean?

Your app tried to open a connection and received no response within the timeout window. The packets weren't refused — they got no answer, usually due to a firewall, wrong host, or overloaded upstream.

ETIMEDOUT vs ECONNREFUSED?

Refused means something actively rejected the connection (service down or wrong port, host reachable). Timed out means nothing answered at all — typically a firewall dropping packets or an unreachable host.

How do I fix connect ETIMEDOUT?

Confirm the port is open in the firewall/security group, that the host is actually routable from your service, and that the upstream isn't overloaded. Add explicit connect timeouts and retries in code.

Why does it work locally but time out in the cloud?

Locally there's no firewall between you and the service. In the cloud, a security group or network ACL is likely dropping the packets — open the port for the source.