Skip to content
Rescue 404
Rescue

Cloudflare Errors

Cloudflare too many redirects

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Direct answer

Cloudflare “too many redirects” almost always means the SSL/TLS encryption mode is set to Flexible while the origin also redirects HTTP to HTTPS — Cloudflare terminates TLS at the edge, connects to the origin over plain HTTP, the origin bounces back to HTTPS, and the loop repeats forever. Switch to Full or Full (strict) with a valid origin certificate, then clear any duplicate force-HTTPS rules stacked on top.

This guide covers redirect loops that are specifically tied to Cloudflare’s proxy and SSL/TLS mode, as distinct from a plain WordPress or server redirect fight. The fix is almost always about which encryption mode Cloudflare uses to talk to your origin, not about WordPress plugins — though duplicate force-HTTPS layers can make the loop worse once the mode is wrong.

Intermediate

Key facts

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

  • Flexible SSL mode sends HTTP to the origin; if the origin redirects all HTTP to HTTPS, browsers hit an ERR_TOO_MANY_REDIRECTS loop. (ERR_TOO_MANY_REDIRECTS)
  • Full or Full (strict) with an origin that redirects HTTPS back to HTTP produces the same redirect-loop error. (ERR_TOO_MANY_REDIRECTS)
  • Always Use HTTPS at the edge redirects HTTP to HTTPS for all hosts; combined with an origin that forces HTTP, it loops. (Always Use HTTPS)

What the error means

When a domain is proxied through Cloudflare (orange cloud), visitors connect to Cloudflare first, and Cloudflare then opens a separate connection to your origin server based on the SSL/TLS encryption mode you have chosen. In Flexible mode, Cloudflare talks HTTPS to the visitor but plain HTTP to the origin. If the origin (via `.htaccess`, a WordPress force-HTTPS plugin, or the host panel) redirects all HTTP traffic to HTTPS, it sends that redirect back to Cloudflare, which forwards it to the visitor, who requests HTTPS again — and Cloudflare again connects to the origin over HTTP, repeating indefinitely. This is different from a WordPress-only redirect loop (mismatched siteurl/home with no CDU involved) and different from a single intentional redirect: the defining signal here is that pausing Cloudflare (grey-clouding the DNS record) or switching SSL/TLS mode changes the behavior immediately.

Common symptoms

  • Browser shows ERR_TOO_MANY_REDIRECTS or “redirected you too many times” only while Cloudflare is proxying the domain
  • DevTools Network shows a repeating chain of 301/302 responses alternating http and https
  • Grey-clouding the DNS record (Cloudflare set to DNS only) makes the loop stop immediately
  • The loop appeared right after enabling the Cloudflare proxy or changing SSL/TLS mode
  • wp-admin and the front end both loop the same way
  • Origin loads fine when accessed directly by IP with the correct Host header, bypassing Cloudflare
  • Cloudflare SSL/TLS overview page shows the mode set to Flexible

Most likely causes

  1. 01 Cloudflare SSL/TLS mode set to Flexible while the origin also force-redirects HTTP to HTTPS
  2. 02 Origin missing a valid SSL certificate, so Full (strict) fails and someone reverts to Flexible as a workaround
  3. 03 WordPress force-HTTPS plugin or `.htaccess` rule redirecting to HTTPS on top of Cloudflare’s own “Always Use HTTPS” setting
  4. 04 Cloudflare Page Rules or Redirect Rules duplicating a redirect the origin already performs
  5. 05 WordPress siteurl/home values still set to http:// while Cloudflare terminates HTTPS at the edge
  6. 06 Origin behind a load balancer that does not trust Cloudflare’s forwarded protocol header, so it keeps “upgrading” requests
  7. 07 Browser HSTS cache holding an old HTTPS-only rule from before the misconfiguration was introduced

What changed before the problem started

  • Cloudflare proxy (orange cloud) enabled on a domain that previously pointed straight at the origin
  • SSL/TLS encryption mode changed to or left on Flexible
  • A force-HTTPS plugin, Really Simple SSL, or similar tool activated on the origin
  • Cloudflare Always Use HTTTPS setting toggled on alongside an existing origin redirect
  • New Page Rule or Redirect Rule added for HTTPS enforcement
  • Origin SSL certificate expired or was never issued, blocking a move to Full (strict)

Troubleshooting steps

  1. 01

    Confirm the loop is Cloudflare-specific by grey-clouding the record

    In the Cloudflare DNS tab, temporarily switch the A/CNAME record from proxied (orange cloud) to DNS only (grey cloud), then reload the site directly against the origin. If the loop disappears, the cause is the interaction between Cloudflare’s SSL/TLS mode and the origin’s own redirect — not a plain WordPress misconfiguration.

  2. 02

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

    In Cloudflare, go to SSL/TLS → Overview and move off Flexible. Full encrypts edge-to-origin traffic over HTTPS using any certificate on the origin; Full (strict) additionally validates that certificate. This single change resolves the Flexible-plus-origin-redirect loop in the large majority of cases.

  3. 03

    Confirm the origin has a valid HTTPS certificate before using Full (strict)

    Full (strict) will fail edge-to-origin connections if the origin certificate is missing, expired, or self-signed and untrusted. Install a real certificate (Let’s Encrypt, host-provided SSL, or a Cloudflare Origin CA certificate) before switching to strict mode, or use plain Full mode temporarily instead.

  4. 04

    Re-enable the Cloudflare proxy and retest with cache cleared

    Set the DNS record back to proxied (orange cloud) now that SSL/TLS mode is corrected. Purge the Cloudflare cache and test in a private browser window so no cached redirect or HSTS rule masks whether the fix actually worked.

  5. 05

    Remove duplicate force-HTTPS layers

    Check whether Cloudflare’s Always Use HTTPS setting, a WordPress force-HTTPS plugin, and an `.htaccess`/host-panel redirect are all active at once. Keep exactly one enforcement layer — Cloudflare’s Always Use HTTPS is usually sufficient once SSL/TLS mode is Full or Full (strict).

  6. 06

    Align WordPress siteurl and home with https

    In Settings → General (or via `wp-config.php` WP_HOME/WP_SITEURL constants if admin is unreachable), set both WordPress Address and Site Address to the https:// version of your domain. A lingering http:// value can reintroduce a bounce even after Cloudflare’s mode is fixed.

When to stop troubleshooting

Escalate if you cannot access the Cloudflare dashboard or origin SSL settings, the origin has no valid certificate and you cannot install one (including a Cloudflare Origin CA certificate), the loop persists after confirming Full/Full (strict) and a single redirect layer, or checkout/login remain broken past your maintenance window. Provide the current SSL/TLS mode, DNS proxy status, and the DevTools redirect chain.

Information to collect before requesting help

  • 01 Current Cloudflare SSL/TLS encryption mode (Flexible, Full, or Full strict)
  • 02 Whether grey-clouding the DNS record stops the loop
  • 03 DevTools redirect chain showing the alternating http/https hops
  • 04 Whether the origin has a valid, unexpired SSL certificate
  • 05 Any active force-HTTPS plugins, Page Rules, or Redirect Rules
  • 06 WordPress siteurl and home values (http vs https)
  • 07 When the Cloudflare proxy or SSL/TLS mode was last changed

How a professional repairs the problem

A technician grey-clouds the domain to confirm the loop is Cloudflare-specific, then moves SSL/TLS mode to Full or Full (strict) after verifying or installing a valid origin certificate — using a Cloudflare Origin CA certificate when no public certificate is available. Duplicate force-HTTPS layers (plugin, `.htaccess`, and Cloudflare’s own Always Use HTTPS) are collapsed to one, WordPress URLs are aligned to https, and the fix is verified with cache purged and HSTS cleared before handing the site back.

Frequently asked questions

Why does turning Cloudflare off (grey cloud) fix the loop? +
Grey-clouding removes Cloudflare’s edge-to-origin hop entirely, so the browser talks straight to your server. If the loop disappears, the cause is specifically how Cloudflare’s SSL/TLS mode interacts with your origin’s own HTTPS redirect — not a general WordPress misconfiguration.
Is Flexible SSL ever safe to use? +
Flexible only encrypts the visitor-to-Cloudflare leg, leaving edge-to-origin traffic unencrypted, and it is the single most common cause of this exact redirect loop when the origin also forces HTTPS. Full or Full (strict) is recommended for any WordPress site with login or checkout.
Do I need to buy a certificate to fix this? +
Not necessarily. Cloudflare issues free Origin CA certificates you can install on the origin specifically for Full (strict) connections, in addition to options like Let’s Encrypt or a host-provided certificate.
Will disabling my WordPress SSL plugin fix the loop by itself? +
Only if that plugin was the sole redirect source. If Cloudflare’s SSL/TLS mode is still Flexible while the origin (via `.htaccess` or the host panel) redirects to HTTPS, the loop will continue even with the plugin off — fix the Cloudflare mode first.
Why does the loop only appear for some visitors? +
Cached redirects, HSTS state from a previous broken configuration, or different Cloudflare edge behavior can make the loop appear intermittent. Treat any occurrence as the same underlying SSL/TLS mode mismatch and fix it centrally rather than per-visitor.
Is this the same fix as the general ERR_TOO_MANY_REDIRECTS guide? +
It overlaps but is narrower: this guide is specifically about Cloudflare’s SSL/TLS mode causing the loop. If grey-clouding the domain does not stop the redirect, follow the general server-errors or SSL-errors too-many-redirects guide instead, since the cause is on the origin itself.

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.
Emergency repair Request diagnosis

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.