Too many redirects behind Cloudflare: find which two settings disagree

How a loop forms

The browser message "redirected you too many times" means the visitor was sent from address A to address B and back again until the browser gave up. Each rule that sends them looks correct on its own. The fault is the pair: one rule insists on https and another sends the visitor back to http, or two redirect rules point at each other. Nothing short of following the chain shows which two disagree.

The encryption mode is the usual first suspect

Cloudflare's encryption mode decides how it talks to your host. In Flexible mode the visitor can use HTTPS but Cloudflare reaches your host over plain HTTP. If your host or WordPress then redirects every HTTP request to HTTPS, Cloudflare asks over HTTP, is redirected, asks over HTTP again, and loops. In Full and Full (strict) the opposite fault is possible: Cloudflare asks over HTTPS and an origin that bounces HTTPS back to HTTP causes the loop.

Full does not validate the certificate at the host and Full (strict) does, so strict needs a valid certificate there. Cloudflare recommends Full or Full (strict) where possible, and treats Flexible as the choice for hosts that cannot do TLS. That has a cost: in Flexible mode the leg between Cloudflare and your host is unencrypted, which is a decision for the site owner and not just a setting.

• Flexible plus a host that forces HTTPS: remove the host redirect, or move to Full with a certificate at the host.
• Full or strict plus a host that sends HTTPS back to HTTP: remove that host redirect.
• Always Use HTTPS or HSTS turned on while the host redirects the other way: keep only one of them.

Other places the second rule hides

Cloudflare lists redirect rules and Page Rules as a cause: two rules for related addresses can send the visitor round in a circle. The host's own control panel often has a "force HTTPS" switch and a separate rule file. For a WordPress site, the site and home address settings are a further place where the scheme or the www choice can disagree with the CDN. Cloudflare's page mentions its WordPress plugin with Automatic HTTPS rewrites as a way to reduce loops and mixed content; the address settings are our own addition, not from that page.

• Look at the CDN's redirect rules, its Page Rules and its HTTPS settings.
• Look at the host's force-HTTPS and redirect settings, and any security plugin.
• For WordPress, look at the site and home address settings.

Trace the chain first

Follow the redirects from the plain-http version of each name and print every step. With curl, the -L option follows redirects and --max-redirs stops a loop. A redirect that Cloudflare itself produces, from a redirect rule or Always Use HTTPS, shows a cache status of NONE or UNKNOWN in its documentation, so a header that differs between hops can tell you which side sent it. Record the hop where the address flips between http and https or between www and the bare domain.

• Trace the four variants: http and https, bare and www.
• Trace the log-in page separately, because a loop sometimes happens only after sign-in.
• Do not change anything until you have one saved trace.

Fix it in one place, then prove it

The repair is to make HTTPS enforcement happen in exactly one place and make the other settings agree with it. Prefer a stricter encryption mode when the host has a valid certificate, and say plainly if the host does not. After the change, re-trace all four variants and a log-in.

The fixed-price job for this is a published test price of £125, not yet tested with buyers, and you pay after sign-off. Acceptance is a four-row table in which each variant ends at one address with a 200 status after at most two redirects, a log-in that works without a loop, and a note of the one place that now enforces HTTPS. It does not cover buying a certificate, a certificate warning, or a loop caused by a firewall or plugin that nobody may change.