Should I leave SSL Flexible mode so the site keeps working?

Flexible mode is precisely the most common cause of the loop: Cloudflare reaches the origin over HTTP, the origin answers with a 301 to HTTPS, and the request starts cycling. The correct setup is Full (strict) with a valid certificate on the origin, even a free Cloudflare Origin Certificate. Flexible is no longer justified today, even on a Free plan.

Should I force HTTPS at Cloudflare, on the origin server, or both?

In one place only, never both. If the origin already forces HTTPS in its web server or CMS configuration, the Cloudflare Always Use HTTPS option becomes redundant and adds a second redirect layer. The cleanest is to let Cloudflare handle the HTTP-to-HTTPS redirect and disable the origin one, or the reverse, but not both.

Why does the loop persist after fixing the configuration?

Because of caching. Browsers memorize 301 redirects for up to a year without rechecking the server, and some redirects can also be memorized at the edge. After fixing, test in a private window, purge the Cloudflare cache, and ask affected users to clear their browser cache.

Infinite HTTPS Redirect Loop behind Cloudflare

Your browser shows "ERR_TOO_MANY_REDIRECTS" or "Redirected too many times" as soon as the orange cloud is enabled. Here is how to walk the redirect chain and break the loop in a single intervention.

Why the loop happens, exactly

A redirect loop behind Cloudflare™ almost always follows the same pattern: the visitor requests https://example.com, Cloudflare reaches your origin server over HTTP (that is what SSL/TLS "Flexible" mode does), the origin answers with a 301 that forces HTTPS, and the request heads back to https://example.com... which Cloudflare will again fetch over HTTP. The browser gives up after roughly 20 round trips and displays the error.

This pattern did not exist before the proxy was enabled: directly, the browser already spoke HTTPS to the server. Introducing an intermediary is what shifts the protocol perception, which is why the problem systematically appears "after adding Cloudflare".

The five classic causes, most frequent first

SSL/TLS "Flexible" mode: Cloudflare reaches the origin over HTTP, the origin forces HTTPS, loop. This is cause number one, reinforced by Cloudflare suggesting Flexible "to make it work quickly" when the zone is added.
Duplicate HTTPS redirect: "Always Use HTTPS" on Cloudflare and an .htaccess / Nginx block that also forces HTTPS. Each layer sends the other back to the URL it just left.
Conflicting redirect rules: a Cloudflare Redirect Rule (for example apex to www) coexisting with an equivalent redirect on the origin, or a forgotten legacy Page Rule.
Incorrect base URLs in the CMS: WordPress, PrestaShop and friends store the site URL in the database; if it differs (http vs https, www vs non-www) from the URL actually served, the application redirects on every request.
301s memorized on both sides: browsers cache 301s for up to a year, so an old wrong redirect can "survive" its own fix on the server side.

The resolution protocol, step by step

Observe the real redirect chain. From the command line, with no cache:
```
curl -sIL https://www.example.com/ | grep -iE "HTTP/|location"
```
If you see the same URL reappear in the Location headers, the loop is confirmed and you can see at which link it alternates http/https or www/non-www.
Switch SSL/TLS to Full (strict). In SSL/TLS > Overview, pick Full (strict) and deploy a valid certificate on the origin (Let's Encrypt, or a free 15-year Cloudflare Origin Certificate). This is the setting that removes cause number one.
Choose ONE place to force HTTPS. Either "Always Use HTTPS" on Cloudflare with no forcing rule at the origin, or the reverse. If the origin is a CMS, the origin rule is usually more intrusive to remove; letting Cloudflare handle it is simplest.
Audit every redirect layer. Redirect Rules and Bulk Redirects on Cloudflare, then .htaccess/nginx.conf and application configuration at the origin. Every layer forcing the same thing should be reduced to a single one. Our guide on bulk redirects with Cloudflare details the right priority order.
Align the URLs declared by the application. WordPress: Settings > General (siteurl/home). PrestaShop: shop URL in the settings. Shopify and SaaS platforms manage this themselves, but check the declared primary domain.
Break the cache before concluding. Always test in a private window or with curl, purge the Cloudflare cache (Caching > Purge), and ask users who saw the loop to clear their browser cache: their machine may be replaying a 301 that no longer exists.

Mistakes that bring the loop back

Keeping Flexible "because it works": the site may seem fine if the origin does not force HTTPS, but every page is served over HTTP between Cloudflare and the origin, and any forcing on the application side flips the site into a loop. Flexible is a deferral, not a fix.
Fixing without purging: the server configuration is fixed, but the test happens in a browser replaying a memorized 301. The loop "resists" although it is gone server-side, and the diagnosis starts over from scratch.
Forgetting www vs non-www: the loop is not always about the protocol. A site served on example.com redirecting www to the apex, combined with a Cloudflare rule doing the opposite, loops endlessly across both hosts.
Stacking redirect rules incident after incident: a 2019 Page Rule, a 2024 Redirect Rule and an inherited .htaccess compose into a chain. One full audit pass costs less than the next incident.

Frequently asked questions

Why does the redirect loop only appear in some browsers?

Because the loop relies on locally cached 301 redirects. A browser that already memorized an old 301 replays it without contacting the server, while a private window or curl sees the real configuration. Test in a private window before touching the configuration again: the problem may already be gone server-side.

Should I leave SSL Flexible mode on so the site works?

No, it is the opposite: Flexible is the most common cause of the loop. Cloudflare then reaches the origin over HTTP, the origin answers with a 301 to HTTPS, and the request cycles. The correct setup is Full (strict) with a valid origin certificate, deployable for free even on a Free plan.

Should HTTPS be forced on Cloudflare, on the server, or both?

In one place only. If the origin already forces HTTPS, "Always Use HTTPS" on Cloudflare adds a redirect layer that can loop with the first one. Pick the place that is easiest to maintain (usually Cloudflare) and disable the other.

Why does the loop persist after the fix?

Because of caching. 301 redirects are memorized by browsers for up to a year and sometimes at the edge. Purge the Cloudflare cache, test in a private window or with curl -I, and tell affected users to clear their cache or retry later.

Fixing the Infinite HTTPS Redirect Loop behind Cloudflare™