ERR_CONNECTION_TIMED_OUT / ETIMEDOUT (tested)

ERR_CONNECTION_TIMED_OUT (Chrome) and ETIMEDOUT (Node, Linux) mean the TCP connection was never set up. Packets went out and nothing came back. We pointed four clients at an address that drops every packet and timed exactly how long each waited and what it said.

1. What the error means

To open a connection, the client sends a SYN packet and waits for a SYN-ACK. If nothing at all comes back, the client resends the SYN a few times and then gives up. That is a connection timeout.

It is different from a refused connection (ECONNREFUSED; see ERR_CONNECTION_REFUSED / ECONNREFUSED). Refused means the host answered with a reset because nothing listens on the port. That fails at once. A timeout means silence: the packets are dropped by a firewall, a wrong route, a down host or a wrong IP.

It is also different from a server that accepts the connection and then never answers. That gives other errors, or none at all (section 4).

2. Our test setup

We connected to http://10.255.255.1/. It is a private address that nothing on our network answers, so every SYN is silently dropped. 192.0.2.1 (TEST-NET-1, reserved for documentation) did the same. No firewall rules were changed. Each client ran with its defaults, then with an explicit timeout.

3. Results: blackholed address

The 134.7 s is not a browser or library setting. It is the Linux kernel giving up after its default SYN retries. Chromium, curl, Node net and Python all hit the same wall within a few milliseconds of each other. curl's own default connect timeout is 300 s (per the curl docs, not measured), so on Linux the kernel always wins.

Node's built-in fetch is the exception. Its undici connect timeout of 10 s fired first. Catch it like this:

try {
  await fetch(url);
} catch (e) {
  if (e.cause?.code === 'UND_ERR_CONNECT_TIMEOUT') { /* host unreachable */ }
  if (e.cause?.code === 'ETIMEDOUT') { /* kernel timeout */ }
}

Note that Chromium's fetch() only says "Failed to fetch". Page code cannot see the reason. The DevTools console and network panel show the net:: code.

4. Contrast: the server accepts but never answers

Next we ran a Node server on 127.0.0.1 that accepts connections and never sends a byte. One version was a raw TCP server, one an HTTP server whose handler never calls res.end(). Both gave the same client results.

So ERR_CONNECTION_TIMED_OUT and ETIMEDOUT never appear here. The connection worked. curl's --connect-timeout does not help either; only -m/--max-time caps the whole request. We did not see Chromium's net::ERR_TIMED_OUT in this test. Chromium simply kept waiting for at least 7 minutes.

On the server side, Node's headersTimeout (60 s) and requestTimeout (300 s) only cover receiving the request. They did nothing to stop our handler hanging. When a client connected and sent nothing, or only half the headers, Node replied HTTP/1.1 408 Request Timeout and closed after 77 s (60 s plus the 30 s check interval). See 408 Request Timeout.

Behind a proxy, a hanging upstream turns into 504 Gateway Timeout. If the client gives up first, nginx logs 499.

5. Common causes

• Firewall drops the port. A cloud security group, host firewall or ISP filter with a DROP rule. A REJECT rule usually gives "refused" instead (not measured here).
• Wrong IP. Stale DNS, an old A record, or a hosts file entry pointing at a machine that is gone.
• Server is down or the port is not exposed. A container port not published, a VM stopped, a load balancer with no healthy targets.
• Private address from outside. Connecting to 10.x, 172.16-31.x or 192.168.x from another network, like our test.
• IPv6 route broken. The name resolves to an AAAA record but IPv6 traffic goes nowhere.

6. How to fix it

• Check what the name resolves to: dig +short example.com. Is that the right IP?
• Test the port with a short limit: curl -v --connect-timeout 5 http://HOST:PORT/. Exit 28 with "Connection timed out" means silence. Exit 7 after 0 ms (we measured "Failed to connect to 127.0.0.1 port 8987 after 0 ms: Could not connect to server" on a closed port) means refused. Without --connect-timeout, a timeout prints the same "Could not connect to server" text, so check the exit code: 28 vs 7.
• Test from the server itself: curl http://127.0.0.1:PORT/. If that works, the problem is a firewall or routing between you and it.
• Open the port in every layer: cloud security group, host firewall, container port mapping.
• In code, always set your own timeouts so a dead host fails in seconds, not 135 s: curl --connect-timeout plus -m, Python timeout=, Node AbortSignal.timeout().

If connections open and then drop, read ERR_CONNECTION_RESET / ECONNRESET.

Written with AI assistance. Measured on 2026-10-02 on Linux 6.12 with headless Chromium 153.0.8010.12 (Playwright), Node.js 24.21.0, curl 8.14.1 and Python 3.13.5 urllib. Blackholed target: 10.255.255.1:80 (no reply to SYN; 192.0.2.1 behaved the same). Hanging-server tests used a local Node server that accepts but never answers. Kernel and firewall settings were left at their defaults. PlainHeaders is our extension; curl, Python, Node.js and Chromium are free.