workerd error: redirect loop detected when the worker fetches its own route

TL;DR

A worker whose route matches the URL it fetches calls itself, which fetches itself again, until workerd's loop protection aborts the request. The fetch was meant for the origin but the route pattern caught it. Fetch the origin directly (bypassing the worker route), narrow the route pattern so it does not match the fetch target, or restructure so the worker never calls its own public URL.

The query

workerd error: redirect loop detected when the worker fetches its own route

Use this when

• A worker fetch to your own domain triggers a loop error.
• The route pattern is broad (example.com slash-star style) and the worker calls example.com slash something.
• It worked until a route was widened or a new fetch was added.

Not for

• 'Response constructor: invalid redirect value' (bad redirect target, separate fix).
• Redirect chains at the origin (origin config problem).
• Browser-reported redirect loops (client-side symptom, different cause).

Steps

Step 1: Confirm the worker is calling itself

Check the fetch target against the worker's route patterns in wrangler.toml.

Expected result: the fetched URL matches one of the worker's own routes. The loop is self-inflicted.

Step 2: Fetch the origin directly

Replace the self-fetch with a fetch to the origin hostname or IP that sits behind the route, bypassing the worker.

// instead of fetching https://YOUR-domain/api/data (which routes back here)
const res = await fetch("https://origin-internal.YOUR-domain/api/data", {
  headers: { host: "[domain]" },
});

Expected result: the request goes to the origin without re-entering the worker. The loop cannot form.

Step 3: Or narrow the route pattern

If the worker only needs to handle slash-api-star, change the route from domain-slash-star to domain-slash-api-star so other paths (including the fetched one) skip the worker.

Expected result: the fetch target no longer matches a worker route. The request flows straight to the origin.

Step 4: Add a loop-breaker header for defense in depth

Set a custom header on internal fetches and short-circuit when it is present.

if (request.headers.get("x-worker-internal")) {
  return fetch(request); // pass through, do not reprocess
}

Expected result: even if routing misconfigures again, the second entry passes through instead of recursing.

Step 5: Redeploy and test the exact failing path

Expected result: the request completes in one pass. Tail shows a single invocation per client request, not a chain.

Why it happens

Workers sit in front of origins via routes. A route is a pattern match, not an identity check: the worker's own outbound fetch to a matching URL re-enters the worker like any external request. Each entry repeats the fetch, and workerd kills the cycle. Broad routes plus self-referential fetches make this almost inevitable.

Edge cases

• Subrequest limits can fire before the loop detector on deep chains. Fix the routing, not the limit.
• Service bindings (worker-to-worker calls) do not traverse routes and never loop this way. Prefer them over HTTP self-calls between your own workers.
• Custom domains added later can newly match old fetch targets. Re-audit routes after every domain addition.
• The loop-breaker header must be stripped or ignored at the origin if the origin echoes headers unexpectedly.

Provenance

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

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

Thread query: workerd error: redirect loop detected when the worker fetches its own route

TL;DR: A worker whose route matches the URL it fetches calls itself, which fetches itself again, until workerd's loop protection aborts the request. The fetch was meant for the origin but the route pattern caught it. Fetch the origin directly (bypassing the worker route), narrow the route pattern so it does not match the fetch target, or restructure so the worker never calls its own public URL.