Cloudflare Error 526 and the Redirect Loop: Two Failures, One Setting

The short answer

Two different symptoms, one setting, opposite directions.

ERR_TOO_MANY_REDIRECTS          -> SSL/TLS mode is Flexible
Error 526 Invalid SSL certificate -> SSL/TLS mode is Full (strict)

Fix both by setting the mode to Full, exactly:

Cloudflare dashboard, the zone holding your domain, SSL/TLS, Overview, set encryption mode to Full.

Confirm what the edge is actually doing:

# does the origin redirect, and to where
curl -sI https://origin.example.com/ | grep -iE "^(HTTP|location)"

# what Cloudflare returns, bypassing browser cache entirely
curl -sI "https://example.com/?cb=$(date +%s)" | grep -iE "^(HTTP|cf-|location)"

# is the record proxied (orange) or DNS only (grey)
dig +short example.com

An IP in Cloudflare's ranges means proxied. Your origin's own IP means DNS only, in which case none of this applies.

Tested on Caddy based ingress, Cloudflare as of August 2026.

Why one setting produces two opposite failures

Cloudflare's SSL/TLS mode governs only the second hop: how Cloudflare connects to your origin. The browser to Cloudflare hop is always HTTPS. People assume the setting is about their visitors, which is why the failures are so confusing.

The Flexible loop, step by step

1. Browser requests https://example.com, reaching Cloudflare over TLS.
2. Cloudflare fetches your origin over plain HTTP.
3. Your origin redirects HTTP to HTTPS, which nearly every managed platform does unconditionally.
4. Cloudflare passes that 301 back to the browser.
5. The browser dutifully requests https://example.com again.
6. Go to step 2.

The browser gives up after about twenty round trips with ERR_TOO_MANY_REDIRECTS. Nothing is broken at either end. The two halves simply disagree about which scheme the request is already using.

The Full strict 526

Full (strict) requires the origin certificate to chain to a public CA and to match the hostname.

Managed platforms that terminate TLS for you frequently serve an internal, self signed certificate on the origin hop, because the public certificate lives at their ingress tier rather than on your machine. That is deliberate: it means a domain works the instant you point it, with no certificate provisioning race.

Full (strict) rejects exactly that, and returns 526.

The trap is that Cloudflare's own documentation generally recommends "Full or higher". On a platform with a managed ingress, higher is the setting that breaks it. Read a recommendation like that as being about origins you provision certificates on yourself.

The causes, in the order I check them

1. Mode is Flexible and the origin forces HTTPS

By far the most common. Flexible was the historical default for years, so old zones carry it forward and nobody revisits it.

Confirm by asking whether the origin redirects:

curl -sI http://origin.example.com/ | grep -iE "^(HTTP|location)"
# HTTP/1.1 301 Moved Permanently
# location: https://origin.example.com/

If that redirect exists and your mode is Flexible, you have found it.

2. Mode is Full strict against a managed origin certificate

Check what the origin actually presents:

openssl s_client -connect origin.example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -issuer -subject

If the issuer is internal rather than a public CA, Full (strict) cannot work and there is nothing to install on your side to make it work. The certificate is managed by the platform.

This is also worth separating from a genuinely broken chain. A missing intermediate produces different errors and is fixable at the origin. An internal certificate on a managed ingress is by design.

3. The mode is right and Cloudflare is serving a cached redirect

Cloudflare caches redirects, so a zone that was looping before you fixed it can keep looping afterwards.

Purge everything, then test in a private window. If curl with a cache buster works and the browser does not, it is cache, not configuration.

4. The record is grey cloud and you are debugging the wrong thing

DNS only means Cloudflare is not in the request path at all. There is no SSL/TLS mode in play and the certificate is issued directly for your domain. If the site is broken on grey cloud, the problem is at the origin and Cloudflare is a red herring.

The reverse is the useful diagnostic: works on grey, breaks on orange is almost always the SSL/TLS mode.

5. Page Rules or Configuration Rules overriding the zone setting

The zone level mode can be overridden per path. A rule setting SSL to Flexible on /* will beat your Overview setting and is easy to forget, because rules live in a different part of the dashboard.

Getting the truth out of it

# full request chain, showing every redirect hop
curl -sIL "https://example.com/?cb=$(date +%s)" | grep -iE "^(HTTP|location|cf-cache|server)"

# what the origin says when you skip Cloudflare completely
curl -sI --resolve example.com:443:ORIGIN_IP https://example.com/ | head -5

That second command is the one that settles arguments. It sends the correct SNI and Host header directly to your origin, bypassing the edge. If the origin responds correctly there and fails through Cloudflare, the problem is between them.

Prevention

• Set the mode to Full before you switch a record to proxied, not after. Both failures become impossible.
• Treat "Full or higher" advice as conditional. Higher is correct only when you control the origin certificate.
• When a domain breaks immediately after enabling the orange cloud, check the SSL/TLS mode before anything else. It is one click and it is usually the answer.
• Purge the Cloudflare cache after fixing a redirect loop, or you will conclude the fix did not work. That is the same false negative as a cached CORS preflight, where the browser stops asking and keeps enforcing an old answer.
• Document the mode alongside the DNS record. It is invisible from the DNS panel, so the next person will not know it exists.