Cloudflare Flexible SSL: What It Actually Encrypts, the Redirect Loop It Causes, and How to Move to Full (Strict)

Cloudflare Flexible SSL encrypts traffic between the visitor and Cloudflare, then sends it to your server over plain HTTP. The browser shows a padlock; the second half of the journey is unencrypted. It exists so that a site with no certificate on its origin can show HTTPS, and it is the cause of the two most common Cloudflare support questions: the ERR_TOO_MANY_REDIRECTS loop when the origin forces HTTPS, and mixed content warnings when the app builds URLs from the scheme it sees. The fix is to put a certificate on the origin and switch the mode to Full (strict), which takes about ten minutes.

The Cloudflare docs describe the mode accurately and then, in the prerequisites, mention in passing that you may have to adjust settings to avoid redirect loops. That understates it. If your origin does anything sensible about HTTPS, Flexible breaks it. This post explains the mechanism so that the fix makes sense, then gives the steps.

Table of contents

• What Flexible mode does, and does not
• The redirect loop, step by step
• Mixed content and the other symptoms
• Why Full (strict) is the right setting
• Moving off Flexible: the steps
• What this looks like on a managed host
• How this fits the rest of the stack
• FAQ

What Flexible mode does, and does not

Cloudflare sits between the visitor and your server as a reverse proxy. The SSL/TLS encryption mode controls the second hop, from Cloudflare to your origin.

• Off. No HTTPS anywhere. Nobody should use this.
• Flexible. Visitor to Cloudflare is HTTPS. Cloudflare to origin is HTTP on port 80. The origin needs no certificate.
• Full. Both hops are HTTPS. The origin needs a certificate, but Cloudflare does not validate it; a self-signed one works.
• Full (strict). Both hops are HTTPS and the origin certificate must be valid: either a publicly trusted one or a Cloudflare Origin CA certificate.

Flexible was designed for a world where getting a certificate onto a server was hard. That world ended when free certificates became a one-line command. Today Flexible is a legacy default that persists because it is the mode that works when the origin has nothing configured, which makes it the mode people leave on.

The thing to hold onto: under Flexible, your origin receives plain HTTP requests and does not know the visitor used HTTPS unless it reads the X-Forwarded-Proto header Cloudflare adds.

The redirect loop, step by step

Here is the sequence that produces ERR_TOO_MANY_REDIRECTS, which is the error Chrome shows after about twenty hops.

1. The visitor requests https://example.com. Cloudflare terminates the TLS connection.
2. Flexible mode forwards the request to the origin as http://example.com.
3. The origin has a rule that says all HTTP requests must redirect to HTTPS. This is the correct rule for a server that expects to be reached directly. It returns 301 to https://example.com.
4. Cloudflare passes the redirect to the visitor. The visitor follows it, requesting https://example.com again.
5. Go to step 2.

The origin is not wrong. Cloudflare is not wrong. They simply disagree about what protocol the request used, and neither can see the other’s view. The loop is the disagreement made visible.

The redirect rule can live in several places, which is why people often cannot find it: an nginx or Apache rewrite, a WordPress site URL set to https, a framework setting like Django’s SECURE_SSL_REDIRECT or Rails force_ssl, or a hosting panel’s Force HTTPS toggle. Any one of them triggers the loop.

Mixed content and the other symptoms

The loop is the loud failure. Flexible also causes quieter ones.

Mixed content. An application that builds absolute URLs from the request scheme sees http, so it emits http:// links for its stylesheets and scripts. The browser, on an HTTPS page, blocks them. The page loads unstyled or with broken images and the console fills with mixed content warnings. WordPress is the usual victim because its site URL setting drives every generated link.

Cookies that will not stick. A session cookie set with the Secure flag by a framework that thinks it is on HTTP, or a framework that refuses to set Secure because it sees HTTP, produces logins that fail silently.

OAuth and webhook callbacks. A callback URL generated as http:// does not match the https:// URL registered with the provider. The provider rejects it.

The workaround for all of these is to make the application trust X-Forwarded-Proto. The fix is to stop sending it plain HTTP in the first place.

Why Full (strict) is the right setting

Full (strict) means the origin has a valid certificate and Cloudflare checks it. That is the only mode where the connection is encrypted end to end and Cloudflare can detect an impostor origin.

Full without strict is a common halfway house. It encrypts the second hop but does not verify the certificate, which means anyone who can redirect Cloudflare’s traffic to their own server gets accepted. It is better than Flexible and worse than it looks.

The objection is usually that the origin certificate is a hassle. It is not, for two reasons. Cloudflare issues a free Origin CA certificate valid for up to fifteen years, trusted only by Cloudflare, which is exactly what a proxied origin needs. Or the origin can use a standard free certificate from a public CA, which any managed host issues automatically.

Moving off Flexible: the steps

Do these in order. The mode switch is last, because switching before the origin is ready produces a 526 error instead of a redirect loop.

1. Put a certificate on the origin. Either generate an Origin CA certificate in the Cloudflare dashboard under SSL/TLS, Origin Server, and install it in your web server, or run certbot on the origin for a public certificate. Note that certbot’s HTTP challenge works through Cloudflare’s proxy; the DNS challenge is more reliable if you have many domains.
2. Make the origin listen on 443. Confirm with curl -vk https://ORIGIN_IP -H Host:example.com from outside the box. You want a TLS handshake and a real response, not a connection refused.
3. Leave the HTTP to HTTPS redirect in place. It is correct once the mode changes.
4. Switch the mode. SSL/TLS, Overview, set to Full (strict). Propagation is near-instant.
5. Test. Load the site in a private window. Check the console for mixed content. Log in. If you get a 526, the certificate on the origin does not match the hostname or is not trusted; if you get a 521, nothing is listening on 443.

Then turn on Always Use HTTPS in Cloudflare so that the edge does the redirect and the origin never sees an HTTP request at all.

What this looks like on a managed host

Most of the friction above comes from the origin being a server you configure. On a host that issues certificates automatically, the origin already speaks HTTPS with a valid certificate, so Full (strict) is the only mode that makes sense and Flexible is actively harmful.

A static site or a web service on RunxBuild, for example, gets a certificate for its custom domain on its own. If you put Cloudflare in front of it, set Full (strict) on day one. Set Flexible and you get the redirect loop immediately, because the platform enforces HTTPS at the edge, exactly as it should.

How this fits the rest of the stack

Flexible is the mode you end up in by default and leave because the padlock looks fine. It is worth the ten minutes to leave it. Once the origin has a real certificate and the mode is Full (strict), the redirect loop, the mixed content and the cookie oddities all go away together. If the origin is on a managed host, that certificate is already there: custom domains and certificates on RunxBuild describes what the platform issues. And if you are weighing what the origin itself should cost, the RunxBuild hosting calculator puts the site, the service and the bandwidth on one page.

Useful related references:

• Cloudflare TLS Termination: The Encryption Modes and the One That Is a Trap
• Cloudflare Error 502: The Three Places a 502 Actually Comes From, and the Decision Tree That Tells You Which
• namecheap with cloudflare: The Three Modes and the One That Actually Saves Money
• Custom domains and certificates on RunxBuild

FAQ

Is Cloudflare Flexible SSL secure?

Only halfway. The visitor to Cloudflare hop is encrypted; Cloudflare to your server is plain HTTP. Anyone between Cloudflare and your origin can read the traffic. Use Full (strict) with a certificate on the origin for end-to-end encryption.

Why does Cloudflare Flexible cause a redirect loop?

Cloudflare forwards HTTPS requests to your origin as HTTP. If the origin redirects HTTP to HTTPS, Cloudflare passes that redirect to the visitor, who requests HTTPS again, and the cycle repeats until the browser gives up with ERR_TOO_MANY_REDIRECTS.

What is the difference between Full and Full (strict)?

Both encrypt the hop to the origin. Full accepts any certificate, including self-signed and expired ones, without checking it. Full (strict) requires a certificate that is valid for the hostname, either publicly trusted or a Cloudflare Origin CA certificate.

How do I get a certificate on my origin for Full (strict)?

Generate a free Origin CA certificate in the Cloudflare dashboard and install it in your web server, or use certbot for a public certificate. On a managed host, the certificate is issued automatically and no step is needed.

Should I use Flexible if my host does not support HTTPS?

Briefly, while you move to a host that does. A host that cannot serve HTTPS in 2026 is the problem to fix, and Flexible only hides it from the visitor’s browser.