SSL and HTTPS configuration errors are among the most common causes of redirect loops. When you enable HTTPS on your site, multiple systems (your web server, CDN, WordPress, and plugins) may try to enforce HTTPS at the same time. If these systems don’t align perfectly, they create conflicting redirect instructions that trap visitors in endless loops.

To fix an HTTPS redirect loop, you need to identify which layer is issuing each redirect and determine whether the CDN, web server, reverse proxy, or application disagrees about the original request protocol. The sections below walk through the most common SSL-related conflicts and how to isolate them.

Understanding SSL/HTTPS Redirect Layers

HTTPS redirects can happen at multiple levels in your hosting stack. Understanding where each redirect occurs helps you identify and fix conflicts.

• CDN level (like Cloudflare, Stackpath, or Sucuri) intercepts requests before they reach your server and can force HTTPS redirects at the edge.
• Web server level (.htaccess for Apache, nginx.conf for Nginx, web.config for IIS) implements redirects through server configuration files.
• Application level (WordPress core, plugins, or theme functions) handles redirects through PHP code.
• Load balancer/proxy level (in advanced hosting setups) can terminate SSL and create redirects between the proxy and your application server.

Redirect loops occur when these layers conflict. One redirects HTTP to HTTPS while another redirects HTTPS back to HTTP, or when SSL settings at different layers don’t communicate properly about the connection state.

Pro Tip: The safest approach is to avoid conflicting HTTPS enforcement rules. Using one clearly defined redirect layer is often simpler to maintain, but multiple layers can coexist when they consistently preserve HTTPS and the preferred hostname.

Cloudflare SSL Mode Misconfigurations

Cloudflare is a widely used CDN, and its SSL/TLS mode can produce redirect loops when it conflicts with origin-side HTTPS enforcement. Understanding how Cloudflare communicates with your origin server can help you identify and prevent these conflicts.

Cloudflare SSL Modes Explained

Cloudflare provides several SSL/TLS encryption modes. The three most relevant to typical redirect-loop troubleshooting are Flexible, Full, and Full (Strict). These modes determine how Cloudflare communicates with your origin server and whether the origin certificate is validated.

• Off disables SSL entirely. Your site is only accessible via HTTP. This is rarely used and not recommended.
• Flexible encrypts traffic between visitors and Cloudflare, but Cloudflare connects to your origin server via HTTP (unencrypted). Use this only if you cannot install an SSL certificate on your server.
• Full allows HTTPS between visitors and Cloudflare and uses HTTPS to the origin when the visitor request is HTTPS. Cloudflare does not validate the origin certificate in this mode, so self-signed, expired, or otherwise invalid origin certificates can still be accepted. Use Full when the origin supports HTTPS but cannot present a valid trusted certificate.
• Full (Strict) establishes an HTTPS connection to your origin and validates its SSL certificate. The certificate must be unexpired, match the requested hostname, and be issued by a publicly trusted certificate authority or Cloudflare Origin CA. Use Full (Strict) whenever your origin has a valid certificate. It is the preferred option for production sites.

Flexible SSL Redirect Loops

The most common Cloudflare redirect loop occurs with Flexible SSL mode when your server or WordPress forces HTTPS.

Here’s what happens: A visitor requests http://yoursite.com. Cloudflare’s “Always Use HTTPS” feature redirects them to https://yoursite.com. Cloudflare connects to your origin server via HTTP (because you’re using Flexible SSL). Your server or WordPress detects the HTTP connection and redirects to HTTPS. Cloudflare receives this redirect and converts it back to HTTP when connecting to your server. The server redirects to HTTPS again, creating an infinite loop.

The fix: If AutoSSL has installed a valid certificate for the hostname, change Cloudflare’s encryption mode from Flexible to Full (Strict). This allows Cloudflare to connect securely to the origin and validate the installed certificate. If the origin certificate cannot currently be validated, Full can be used temporarily while the certificate issue is corrected.

After installing the certificate on your server, go to Cloudflare dashboard > SSL/TLS and change the mode to Full (Strict). The redirect loop should resolve immediately.

Always Use HTTPS Conflicts

Cloudflare’s “Always Use HTTPS” feature (found in SSL/TLS > Edge Certificates) redirects all HTTP requests to HTTPS at the edge.

This creates loops when combined with Flexible SSL mode (as described above) or when your server has incorrect HTTPS redirect rules that send HTTPS traffic back to HTTP.

If you experience redirect loops with “Always Use HTTPS” enabled, first verify your SSL mode is Full or Full (Strict), then check your server configuration (.htaccess or nginx.conf) for redirect rules that might conflict with Cloudflare’s edge redirects.

Pro Tip: If using Cloudflare’s “Always Use HTTPS,” disable HTTPS forcing in your server configuration and WordPress. Let Cloudflare handle all HTTP-to-HTTPS redirects at the edge for better performance and fewer conflict opportunities.

Server SSL Certificate Issues

Problems with SSL certificates installed on your origin server can cause redirect loops, even when the installation appears successful.

Missing or Inactive SSL Certificates

If your CDN or server configuration forces HTTPS but no SSL certificate is installed or activated, redirect loops can occur.

If HTTPS is enforced but the origin server cannot establish a valid TLS connection, visitors will normally encounter an SSL/TLS connection error rather than a redirect loop. Redirect loops occur when another layer, such as a CDN, reverse proxy, server rule, or application, changes the protocol and triggers a conflicting redirect.

The fix: Verify that your SSL certificate is properly installed and active. In cPanel, check SSL/TLS status to see if your domain has an active certificate. For other control panels, look for SSL certificate management sections.

If no certificate is installed, get one from Let’s Encrypt (free) through your hosting control panel, buy one from a certificate authority, or use your CDN’s origin certificate (for example, Cloudflare).

After installing or renewing the certificate, confirm that the web server or hosting platform is serving the new certificate. Managed control panels typically apply certificate changes automatically, while manually managed servers may require the relevant service to reload its configuration.

Expired SSL Certificates

An expired SSL certificate usually causes a certificate validation or TLS connection error rather than a redirect loop. However, certificate problems can appear alongside redirect issues when a CDN, proxy, or server is also changing the request protocol.

For example, when Cloudflare is configured to use Full (Strict), an expired or otherwise invalid origin certificate can cause a Cloudflare 526 error because the certificate no longer meets the validation requirements. This should be diagnosed separately from an HTTP redirect loop.

Check your certificate expiration date in your hosting control panel or by visiting your site in a browser and clicking the padlock icon in the address bar. If expired, renew the certificate immediately.

Most modern SSL providers (including Let’s Encrypt) offer automatic renewal. Enable auto-renewal to prevent future expiration issues.

SSL Certificate Not Covering All Domains

If your SSL certificate covers www.example.com but not example.com, or vice versa, visitors may encounter a certificate warning when redirected between the two hostnames. This is a certificate coverage problem rather than a redirect loop unless conflicting redirect rules are also present.

Check your certificate’s Subject Alternative Names (SANs) to see which domains it covers. Most modern certificates cover both www and non-www versions, but older or improperly configured certificates might not.

The fix: Obtain a new certificate that covers all domain variations you use. Let’s Encrypt certificates automatically cover both www and non-www versions when properly requested.

Mixed HTTPS Enforcement Conflicts

The most common cause of SSL-related redirect loops is enforcing HTTPS at multiple levels with conflicting configurations.

Multiple HTTPS Enforcement Points

Check if HTTPS is being forced at multiple levels:

• CDN: Cloudflare “Always Use HTTPS,” Sucuri “Force SSL,” or similar features
• Server: .htaccess redirect rules, nginx HTTPS redirect blocks, or IIS URL rewrite rules
• WordPress: Really Simple SSL plugin, SSL Insecure Content Fixer, or similar plugins
• Theme/Functions: Custom HTTPS redirect code in functions.php or theme files

Having HTTPS enforcement at multiple levels doesn’t always cause loops, but conflicts arise when these enforcement methods don’t communicate properly or use different redirect logic.

The fix: First identify every layer that is enforcing HTTPS and make sure their rules agree. For simpler setups, using one primary enforcement point reduces the chance of conflicting redirects. Recommended hierarchy:

1. CDN level (if using a CDN). Handles redirects before traffic reaches your server
2. Server level (if no CDN). Efficient and reliable
3. WordPress plugins (last resort). Less efficient but easier for non-technical users

If more than one layer remains enabled, verify that every rule redirects toward the same HTTPS hostname and that no layer sends HTTPS traffic back to HTTP.

Server Configuration Forcing HTTP

Less common but particularly frustrating are scenarios where server configuration redirects HTTPS traffic back to HTTP, while something else forces HTTP to HTTPS.

This happens with legacy server configurations, incorrectly configured reverse proxy setups, or old .htaccess rules that were appropriate before SSL but now conflict with HTTPS enforcement.

Check your .htaccess file (Apache) or nginx.conf (Nginx) for redirect rules. Look for rules that redirect HTTPS to HTTP or that redirect to HTTP URLs explicitly.

Common problematic .htaccess patterns:

RewriteRule ^(.*)$ http://yoursite.com/$1 [R=301,L]

This rule redirects everything to HTTP. If you have HTTPS enforcement elsewhere, it creates a loop.

The fix: Update redirect rules to use HTTPS or use relative URLs that preserve the protocol. Correct version:

RewriteRule ^(.*)$ https://yoursite.com/$1 [R=301,L]

WordPress HTTPS Configuration Issues

WordPress-specific HTTPS settings can conflict with server or CDN SSL configurations.

WordPress Site URL Protocol Mismatch

If your WordPress Site URL uses HTTP (http://yoursite.com) but your server or CDN forces HTTPS, redirect loops occur because WordPress redirects HTTPS requests back to HTTP while external systems redirect HTTP to HTTPS.

The fix: Update WordPress URLs to use HTTPS. Go to Settings > General and change both WordPress Address (URL) and Site Address (URL) from http:// to https://.

If locked out due to the redirect loop, update these via wp-config.php:

define(‘WP_HOME’,’https://yoursite.com’);

define(‘WP_SITEURL’,’https://yoursite.com’);

Or update directly in the database via phpMyAdmin by changing the siteurl and home values in the wp_options table to use https://.

SSL Plugin Conflicts

WordPress SSL plugins like Really Simple SSL, SSL Insecure Content Fixer, or Easy HTTPS Redirection can create loops when combined with server or CDN HTTPS enforcement.

These plugins add their own HTTPS redirect logic that might conflict with your server’s .htaccess rules or CDN settings.

The fix: If you’ve already configured HTTPS at the server or CDN level, you don’t need an SSL plugin for redirects. Deactivate the SSL plugin and test your site.

If the redirect loop resolves, the plugin was conflicting with your existing HTTPS configuration. You can either keep the plugin deactivated or reconfigure your setup to use ONLY the plugin for HTTPS enforcement (disabling server and CDN HTTPS forcing).

Reverse Proxy and Load Balancer SSL Issues

Advanced hosting setups with reverse proxies or load balancers introduce additional SSL complexity that commonly causes redirect loops.

SSL Termination Without Proper Headers

When SSL terminates at a load balancer or reverse proxy, the connection between the proxy and your application server uses HTTP, not HTTPS.

If your application server (or WordPress) checks the direct connection protocol, it sees HTTP and tries to redirect to HTTPS. The load balancer receives this HTTPS redirect, which comes back to the application server as HTTP, triggering another redirect and creating a loop.

The fix: Configure your load balancer or reverse proxy to send protocol-aware forwarding information, such as X-Forwarded-Proto or a platform-specific equivalent, to the application server so it can determine whether the original visitor request used HTTPS.

Then configure your application (WordPress or server config) to respect these headers when determining whether to redirect.

For WordPress behind a reverse proxy, add this to wp-config.php:

if (isset($_SERVER[‘HTTP_X_FORWARDED_PROTO’]) && $_SERVER[‘HTTP_X_FORWARDED_PROTO’] === ‘https’) {

    $_SERVER[‘HTTPS’] = ‘on’;

}

This allows WordPress to recognize that the original visitor request used HTTPS even when the connection between the trusted proxy and WordPress uses HTTP, preventing WordPress from issuing an unnecessary HTTPS redirect.

Important: Only trust forwarded protocol headers when requests are coming through a reverse proxy or load balancer you control or explicitly trust.

Cloudflare with cPanel AutoSSL

One common conflict occurs when a site uses Cloudflare Flexible SSL while cPanel AutoSSL has already installed a certificate on the origin server.

With Flexible mode, Cloudflare connects to the origin over HTTP even though AutoSSL has installed an HTTPS certificate. If the origin then redirects that HTTP request to HTTPS, Cloudflare can send the next origin request over HTTP again, causing the same redirect to repeat.

The fix: Change Cloudflare’s SSL mode from Flexible to Full or Full (Strict) to use the AutoSSL certificate installed on your server. This allows Cloudflare to connect to your origin via HTTPS, eliminating the conflict.

For reliable hosting infrastructure with properly configured SSL termination, load balancing, and proxy settings, quality managed hosting ensures these advanced configurations work correctly from the start, reducing the risk of SSL redirect loops.

Testing and Verifying Your SSL Configuration

After fixing SSL misconfigurations, verify that everything works correctly.

Use SSL Checker Tools

Online SSL testing tools like SSL Labs’ SSL Server Test (ssllabs.com/ssltest) analyze your SSL configuration and identify issues like expired certificates, missing intermediate certificates, or weak SSL protocols.

Run your domain through SSL Labs and address any warnings or errors that appear. A grade of A or A+ indicates proper SSL configuration.

Test All URL Variations

Test your site with all URL variations to ensure redirects work correctly:

• http://example.com
• https://example.com
• http://www.example.com
• https://www.example.com

All variations should successfully redirect to your preferred URL (typically https://www.example.com or https://example.com) without errors or loops.

Check Redirect Chains

Use redirect checker tools (like redirectchecker.org or httpstatus.io) to visualize your redirect chain. A healthy configuration shows a single redirect from HTTP to HTTPS (or from non-www to www), not multiple redirects or circular patterns.

Preventing Future SSL Redirect Loops

Once resolved, maintain proper SSL configuration to prevent recurrence.

Document which level handles HTTPS enforcement (CDN, server, or WordPress) so future changes don’t introduce conflicts. Set up monitoring for SSL certificate expirations to renew certificates before they expire. Test all SSL-related changes in a staging environment before deploying to production.

When making infrastructure changes (switching CDNs, changing hosting, or modifying server configs), review your entire SSL configuration to ensure all layers remain properly aligned.

Fix SSL Redirect Loops by Aligning HTTPS Configuration

HTTPS redirect loops usually stem from conflicting protocol or hostname decisions across infrastructure layers. Start by identifying where redirects occur, including your CDN, web server, reverse proxy, WordPress configuration, and plugins. A common example is Cloudflare Flexible SSL combined with origin-side HTTPS enforcement, which can cause Cloudflare and the origin server to repeatedly disagree about the request protocol.

Fix redirect loops by identifying every HTTPS enforcement point and removing conflicting rules. Using one primary redirect layer is often easiest to maintain, but multiple layers can work when they consistently redirect toward the same HTTPS hostname. Verify that your SSL certificate is properly installed, ensure WordPress URLs use HTTPS, and confirm that your CDN encryption mode matches the origin’s certificate configuration. In reverse-proxy setups, make sure the application receives trusted information about the visitor’s original protocol.

Test thoroughly after making changes by checking all URL variations and reviewing redirect chains with online tools. Proper SSL configuration not only prevents redirect loops but also ensures secure, performant HTTPS connections for all your visitors.

Frequently Asked Questions