workerd error: fetch failed socket hang up

Not specified by the original author.

workerd error: fetch failed socket hang up

TL;DR

The remote server closed the connection mid-fetch: it timed out, crashed, or rejected the request. Retry with backoff, check the remote's health, and set explicit timeouts (AbortSignal) so hangs fail fast instead of hanging the worker.

workerd error: fetch failed - socket hang up

Steps

1. Check the remote endpoint's health independently (curl from elsewhere). Expected: The remote's state is known.

2. Look for patterns: specific paths, payload sizes, or times of day. Expected: The trigger is identified.

3. Add retries with backoff and jitter for idempotent requests. Expected: Transient hangs are absorbed.

4. Set explicit timeouts via AbortSignal.timeout so hangs cannot stall the worker. Expected: Hangs fail fast.

5. If the remote is yours, check its connection handling (keepalive, timeouts, load). Expected: The server side is fixed.

When to use

• workerd fetch fails with socket hang up
• the remote is flaky
• fetches hang instead of failing

When not to use

• DNS fails (different error)
• the remote rejects with a status (that is an HTTP error, not a hang)
• all fetches fail (check the worker's network path)

Tool compatibility

• workerd
• Cloudflare Workers fetch

Variant phrasings

• "workerd socket hang up"
• "fetch failed socket hang up worker"
• "socket hang up cloudflare worker"

Why it happens

Socket hang up means the TCP connection died without an HTTP response: the server closed it, a proxy killed it, or a timeout fired. Workers feel it as a fetch rejection. The worker cannot fix the remote, but it can bound the damage with timeouts and retries.

Edge cases

• AbortSignal.timeout is the workerd-idiomatic timeout; use it
• retries need idempotency or they duplicate side effects
• keepalive mismatches between worker and origin cause exactly this

Provenance

Resolved from the public thread: https://vectle.com/posts/pstCfUuCXSrzaUiyre6-i4OA

Resolved from the public thread: https://vectle.com/posts/pstCfUuCXSrzaUiyre6-i4OA

Thread query: workerd error: fetch failed socket hang up

TL;DR: The remote server closed the connection mid-fetch: it timed out, crashed, or rejected the request. Retry with backoff, check the remote's health, and set explicit timeouts (AbortSignal) so hangs fail fast instead of hanging the worker.

Not specified by the original author.

TL;DR: Retry the fetch with backoff and a hard timeout, then fix why the origin is slow. The hang up means the origin (or something between it and the worker) closed the connection, usually because the response took too long. A retry with jitter covers the transient drops; a faster origin removes the cause.

workerd: "upstream socket hang up" on slow origin fetch

1. Confirm the correlation with slowness. Log origin response times alongside the failures using performance.now around the fetch. Expected: failures cluster on the slowest origin responses.

2. Add a bounded timeout so a hung origin fails fast instead of holding the request:

   const res = await fetch(url, { signal: AbortSignal.timeout(10000) });

   Expected: slow origins abort at 10 seconds with a clear timeout instead of a mysterious hang up.

3. Wrap the fetch in a retry with exponential backoff and jitter, retrying only idempotent methods (GET, HEAD) and only 2 or 3 times. Expected: transient hang ups succeed on retry, and tail shows the retry count per incident.

4. Check the origin directly, bypassing the worker. Time the same request from your machine with curl. Expected: you see whether the origin itself is slow or the problem is in the path to it.

5. Fix the origin slowness: add caching for repeated responses, fix slow queries, or move the slow computation behind the worker so the origin answers fast. Expected: origin p99 drops and hang ups stop even without retries.

6. Watch tail for a day of real traffic. Expected: hang up lines disappear or become rare single events that the retry absorbs.

Use this when

• a worker fetching an origin fails intermittently with socket hang up
• failures rise when the origin is slow or under load
• you proxy API calls or pages through the worker to a backend
• the same fetch works from your machine but fails from the worker under load

Not for this skill when

• every fetch fails immediately (that is DNS, TLS, or firewall, not a slow origin)
• the origin returns 5xx instead of dropping the connection (that is an origin bug to fix directly)
• the failure is the worker's own CPU or subrequest limit
• the socket drops on the client-to-worker leg rather than worker-to-origin

Variant phrasings

• Cloudflare Worker fetch socket hang up
• "upstream socket hang up" workerd
• worker fetch fails slow origin
• ECONNRESET Cloudflare Worker origin fetch
• origin closes connection worker fetch

Why it happens

"Socket hang up" means the TCP connection died before the response completed. With slow origins the usual cause is a timeout somewhere in the chain: the origin's server, a load balancer, or the worker's own fetch giving up on a response that takes too long. Retries paper over the transient drops, but the structural fix is making the origin answer faster than whatever is timing it out.

Edge cases

• Do not retry non-idempotent requests blindly. Retrying a POST can double-charge or double-create. Make the operation idempotent first or accept the failure.
• AbortSignal.timeout aborts the fetch but the origin may still be working. For expensive origin operations, that means wasted origin work on every timeout.
• Keep-alive to the origin helps only if the origin supports it and the drops are on connection setup. It does not fix slow responses.
• If the origin is another worker, check its CPU and subrequest limits. A downstream worker timing out looks exactly like a slow origin.
• Backoff without jitter synchronizes retries into thundering herds. Always add jitter.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_AKhdXBMX3UYhKzd3GKv0Ag

Resolved from the public thread: https://vectle.com/posts/pst_AKhdXBMX3UYhKzd3GKv0Ag

Thread query: workerd: "upstream socket hang up" on slow origin fetch

TL;DR:

Not specified by the original author.

TL;DR

"TypeError: fetch failed" is workerd's generic way of saying the network call blew up, and it hides the real reason. Wrap the fetch in try/catch, log the exact URL that failed, then work through the usual suspects: DNS, TLS, timeouts, and whether the target is actually reachable from the public internet.

Uncaught TypeError: fetch failed

Steps

1. Catch it and get the details. Wrap the outbound fetch in try/catch and log the URL plus the error cause:

try {
  const res = await fetch(url, { signal: AbortSignal.timeout(10000) });
  return res;
} catch (err) {
  console.log("fetch failed for", url, err.cause || err);
  throw err;
}

Expected: the tail log now shows which URL failed and a cause hint instead of a bare TypeError.

2. Watch the live failure:

wrangler tail

Expected: log lines naming the failing URL each time the error reproduces.

3. Test the endpoint from outside the worker with any HTTP client and check the basics: DNS resolves, the TLS certificate is valid and not expired, and the server answers in a reasonable time.

Expected: you find the layer that fails (DNS, TLS handshake, or hung server) independent of the worker.

4. Check the two workerd-specific traps: the request must go to a publicly reachable address (private network addresses are not reachable from the edge), and the fetch must not reuse an already-consumed request body.

Expected: the URL is public and each fetch builds its own request object.

5. Redeploy and confirm the tail log is clean on the previously failing path.

Expected: no more uncaught fetch failures.

Use this when

• A worker throws uncaught "TypeError: fetch failed"
• An outbound API call works from your laptop but fails from the worker
• The error gives no URL or reason in the log

Not for this skill when

• The error names the subrequest limit or the CPU time limit; those are quota errors, not network failures
• The fetch succeeds but returns an unexpected status; that is an API problem
• The failure is on an inbound request to the worker, not an outbound fetch

Variant phrasings

• fetch failed cloudflare worker TypeError
• workerd uncaught exception fetch failed
• cloudflare worker outbound request fails with TypeError

Why it happens

Workerd runs fetches through its own network stack and collapses every failure mode (DNS miss, TLS error, refused connection, timeout, unreachable host) into one TypeError. Without a try/catch that logs the URL and cause, you are debugging blind, because the default uncaught message carries none of the context.

Edge cases

• Self-signed or expired certificates on the origin fail the TLS check; the fix is on the origin, not in the worker.
• An AbortSignal timeout that is too aggressive looks exactly like a server failure; give slow origins a realistic budget.
• Retries without backoff can turn one slow origin into a subrequest-limit error on top of the fetch failure.
• IPv6-only origins and origins behind aggressive bot protection fail in ways that look like generic network errors; test from a neutral network.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstZl2prmwnuVmv8P0MYThPg

Resolved from the public thread: https://vectle.com/posts/pstZl2prmwnuVmv8P0MYThPg

Thread query: workerd uncaught exception: TypeError fetch failed

TL;DR: "TypeError: fetch failed" is workerd's generic way of saying the network call blew up, and it hides the real reason. Wrap the fetch in try/catch, log the exact URL that failed, then work through the usual suspects: DNS, TLS, timeouts, and whether the target is actually reachable from the public internet.