Introduction

Cloudflare Transform Rules can rewrite URLs, headers, and request details before your application or redirect logic sees the request. That makes them powerful, but also easy to misconfigure. A rule that changes the path, host, or scheme at the wrong stage can cause loops, failed redirects, or users landing on the wrong URL. The fix is to trace what Cloudflare sends downstream after transforms are applied.

Symptoms

  • Redirects start looping or stop matching the expected destination
  • Requests land on the wrong hostname, path, or protocol after a Cloudflare rule change
  • Origin-side redirect logic worked before adding a Transform Rule
  • Only some routes break, usually those tied to locale, host, or path normalization
  • The issue began after introducing request header or URL rewrite logic at the edge

Common Causes

  • A Transform Rule rewrites the path or host before the origin redirect logic evaluates it
  • Redirect rules and transform rules act on the same requests in conflicting ways
  • A header rewrite changes origin behavior unexpectedly, especially around scheme or host detection
  • Rule ordering causes a broad rewrite to run before a narrow redirect condition
  • The application trusts forwarded headers that no longer reflect the original request correctly

Step-by-Step Fix

  1. Reproduce the broken redirect with a specific URL and record the expected versus actual final destination.
  2. Review active Cloudflare Transform Rules, Redirect Rules, and any origin redirect logic together rather than debugging them in isolation.
  3. Identify whether the request path, hostname, or forwarded headers are being modified before the redirect condition is evaluated.
  4. Disable or narrow the suspect Transform Rule temporarily to confirm whether the redirect behavior returns to normal.
  5. Adjust rule order or scope so only the intended requests are rewritten before redirect logic runs.
  6. If the origin application uses forwarded host or scheme headers, verify those values still represent the canonical request after edge processing.
  7. Test both browser-facing and direct-origin flows so you can distinguish an edge rewrite problem from an application redirect bug.
  8. Re-check the affected URL patterns after the fix to ensure there are no loops, protocol downgrades, or host mismatches.
  9. Document how edge transforms interact with redirect logic so future URL normalization changes do not break canonical routing unexpectedly.