Skip to content
Rescue 404

Cloudflare Errors

Cloudflare flexible SSL redirect loop

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

A Cloudflare Flexible SSL redirect loop happens when the edge talks HTTPS to visitors but plain HTTP to the origin while WordPress or the host also force-redirects HTTP to HTTPS—switch to Full or Full (strict) with a valid origin certificate, then leave only one HTTPS-enforcement layer in place.

Flexible mode is the classic Cloudflare-specific redirect trap on WordPress: the proxy never uses HTTPS to the origin, so every origin “upgrade to HTTPS” bounce feeds another visitor HTTPS request that becomes HTTP again at the host. This guide is the Flexible-focused playbook—confirm the mode, install origin TLS, move to Full/Full (strict), and strip duplicate force-HTTPS rules without guessing plugin settings first.

Intermediate

Key facts

Verifiable numbers and definitions — each claim links to its source.

What the error means

In Cloudflare Flexible SSL/TLS mode, browsers connect to Cloudflare with HTTPS, but Cloudflare connects to your origin with plain HTTP. If the origin—via Really Simple SSL, a host “force HTTPS” toggle, or `.htaccess`—responds to that HTTP request with a redirect to HTTPS, Cloudflare forwards the redirect to the browser, the browser requests HTTPS again, and Cloudflare once more opens HTTP to the origin. The loop continues until the browser shows ERR_TOO_MANY_REDIRECTS. This is not mixed content (mixed content is HTTPS pages loading HTTP assets) and not a broken certificate by itself; it is a protocol mismatch between Flexible and an origin that refuses to stay on HTTP. Grey-clouding the DNS record or leaving Flexible for Full/Full (strict) changes the behavior immediately when Flexible is the cause.

Common symptoms

  • Browser shows ERR_TOO_MANY_REDIRECTS or “redirected you too many times” while the hostname is orange-cloud proxied
  • Cloudflare SSL/TLS Overview shows encryption mode set to Flexible
  • DevTools Network shows a repeating 301/302 chain bouncing between http and https
  • Grey-clouding the DNS record (DNS only) stops the loop immediately
  • Loop appeared right after enabling Cloudflare proxy, Flexible mode, or a force-HTTPS plugin
  • wp-admin and the front end both loop the same way
  • Origin loads when tested directly over HTTPS with a valid certificate, proving the app itself is not the only factor

Most likely causes

  1. 01 Cloudflare SSL/TLS mode left on Flexible while the origin redirects all HTTP to HTTPS
  2. 02 Really Simple SSL, Exact Links, or similar force-HTTPS plugins active on top of Flexible
  3. 03 Host panel or `.htaccess` HTTPS redirect still firing on the HTTP hop Cloudflare uses in Flexible
  4. 04 Cloudflare Always Use HTTPS plus an origin redirect doubling the bounce under Flexible
  5. 05 Origin missing a usable certificate, so someone chose Flexible instead of fixing Full/Full (strict)
  6. 06 WordPress siteurl/home still on http:// while edge visitors arrive on https://
  7. 07 Page Rules or Redirect Rules sending HTTPS upgrades that fight the Flexible origin hop

What changed before the problem started

  • Cloudflare proxy (orange cloud) enabled on a previously direct-to-origin site
  • SSL/TLS encryption mode set to or left on Flexible
  • Force-HTTPS plugin or host HTTPS redirect enabled after connecting Cloudflare
  • Always Use HTTPS toggled on alongside Flexible
  • Origin certificate expired or never issued, blocking a move to Full (strict)
  • Migration restored WordPress http:// URLs while Cloudflare terminates HTTPS at the edge

Troubleshooting steps

  1. 01

    Confirm Flexible mode and a Cloudflare-specific loop

    Open SSL/TLS → Overview and verify Flexible. Temporarily set the A/CNAME to DNS only (grey cloud). If the loop vanishes, the Flexible-plus-origin-redirect interaction is the prime suspect—not a random plugin conflict elsewhere.

  2. 02

    Install or verify a certificate on the origin

    Before leaving Flexible, confirm the origin can speak HTTPS: Let’s Encrypt/AutoSSL, host SSL, or a Cloudflare Origin CA certificate on port 443 for the hostname. Full (strict) needs a certificate Cloudflare will accept; plain Full needs HTTPS listening even if validation is looser.

  3. 03

    Switch SSL/TLS mode to Full or Full (strict)

    Move off Flexible so Cloudflare uses HTTPS to the origin. This single change breaks the Flexible redirect loop in most WordPress cases. Prefer Full (strict) once the origin certificate is valid and name-matched.

  4. 04

    Re-proxy the DNS record and purge edge cache

    Set the record back to proxied (orange cloud), purge Cloudflare cache, and retest in a private window. Confirm both the homepage and wp-admin load without a redirect chain.

  5. 05

    Collapse duplicate force-HTTPS layers to one

    Keep a single enforcement path—usually Cloudflare Always Use HTTPS plus correct https:// WordPress URLs—or a single origin redirect, not plugin + `.htaccess` + edge rules all at once. Extra layers recreate loops even after mode is fixed.

  6. 06

    Set WordPress Address and Site Address to https://

    In Settings → General (or WP_HOME/WP_SITEURL in `wp-config.php` if admin was looping), use the https:// domain. Lingering http:// values can reintroduce bounces after Flexible is gone.

When to stop troubleshooting

Escalate if you cannot access the Cloudflare dashboard or origin SSL settings, you cannot install any origin certificate (including Origin CA), the loop survives after Full/Full (strict) with a single redirect layer, or login/checkout remain broken past your maintenance window. Provide the SSL/TLS mode, proxy status, DevTools redirect chain, and whether grey-cloud stopped the loop.

Information to collect before requesting help

  • 01 Cloudflare SSL/TLS mode (confirm Flexible vs Full / Full strict)
  • 02 Whether grey-clouding the DNS record stops the loop
  • 03 DevTools redirect chain showing http/https alternation
  • 04 Whether the origin has a valid HTTPS certificate on 443
  • 05 Active force-HTTPS plugins, Always Use HTTPS, Page Rules, or Redirect Rules
  • 06 WordPress siteurl and home values (http vs https)
  • 07 When Flexible mode or the Cloudflare proxy was enabled

How a professional repairs the problem

We prove the loop is Flexible-specific with a grey-cloud test, install or validate origin TLS (public CA or Cloudflare Origin CA), and move the zone to Full or Full (strict). Duplicate force-HTTPS layers are reduced to one, WordPress URLs are aligned to https://, and we verify front end plus wp-admin with cache purged before handing the site back—Flexible is not left as a standing workaround.

Frequently asked questions

Why does Flexible SSL cause redirect loops so often on WordPress? +
WordPress and many hosts assume that an HTTP request should be upgraded to HTTPS. Flexible still sends HTTP to the origin, so that upgrade never “finishes” from Cloudflare’s point of view and the browser loops.
Is this the same as the general Cloudflare too many redirects guide? +
It overlaps. That guide covers Cloudflare redirect loops broadly; this page focuses on the Flexible SSL mode mismatch as the named failure mode and the exact mode + certificate path out of it.
Can I stay on Flexible if I disable the WordPress SSL plugin? +
Sometimes the loop stops, but Flexible still leaves the edge-to-origin leg unencrypted and any remaining host redirect can bring the loop back. Full or Full (strict) is the durable fix.
Do I need to buy a certificate to leave Flexible? +
Not necessarily. Let’s Encrypt, host AutoSSL, or a free Cloudflare Origin CA certificate is enough for Full or Full (strict) when installed correctly.
Will Always Use HTTPS alone fix a Flexible loop? +
No. Always Use HTTPS upgrades visitors at the edge; under Flexible the origin hop is still HTTP, so an origin force-HTTPS redirect can continue the loop. Change the encryption mode.
Is a Flexible redirect loop the same as mixed content? +
No. Mixed content is an HTTPS page loading HTTP images/scripts. A Flexible redirect loop is a 301/302 cycle that prevents the page from loading at all.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.

Do not share passwords through an unencrypted contact form — use Password Pusher (self-destructing link). Prefer a dedicated Rescue 404 admin account, not your personal owner login; if you cannot create one yet, we will add ours after repair.

Written by Josh

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.