How do I enable Cloudflare SSL/HTTPS on an existing site and avoid redirect loops?

Most teams can turn on Cloudflare SSL/HTTPS in minutes, but the part that trips people up is redirect loops: the browser keeps bouncing between HTTP and HTTPS or between the origin and Cloudflare until the page fails. The fix is to configure Cloudflare SSL mode and your origin redirects so they agree on where and how HTTPS is enforced.

Quick Answer: Cloudflare provides free SSL/TLS for your existing site and terminates HTTPS at its global edge, but you must choose the right SSL mode (usually “Full” or “Full (strict)”), update origin redirects to avoid double-redirects, and ensure your app trusts Cloudflare’s X-Forwarded-Proto / CF-Visitor headers to stop redirect loops.

The Quick Overview

What It Is: Cloudflare SSL/HTTPS is a connectivity cloud feature that lets you serve your site securely over HTTPS through Cloudflare’s global network, even if your origin doesn’t yet have a public TLS certificate.
Who It Is For: Site owners, developers, and security teams who want to enable HTTPS, improve performance, and add WAF/DDoS protection without breaking existing apps or causing redirect loops.
Core Problem Solved: It simplifies SSL deployment and enforces encryption between users, Cloudflare, and your origin while eliminating fragile, conflicting redirect rules that cause infinite HTTPS redirects.

How It Works

Cloudflare sits in front of your existing site as a reverse proxy. Visitors connect to Cloudflare over HTTPS using a certificate presented by Cloudflare’s edge. Cloudflare then connects to your origin over HTTP or HTTPS, depending on your SSL mode and origin setup.

To avoid redirect loops, you need a clear policy for where HTTPS is enforced:

At Cloudflare’s edge (edge redirects / Page Rules / Redirect Rules).
At your origin (web server or application-level redirects).
Or a combination, but in a way that doesn’t send the same request back and forth between HTTP and HTTPS.

Here’s the basic flow when correctly configured:

Visitor types http://example.com.
Cloudflare receives the HTTP request and (optionally) redirects it once to https://example.com.
Browser connects to https://example.com (still terminating at Cloudflare).
Cloudflare talks to your origin using one, consistent scheme (HTTP or HTTPS) that your origin expects, without triggering additional forced HTTPS redirects.

Step-by-step phases

Phase 1 – Prepare DNS and SSL mode:
- Point your DNS to Cloudflare and ensure orange-cloud proxy is enabled.
- Choose the correct SSL/TLS mode for your origin (Off / Flexible / Full / Full (strict)).
Phase 2 – Turn on HTTPS and origin encryption:
- Enable HTTPS at the edge (Automatic HTTPS Rewrites, Always Use HTTPS if appropriate).
- Install a certificate on your origin (Cloudflare Origin CA or public CA) and move to Full (strict) when possible.
Phase 3 – Prevent and fix redirect loops:
- Clean up conflicting server redirects (.htaccess, Nginx, IIS, application frameworks).
- Use Cloudflare headers (X-Forwarded-Proto, CF-Visitor) in origin logic to detect when the request is already HTTPS at the edge.
- Test with tools like curl -I and dev tools to verify there’s at most one redirect.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Cloudflare SSL/TLS mode	Controls how Cloudflare connects to your origin (Off, Flexible, Full, Full strict).	Ensures encrypted paths end-to-end without breaking your site.
Edge HTTPS enforcement	Redirects HTTP → HTTPS at the edge via “Always Use HTTPS” or rules.	Centralizes redirect logic, reducing loops and config drift.
Origin-aware redirect control	Uses headers like `X-Forwarded-Proto` and `CF-Visitor` so your origin knows the true client scheme.	Prevents your origin from redirecting HTTPS requests back to HTTPS, stopping infinite loops.

Ideal Use Cases

Best for migrating an existing HTTP site to HTTPS: Because Cloudflare can terminate HTTPS at the edge immediately, then you can gradually add an origin certificate and tighten security to Full (strict) without downtime.
Best for securing a legacy app behind many load balancers/proxies: Because Cloudflare’s headers and edge redirects give you a single, consistent place to enforce HTTPS and simplify complex, error-prone redirect logic at the origin.

Phase 1: Prepare DNS and Choose the Right SSL/TLS Mode

1. Onboard your site to Cloudflare

Add your domain to Cloudflare.
Cloudflare scans existing DNS records.
Update nameservers at your registrar to point to Cloudflare.
Ensure your “A” and “CNAME” records for the site have the orange cloud (proxied) enabled. Without proxy, Cloudflare isn’t in the path and can’t manage HTTPS for that traffic.

2. Understand Cloudflare SSL/TLS modes

This is where many redirect loops start. The SSL mode defines how Cloudflare connects to your origin:

Off:
- Visitors can’t use HTTPS through Cloudflare.
- Origin connections are HTTP only.
- Not recommended for production.
Flexible:
- Visitors connect to Cloudflare with HTTPS.
- Cloudflare connects to your origin with HTTP.
- Can cause redirect loops if your origin also tries to enforce HTTPS or assumes direct HTTPS connections.
- Use only as a temporary workaround when you cannot install a certificate on the origin.
Full:
- Visitors connect to Cloudflare with HTTPS.
- Cloudflare connects to your origin over HTTPS, but doesn’t validate the certificate.
- Works with self-signed or Cloudflare Origin CA certificates.
- Better than Flexible, but you still don’t have certificate validation.
Full (strict):
- Visitors connect to Cloudflare with HTTPS.
- Cloudflare connects to your origin over HTTPS and validates the certificate (trusted CA or Cloudflare Origin CA, correct hostname, not expired).
- Recommended for production. This is the “clean” end-to-end TLS configuration.

Best practice:

Avoid Flexible SSL if at all possible. It’s the most common source of redirect loops when origins also try to enforce HTTPS.
Aim for Full (strict) using a Cloudflare Origin CA certificate or a standard TLS certificate on your origin.

Phase 2: Turn On HTTPS and Encrypt to the Origin

1. Enable edge HTTPS for visitors

Within Cloudflare’s dashboard:

Automatic HTTPS Rewrites
- Helps rewrite http:// asset links in HTML to HTTPS where safe, reducing mixed content warnings.
Always Use HTTPS
- Forces all HTTP requests to redirect to HTTPS at the edge.
- Use this when you no longer need to serve plain HTTP to visitors.

You can also use Redirect Rules or Page Rules for more granular control (e.g., redirect only specific paths to HTTPS).

2. Add / update your origin certificate

To move away from Flexible and prevent loops:

Issue an origin certificate:
- Either a Cloudflare Origin CA cert (trusted by Cloudflare edge)
- Or a public certificate (Let’s Encrypt, commercial CA).
Install it on your web server (Apache, Nginx, IIS, etc.).
Configure your web server:
- Enable HTTPS listener/virtual host.
- Ensure it listens on the correct ports (usually 443).
In Cloudflare, switch SSL/TLS mode to Full (strict).

Once this is done, Cloudflare handles TLS on both legs:

Visitor ↔ Cloudflare (Cloudflare’s public cert)
Cloudflare ↔ Origin (your origin cert, validated)

Phase 3: Prevent and Fix Redirect Loops

Redirect loops usually come from Cloudflare and the origin both trying to force HTTPS, or the origin misinterpreting the request scheme because it’s behind a proxy.

Common loop scenario

Cloudflare SSL mode: Flexible
Origin web server: “Redirect all HTTP to HTTPS” rule enabled
Request flow:
1. Visitor hits http://example.com.
2. Cloudflare presents HTTPS to the visitor, but uses HTTP to talk to the origin (because of Flexible).
3. Origin sees HTTP and redirects to HTTPS (e.g., https://example.com).
4. That HTTPS URL still terminates on Cloudflare. Cloudflare again makes HTTP to the origin.
5. Origin again redirects to HTTPS.
  → Infinite loop.

Fixes for Flexible loops

Preferred fix: Stop using Flexible.
- Install an origin certificate and switch to Full (strict).
Interim workaround (if you must stay on Flexible temporarily):
- Remove or disable origin-level “force HTTPS” redirects.
- Let Cloudflare handle HTTPS enforcement at the edge.

Using headers so your origin knows it’s already HTTPS

Even with Full / Full (strict), you might run into loops if your app or server checks $_SERVER['HTTPS'], server.port, or similar, and doesn’t understand that Cloudflare is terminating TLS.

Cloudflare adds these headers:

X-Forwarded-Proto: http or https
CF-Visitor: {"scheme":"https"}

Update your redirect logic to respect these:

Example: Nginx

# Instead of naive: if ($scheme = http) { return 301 https://$host$request_uri; }

# Use Cloudflare headers to detect real client scheme
map $http_cf_visitor $cf_scheme {
    default "http";
    "~\"scheme\":\"https\"" "https";
}

server {
    listen 80;
    server_name example.com;

    if ($cf_scheme = "http") {
        return 301 https://$host$request_uri;
    }

    # ...other config...
}

Example: Apache (.htaccess)

# Avoid redirecting when the original request was already HTTPS at the edge
RewriteEngine On

# Use X-Forwarded-Proto from Cloudflare
RewriteCond %{HTTP:X-Forwarded-Proto} !https
RewriteRule ^(.*)$ https://%{HTTP_HOST}/$1 [L,R=301]

Example: PHP application logic

function is_https_request() {
    if (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off') {
        return true;
    }

    // Trust Cloudflare headers
    if (!empty($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
        return true;
    }

    if (!empty($_SERVER['HTTP_CF_VISITOR'])) {
        $visitor = json_decode($_SERVER['HTTP_CF_VISITOR'], true);
        if (!empty($visitor['scheme']) && $visitor['scheme'] === 'https') {
            return true;
        }
    }

    return false;
}

Then use is_https_request() instead of raw $_SERVER['HTTPS'] when deciding to redirect.

Remove duplicate redirects

Do not enforce HTTPS in multiple places blindly:

Cloudflare edge:
- “Always Use HTTPS”
- HTTPS redirect rules
Origin web server:
- RewriteRule / return 301 for protocol changes
Framework level:
- “force_ssl” (e.g., in Laravel, Rails, Django settings)
- Load balancer / ingress settings

Choose one primary layer to enforce HTTP→HTTPS for most requests, then:

Keep any origin/framework redirect rules that are strictly necessary for:
- Canonical host (www vs apex)
- Path normalization (e.g., trailing slash)
Ensure redirects are a single, deterministic chain (e.g., http://example.com → https://www.example.com/ and done).

How to detect a redirect loop

Use your browser dev tools or curl:

curl -I http://example.com
curl -I -L http://example.com  # follows redirects

Look for:

Repeated Location: headers bouncing between http:// and https://.
The same URL being returned repeatedly with 3xx status.
Cloudflare error page indicating a redirect loop (e.g., 525/526 in some misconfigurations).

Once you see the pattern, adjust either:

Cloudflare’s HTTPS enforcement settings, or
The origin’s redirect rules / framework config.

Limitations & Considerations

Misaligned SSL mode and origin config:
Flexible + “force HTTPS at origin” is a known anti-pattern. The workaround is to install an origin certificate and move to Full (strict), then simplify origin redirects.
Legacy or opaque application stacks:
In older apps or tightly coupled stacks, you may not easily control redirect logic. In those cases:
- Start by turning off origin-level HTTPS forcing.
- Enforce HTTPS at the edge with Cloudflare.
- Incrementally reintroduce app-level redirects once you can assert they’re scheme-aware (using X-Forwarded-Proto / CF-Visitor).

Pricing & Plans

Cloudflare offers SSL/HTTPS capabilities across all plan levels:

Free and paid plans include Universal SSL, which automatically provisions certificates for your domains so you can start serving HTTPS quickly.
Enterprise plans add:
- Advanced certificate management (custom hostname certificates, dedicated certificates).
- Keyless SSL for strict key custody requirements (e.g., HSM-backed keys kept on-prem).
- 100% uptime SLA and premium support to help debug complex redirect and TLS issues at scale.
Standard / Pro / Business Plans: Best for organizations needing Cloudflare’s WAF, CDN, and SSL with self-service configuration and support tiers.
Enterprise Plan: Best for larger teams needing custom certificate lifecycle control, keyless SSL, advanced security policies, and formal SLAs across global workloads.

Frequently Asked Questions

Why do I get a redirect loop after turning on Cloudflare HTTPS?

Short Answer: Because Cloudflare and your origin are both trying to force HTTPS in conflicting ways, usually with Flexible SSL or scheme-unaware redirects.

Details:
Most redirect loops occur when:

SSL mode is Flexible, so Cloudflare uses HTTP to talk to the origin.
Your origin/server or app also has a “force HTTPS” rule.
The origin sees HTTP from Cloudflare and redirects to HTTPS, which returns to Cloudflare, which again requests HTTP, and so on.

To fix this:

Install an SSL certificate on your origin and move to Full (strict).
Remove or adjust origin-level HTTPS redirects to be aware of X-Forwarded-Proto / CF-Visitor.
Use Cloudflare’s “Always Use HTTPS” or redirect rules to enforce HTTPS centrally.

Can I use Cloudflare SSL if my origin does not have a valid certificate?

Short Answer: Yes, but you should treat it as a temporary state and plan to add an origin certificate.

Details:
Without a valid origin certificate you can:

Use Flexible SSL to quickly present HTTPS to visitors while Cloudflare talks HTTP to the origin.
Or generate a Cloudflare Origin CA certificate and install it on your server, then immediately move to Full (strict) for proper end-to-end encryption.

Staying on Flexible long term is risky:

Higher chance of redirect loops when the origin starts enforcing HTTPS.
Traffic between Cloudflare and your origin remains unencrypted.
Harder to reason about scheme-dependent logic.

The recommended path is:

Quickly enable HTTPS at the edge.
Install an origin certificate.
Switch to Full (strict) and clean up redirects.

Summary

Enabling Cloudflare SSL/HTTPS on an existing site is straightforward: proxy your DNS through Cloudflare, pick the right SSL mode, and let Cloudflare’s connectivity cloud terminate HTTPS at the edge. Redirect loops only happen when Cloudflare’s SSL mode and your origin’s redirect logic disagree about where and how HTTPS should be enforced. By aiming for Full (strict), handling HTTPS redirects at a single layer (ideally the edge), and teaching your origin to trust X-Forwarded-Proto / CF-Visitor, you get fast, secure, and loop-free HTTPS for your users.

Next Step

Get Started