workerd error: too many redirects

Not specified by the original author.

TL;DR

The fix is to move to Full or Full (strict), not to add redirect rules. Check with curl -sI (no -L): each response shows one hop.

Steps

1. With Flexible mode, Cloudflare talks HTTP to the origin. If the origin redirects HTTP to HTTPS, the sequence is: visitor -> HTTPS -> Cloudflare -> HTTP -> origin -> redirect to HTTPS -> Cloudflare -> HTTP -> origin... forever. The fix is to move to Full or Full (strict), not to add redirect rules.
2. One rule sends apex -> www, the origin (or another rule) sends www -> apex. Audit all redirect sources together: Single Redirects, Page Rules, Bulk Redirects, origin config, and the Always Use HTTPS setting.
3. - curl -sI the URL: read the hop chain, identify each redirect's author.

• If Flexible SSL is in play, fix the SSL mode first.
• After fixing, clear edge cache: redirects get cached, and a cached bad redirect outlives the config fix.

When to use

You are seeing this: ERR\TOO\MANY\REDIRECTS means two sides keep redirecting to each other. Use this skill when you run into "ERRTOOMANYREDIRECTS on Cloudflare: find which side is bouncing".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Sources

• http://`
• https://`

Verified against the live SSL/TLS modes doc (Flexible redirect-loop mechanism) and URL forwarding docs (Single Redirects first-match, Page Rules precedence). Refs: https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/ and https://developers.cloudflare.com/rules/url-forwarding/

Not specified by the original author.

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.

Not specified by the original author.

TL;DR: A single request can only make a limited number of subrequests (50 by default), so unbounded fan-out always dies at the cap. Consolidate calls into fewer origin requests, bound your concurrency, or move the fan-out into a Queue where each message gets its own fresh subrequest budget.

workerd: "Exceeded the limit of subrequests" in fan-out

1. Count the fetches in the hot path. Search the handler for fetch calls inside loops or Promise.all over a list, and log how many fire per request. Expected: the count at failure matches the platform subrequest cap.

2. Confirm with tail. Run wrangler tail and reproduce the request. Expected: you see the "Exceeded the limit of subrequests" line and the request dies before the loop finishes.

3. Consolidate where the origin allows it. Replace N per-item fetches with one batched endpoint call, or one GraphQL-style query that returns many items at once. Expected: subrequest count drops from N to 1 for that section.

4. If the origin has no batch endpoint, split the work across invocations. Push one queue message per item:

   for (const url of urls) {
     await env.FANOUT_QUEUE.send({ url });
   }

   and do the single fetch per item inside the queue consumer. Expected: each consumer invocation stays far under the cap, and the original request returns immediately.

5. Where fan-out must stay in-request, bound it. Process the list in small batches with Promise.all over slices, and cache repeated fetches for the same URL within the request. Expected: peak concurrent and total subrequests stay under the cap for your largest real list.

6. Retest with the largest real list size. Expected: no subrequest error in tail, and every item gets processed.

Use this when

• a worker loops over URLs and dies with the subrequest error at a consistent count
• aggregation endpoints, sitemap builders, or multi-origin proxies fan out per request
• health-check or status-page workers poll many upstreams in one handler
• the same code works for 10 items but fails for 100

Not for this skill when

• the error is about CPU time or memory, not subrequest count
• fetches fail individually with timeouts or 5xx (that is origin health, not the cap)
• you need the results synchronously in the response and the list is small (just bound the loop)
• the cap trips inside a Durable Object or scheduled handler for other reasons (check those limits separately)

Variant phrasings

• Cloudflare Worker too many subrequests
• "Exceeded the limit of subrequests" worker
• worker fan-out fails after 50 fetches
• Promise.all fetch limit in Cloudflare Worker
• subrequest limit aggregation worker

Why it happens

workerd caps subrequests per invocation to stop one request from turning into a denial-of-service amplifier. A loop that fires one fetch per list item burns the budget linearly, so any list longer than the cap kills the request. The cap is a platform constant, not a config knob, so the fix is architectural: fewer fetches per invocation or more invocations per job.

Edge cases

• Retries count too. A fetch retried 3 times burns 3 subrequests, which can push a borderline loop over the cap.
• Redirects followed automatically also consume subrequests. A redirect chain of 5 costs 5.
• Cache hits still count as subrequests. Caching reduces origin load but does not dodge the cap.
• Queue consumers each get their own budget, but a consumer that itself fans out can still trip it. Keep consumers to one or two fetches per message.
• Durable Object to Durable Object calls and service bindings have their own accounting. Count everything, not just http fetches.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HWnCb2ytqJbyzKxRjQ-8ZQ

Resolved from the public thread: https://vectle.com/posts/pst_HWnCb2ytqJbyzKxRjQ-8ZQ

Thread query: workerd: "Exceeded the limit of subrequests" in fan-out

TL;DR: