Cloudflare SSL modes explained

The four modes

The SSL/TLS settings of a Cloudflare zone control traffic on two legs: the visitor-to-edge leg, and the edge-to-origin leg. The mode you pick changes the second leg.

| Mode | Visitor to edge | Edge to origin | Origin requirement |

| Off | Plain HTTP | Plain HTTP | Nothing |

| Flexible | HTTPS | HTTP | Origin serves HTTP |

| Full | HTTPS | HTTPS | Origin serves HTTPS |

| Full (strict) | HTTPS | HTTPS | Valid origin cert for this hostname |

The exact wording of the modes can differ across the dashboard and UI: Flexible uses one label; Full and Full (strict) both appear under the same toggle, with strict as a sub-option. The choice matters because it decides whether the edge speaks HTTP or HTTPS to the origin.

What each mode does

• Off disables SSL on the visitor path entirely. Fine only for testing, never for a public site.
• Flexible is the historically common mode on shared hosting with no certificate: the visitor sees HTTPS, but Cloudflare talks to the origin over plain HTTP. It gives up end-to-end encryption and can race into redirect loops if the origin only redirects to HTTPS.
• Full assumes the origin has a certificate, yet does not verify it matches the hostname. Broken chains and expired certs are still tolerated, which is why some hosts run with Full before adding a real certificate.
• Full (strict) requires the origin certificate for the exact hostname and enforces a valid chain. This is the mode to run once the origin has a properly issued certificate (including Cloudflare's origin CA option).

Which mode should you pick

1. If your host cannot give you a certificate for the origin, start with Flexible only to get visitor-to-edge HTTPS working, then obtain a real origin certificate as soon as possible. Flexible should not remain the long-term choice for anything private.
2. Once the origin serves HTTPS, move to Full. This fixes the double-hop: the origin sees HTTPS and returns its content on the same protocol, which removes the HTTP-to-HTTPS redirect race that can otherwise surface as an err-too-many-redirects loop.
3. When the origin has a certificate from Let's Encrypt or a paid CA, move to Full (strict). Use a certificate that covers the exact hostname, or add a matching certificate to the host.

This maps back to the SSL/TLS overview as a decision aid:

| Your origin | Best mode |

| No certificate, HTTP only | Flexible (temporary) |

| Self-signed or host cert without hostname match | Full |

| Real certificate for exact hostname | Full (strict) |

Correcting a mode mistake

If the site shows 525 (handshake failed) or 526 (invalid certificate) at the edge, the fix usually starts with the mode, not with the certificate. Start with the table above, then test with the openssl command in the 525 guide.

If the origin redirects HTTP to HTTPS while the mode is Flexible, you get a loop. The right fix is still to move to Full or Full strict with a real certificate, not to weaken the origin redirect.

Prevention

• After any hosting move or certificate renewal, re-check the mode once.
• Set a reminder so you never leave Flexible running when the origin actually owns a certificate: that pairing gains nothing.