
How do I enable Cloudflare SSL/HTTPS on an existing site and avoid redirect loops?
Most teams enabling Cloudflare SSL/HTTPS on an existing site run into the same two questions: “Which SSL mode should I choose?” and “How do I avoid redirect loops that knock the site offline?” The good news: if you follow a clear sequence—origin first, Cloudflare second, redirects last—you can turn on HTTPS safely and keep traffic stable.
Quick Answer: Enable valid HTTPS between your origin and visitors first, set Cloudflare SSL/TLS mode to the correct level (usually Full (strict)), and centralize redirects either on the origin or at Cloudflare — not both. Redirect loops almost always come from mismatched SSL modes and duplicate or misconfigured HTTP→HTTPS redirects.
The Quick Overview
- What It Is: Turning on Cloudflare SSL/HTTPS means all traffic to your domain is routed through Cloudflare’s global connectivity cloud, encrypted with TLS from the visitor to Cloudflare, and (in secure modes) encrypted again from Cloudflare to your origin.
- Who It Is For: Site owners and admins migrating an existing HTTP or HTTPS site onto Cloudflare, especially those worried about downtime, mixed content, or “too many redirects” errors.
- Core Problem Solved: You get modern TLS, HSTS, and performance from Cloudflare’s edge without breaking existing redirects or causing redirect loops between your origin and Cloudflare.
How It Works
Cloudflare sits in front of your site as a reverse proxy. Visitors connect over HTTPS to Cloudflare’s edge; Cloudflare then connects to your origin server over HTTP or HTTPS depending on your SSL/TLS configuration.
At a high level:
-
Set up HTTPS at the origin (or with Cloudflare certificates):
Make sure your origin can serve HTTPS, either with your own certificate or a Cloudflare Origin CA certificate. -
Select the right Cloudflare SSL/TLS mode:
Choose the SSL mode that matches how your origin is configured: Off, Flexible, Full, or Full (strict). In almost all modern deployments, you want Full (strict). -
Configure redirects and HSTS carefully:
Ensure you do not create a loop between origin-level redirects and Cloudflare-level “Always Use HTTPS” or page rules. Test and then optionally add HSTS.
1. Prepare HTTPS at the Origin
For an existing site, start by confirming what your origin can do today:
-
If your origin already has a valid HTTPS certificate:
- Confirm you can visit
https://yourdomain.comdirectly (by editing your local hosts file to bypass Cloudflare or by hitting the origin IP). - Verify there are no certificate errors (hostname mismatch, expired cert, self‑signed, etc.).
- Confirm you can visit
-
If your origin does not have HTTPS yet: You have two common options:
-
Use Cloudflare Origin CA Certificate
- In the Cloudflare dashboard, go to SSL/TLS → Origin Server → Create Certificate.
- Generate an Origin CA certificate and key.
- Install the certificate and key on your origin server (Apache, Nginx, IIS, etc.).
- Configure your web server to listen on port 443 and serve that certificate.
-
Use a public CA (e.g., Let’s Encrypt)
- Issue a certificate for your domain and install it on the origin.
- Ensure HTTPS is listening and working before you change DNS to Cloudflare.
-
Once HTTPS works directly at the origin, you’re ready to tune Cloudflare.
2. Choose the Correct Cloudflare SSL/TLS Mode
In the Cloudflare dashboard:
- Go to SSL/TLS → Overview.
- Choose the appropriate SSL/TLS encryption mode:
-
Off
- No HTTPS between visitor and Cloudflare. Avoid for production.
-
Flexible
- Visitor → Cloudflare: HTTPS
- Cloudflare → Origin: HTTP
- Only use this if your origin cannot support HTTPS at all.
- Can easily create redirect loops if your origin tries to redirect HTTP→HTTPS.
-
Full
- Visitor → Cloudflare: HTTPS
- Cloudflare → Origin: HTTPS (certificate not fully validated)
- Encryption is in place, but Cloudflare does not validate the certificate against a CA.
-
Full (strict)
- Visitor → Cloudflare: HTTPS
- Cloudflare → Origin: HTTPS with a valid certificate (public CA or Origin CA) and matching hostname.
- Recommended for most existing sites once the origin has a proper certificate.
Best practice:
- If your origin has a valid certificate (including Cloudflare Origin CA), use Full (strict).
- Avoid Flexible unless you have no way to serve HTTPS from your origin. It is the most common cause of redirect loops.
3. Avoid Redirect Loops With Clean HTTP→HTTPS Logic
Redirect loops (often seen as “ERR_TOO_MANY_REDIRECTS” or a Cloudflare 520/522-style loop) usually come from conflicting or repeated redirects between:
- Your origin server (Apache/Nginx/IIS, app framework,
.htaccess). - Cloudflare features:
- SSL/TLS → Edge Certificates → Always Use HTTPS
- SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS)
- Page Rules set to “Always Use HTTPS”
- Redirect Rules in the Rules section
To avoid loops, follow this sequence:
-
Pick where you enforce HTTP→HTTPS — origin or Cloudflare, not both.
- Option A: Enforce on origin only, leave Cloudflare without “Always Use HTTPS”.
- Option B: Enforce on Cloudflare only, remove HTTP→HTTPS redirects from the origin.
-
If your origin logic checks for HTTPS, make it Cloudflare-aware.
When Cloudflare connects to your origin over HTTPS, the connection is encrypted, but depending on your stack,HTTPSorSERVER_PORTvariables might not reflect that. UseCF-Visitor,X-Forwarded-Proto, or similar headers to detect HTTPS correctly, and avoid self-redirects. -
Do not combine Flexible SSL + origin HTTPS redirect.
- If you use Flexible, the origin always sees HTTP from Cloudflare.
- If the origin redirects HTTP→HTTPS, Cloudflare will request HTTPS, but still advertise HTTP to the origin in the next request, causing an infinite loop.
Minimal, safe pattern:
- Use Full (strict).
- Enable Always Use HTTPS in SSL/TLS → Edge Certificates.
- Either:
- Remove any HTTP→HTTPS redirect rules from your origin, or
- Make them conditional using headers (e.g., only redirect if
X-Forwarded-Protoishttpand you’re not behind Cloudflare).
Features & Benefits Breakdown
| Core Feature | What It Does | Primary Benefit |
|---|---|---|
| SSL/TLS Modes (Off → Full strict) | Controls how Cloudflare encrypts traffic between visitors, edge, and origin | Lets you match your actual origin setup and avoid misconfigurations |
| Cloudflare Origin CA | Issues certificates trusted by Cloudflare for origin-to-edge HTTPS | Enables strong encryption (Full strict) without buying public CA certs |
| Always Use HTTPS & Redirect Rules | Forces HTTP requests to be served over HTTPS | Centralized, simple HTTP→HTTPS migration without risky custom logic |
Ideal Use Cases
-
Best for existing HTTP-only sites migrating to Cloudflare:
Because you can use Cloudflare Origin CA and Full (strict) to introduce HTTPS securely without re-architecting everything at once. -
Best for existing HTTPS sites that want to avoid downtime:
Because you can leave your origin TLS as-is, set Cloudflare to Full (strict), and carefully transfer redirect logic to Cloudflare’s edge, minimizing the chance of redirect loops.
Common Redirect Loop Patterns (and How to Fix Them)
Pattern 1: Flexible SSL + Origin HTTP→HTTPS Redirect
-
Symptoms:
- Site shows “too many redirects”.
- Works when Cloudflare is in “DNS-only” (grey-cloud) mode but breaks when proxied (orange-cloud).
-
Why it happens:
- Cloudflare connects to the origin over HTTP (Flexible).
- Origin redirects HTTP→HTTPS.
- Cloudflare obeys the redirect and asks for HTTPS.
- Cloudflare still reports HTTP to origin, so origin redirects again.
-
Fix:
- Switch to Full or Full (strict) and enable HTTPS at the origin, or
- Remove the HTTP→HTTPS redirect from the origin and enforce HTTPS at Cloudflare only.
Pattern 2: Double HTTP→HTTPS Enforcement (Origin + Cloudflare)
-
Symptoms:
- Some URLs work, others loop; or mobile subdomains behave differently.
- Complex
.htaccessor rewrite rules plus “Always Use HTTPS” or Redirect Rules.
-
Why it happens:
- Both Cloudflare and your origin are trying to redirect based on different conditions (host, path, scheme).
-
Fix:
- Choose a primary enforcement point:
- If you prefer origin control: disable Always Use HTTPS and simplify origin rules.
- If you prefer Cloudflare control: remove origin redirects and create targeted Redirect Rules or enable “Always Use HTTPS”.
- Choose a primary enforcement point:
Pattern 3: App-Level HTTPS Assumptions
-
Symptoms:
- Application frameworks (WordPress, Laravel, Django, etc.) keep redirecting or generate
http://URLs that get rewritten over and over.
- Application frameworks (WordPress, Laravel, Django, etc.) keep redirecting or generate
-
Why it happens:
- The app can’t correctly detect HTTPS when behind a proxy.
- Framework sees
httpinternally, thinks it must redirect tohttps, but Cloudflare is already handling HTTPS.
-
Fix:
- Configure your app to trust Cloudflare headers (e.g.,
X-Forwarded-Proto,CF-Visitor). - Enable the appropriate “behind a reverse proxy” or “HTTPS offload” setting for the framework.
- Configure your app to trust Cloudflare headers (e.g.,
Limitations & Considerations
-
Origin certificate scope:
- Cloudflare Origin CA certificates are only trusted between Cloudflare and your origin, not by browsers directly. They’re ideal for Full (strict) but not for direct-origin browsing.
-
Legacy HTTP-only origins:
- If you truly cannot enable HTTPS on your origin and must use Flexible, carefully ensure:
- Your origin does not redirect HTTP→HTTPS.
- All HTTPS enforcement happens at Cloudflare’s edge only.
- This is workable, but not as secure as encrypting all the way to the origin.
- If you truly cannot enable HTTPS on your origin and must use Flexible, carefully ensure:
Pricing & Plans
Cloudflare’s core SSL/TLS and HTTPS features—including SSL modes, Origin CA, and basic HTTP→HTTPS redirection—are available across plan types, from Free to Enterprise.
-
Self-serve plans (Free, Pro, Business):
Best for individuals, small teams, and smaller businesses that need HTTPS, basic WAF, and caching without complex enterprise requirements. -
Enterprise plan:
Best for organizations needing strict compliance, 100% uptime SLAs, advanced WAF and DDoS protection, HTTP/2/3, mutual TLS, keyless SSL (keep private keys on-prem), and dedicated support for phased migrations.
For advanced control, performance SLAs, and help designing a no-downtime SSL/HTTPS rollout, contact Cloudflare for Enterprise.
Frequently Asked Questions
How do I know which Cloudflare SSL/TLS mode to choose for my existing site?
Short Answer:
If your origin already supports HTTPS with a valid certificate (including Cloudflare Origin CA), use Full (strict). Use Flexible only as a last resort when the origin cannot handle HTTPS at all.
Details:
- Full (strict) verifies that your origin certificate is valid (not expired, correct hostname, trusted by Cloudflare or a public CA). This is the recommended mode for strong security.
- Full encrypts traffic but doesn’t validate the certificate; it’s acceptable as a temporary step while you improve your origin TLS.
- Flexible should be used only if you have no access or ability to enable HTTPS on the origin. It’s more prone to redirect loops because the origin sees only HTTP.
How do I fix a “too many redirects” error after enabling Cloudflare HTTPS?
Short Answer:
Align your SSL mode with your origin, remove duplicate HTTP→HTTPS redirects, and enforce HTTPS either at the origin or at Cloudflare—but not both.
Details:
- Confirm whether your origin supports HTTPS and with what certificate.
- Set Cloudflare to Full (strict) if possible.
- Temporarily disable:
- “Always Use HTTPS”
- Any Page Rules or Redirect Rules forcing HTTPS
- Test your site directly against the origin to see how it redirects without Cloudflare.
- Simplify origin redirects to a single, predictable HTTP→HTTPS path.
- Re-enable HTTPS enforcement at one layer:
- Either clean origin redirects, or
- Cloudflare “Always Use HTTPS” / Redirect Rules (with origin redirects removed).
Once the redirect chain from HTTP to HTTPS is a single step, the loop will stop.
Summary
Enabling Cloudflare SSL/HTTPS on an existing site without causing redirect loops comes down to sequence and clarity:
- Get HTTPS working between Cloudflare and your origin (ideally with Full (strict) using a valid or Origin CA certificate).
- Select the SSL/TLS mode that matches your real origin capabilities.
- Centralize HTTP→HTTPS redirects at one layer and make your app proxy-aware.
If you can point to exactly where a request is encrypted, where it’s evaluated, and where it’s redirected, you can run a defensible, stable HTTPS deployment on Cloudflare’s connectivity cloud.