Cloudflare Redirects: Fixing Rules, Proxy and SSL Settings

Is it Cloudflare or your server?

Before changing anything, find out which layer is producing the redirect. A response that passes through Cloudflare carries a cf-ray header and usually server: cloudflare, but both appear whether the redirect came from Cloudflare or from your server behind it. The clues that it was Cloudflare itself:

• The redirect response has no headers your application normally sets, such as its own cookies or x-powered-by.
• The redirect still happens when your server is stopped or when you request a path your server does not have.
• Your server's access log has no line for the request at the time you made it.

curl -sI http://example.co.uk/old-offer | grep -iE "^HTTP|^location|^server|^cf-ray|^x-"

The Redirect Checker records the status code and Location of every hop, which lets you see whether an edge redirect is followed by a second one from your server. That pattern, one hop from Cloudflare and another from the origin, is the most common chain on Cloudflare sites.

The places a Cloudflare redirect can come from

Names and menus change as Cloudflare updates its products, so treat this as a map of what to look for rather than an exact menu path. At the time of writing, a zone can redirect from any of these:

Cloudflare processes these features in a fixed order, documented in its developer documentation. When two of them match the same request, the one that runs first wins and the other may never be seen. That is why an old legacy rule can appear to be ignored, or can quietly override a newer one.

The fix, step by step

Example rules

The exact field names in the dashboard change from time to time, but the logic is stable. These are written in the form Cloudflare's rule expressions use.

Bare domain to www, keeping the path

When incoming requests match:
  (http.host eq "example.co.uk")
Then:
  Type: Dynamic
  Expression: concat("https://www.example.co.uk", http.request.uri.path)
  Status code: 301
  Preserve query string: on

Old folder to new folder with a wildcard

Request URL:  https://www.example.co.uk/blog/*
Target URL:   https://www.example.co.uk/articles/${1}
Status code:  301
Preserve query string: on

A redirect-only domain

For an old domain that only needs to forward to the main site, add it to Cloudflare, create a proxied DNS record for the bare name and www (Cloudflare's documentation suggests a placeholder address such as 192.0.2.1 for this purpose), then add a single redirect rule sending both hostnames to the matching path on the main domain.

A Worker for logic rules cannot express

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const target = await env.REDIRECTS.get(url.pathname);
    if (target) {
      return Response.redirect("https://www.example.co.uk" + target, 301);
    }
    return fetch(request);
  }
};

Here REDIRECTS is a key-value store bound to the Worker. Use this only where rules and bulk lists are not enough: code is harder for the next person to audit.

Cloudflare-specific pitfalls

• Grey-cloud records. A DNS-only record bypasses Cloudflare completely, so no rule you write will run for that hostname. A common case is www proxied and the bare domain not, or the other way round.
• Two HTTPS upgrades. Always Use HTTPS at the edge and a force-HTTPS rule on the origin do not loop if the encryption mode is strict, but they do add work and confusion. Keep one.
• Flexible encryption. This mode encrypts only the visitor side. Any origin rule that forces HTTPS will then loop, and visitors' data travels unencrypted between Cloudflare and your server.
• Dropped paths. A static target such as https://www.example.co.uk/ sends every old URL to the homepage. Use a dynamic target or wildcard reference to carry the path over.
• Query strings. Whether query strings are kept is an option per rule or list. Campaign tracking parameters are lost if it is off.
• Cached redirects. Redirect responses from the origin can be cached at the edge like any other response. Purge after changing origin redirects, or the old ones keep being served.
• Rule limits. Each plan allows a set number of rules and list entries. The limits change, so check your plan before designing a migration that needs thousands of entries.

Deciding between Cloudflare and your origin for each kind of rule is covered in fixing CDN and origin redirect conflicts, and building the list of old and new URLs for a site move is covered in the migration redirects guide.

Keeping Cloudflare redirects tidy

• Name every rule after what it does, such as "bare domain to www" or "2025 blog move", and add the date in the description.
• Keep one exported list of all bulk redirects outside Cloudflare, so you can review targets for chains and restore it if needed.
• Limit who can edit rules to the people who maintain the list, and check the account's audit log after unexplained changes.
• When you migrate away from a legacy feature, switch the old rule off for a week before deleting it, while you check the Redirect Checker results and Search Console for errors.
• Re-run the checker on the four scheme and host combinations after any change to DNS records, encryption mode or rules.