Fixing the Cloudflare Flexible SSL Infinite Redirect
Loop in WordPress and NginxSetting up secure socket layer (SSL) encryption is a fundamental requirement for modern web applications. It protects user data, satisfies security compliance standards, and provides a necessary ranking signal for search engine optimization. When deploying websites behind a content delivery network (CDN) like Cloudflare, configuration errors are common, with one of the most persistent and frustrating being the infinite redirect loop.This technical issue usually manifests in the web browser as an ERR_TOO_MANY_REDIRECTS error page. The problem occurs most frequently on platforms running WordPress coupled with Nginx or Apache web servers when using Cloudflare's Flexible SSL setting.This guide provides a detailed explanation of why this infinite loop happens, details the underlying network communication failure, and offers step-by-step solutions to resolve the error permanently.
The Root Cause: Why the Flexible SSL Loop Occurs
To resolve the infinite redirect loop, it is helpful to first understand the flow of traffic between a user, Cloudflare's edge servers, and your origin server.When you configure Cloudflare to use the Flexible SSL mode, the encryption pathway is split into two distinct segments:First, the connection between the user's browser and Cloudflare's edge network is fully encrypted via HTTPS. This ensures that the user sees the padlock icon in their browser address bar.Second, the connection between Cloudflare's edge servers and your origin web server is unencrypted, running over standard HTTP on port 80.The communication breakdown happens at the origin server. When a request arrives from Cloudflare, the origin server (Nginx or Apache) receives it as an unencrypted HTTP request. If your server or your content management system (such as WordPress) is configured to force all visitors to use HTTPS, the server sees the incoming HTTP request and immediately issues an HTTP 301 or 302 redirect pointing to the HTTPS version of the URL.The redirect response is sent back to Cloudflare. Cloudflare passes this redirect instructions to the visitor's browser. The browser follows the redirect and sends a new HTTPS request to Cloudflare. Cloudflare receives this secure request, strips the SSL layer as dictated by the Flexible setting, and sends another HTTP request to the origin server.The origin server once again sees an unencrypted HTTP request, assumes the visitor is accessing the site insecurely, and issues another redirect. This sequence repeats continuously until the browser detects the circular behavior and stops the connection, throwing the too many redirects error.
Solution 1: Upgrading Cloudflare to Full or Full (Strict) SSL
The most secure and robust way to break the redirect loop is to abandon the Flexible SSL configuration entirely and upgrade your setup to Full or Full (Strict) encryption mode. This change forces Cloudflare to communicate with your origin server over an encrypted HTTPS connection on port 443, eliminating the protocol discrepancy that triggers the loop.To achieve this, you must have an SSL certificate installed directly on your origin server. Because Cloudflare sits between your users and your server, you do not need an expensive commercial certificate. You can use a free, self-signed certificate, a Let's Encrypt certificate, or a free Cloudflare Origin CA certificate.Follow these steps to generate and install a Cloudflare Origin CA certificate on an Nginx server:Log in to your Cloudflare dashboard and select your domain. Navigate to SSL/TLS, then select Origin Server and click Create Certificate. Keep the default settings to generate a private key and certificate with a 15-year expiration window. Copy the generated Origin Certificate text and the Private Key text to separate text files on your local machine.SSH into your Linux VPS or dedicated server as root or an administrative user. Create two files in your secure SSL directory:
sudo nano /etc/ssl/certs/cloudflare-origin.pemsudo nano /etc/ssl/private/cloudflare-origin.key
Paste the corresponding certificate and private key text into these files, then save and exit.Next, update your Nginx configuration block to listen on port 443 and refer to these files:
server {listen 80;server_name example.com www.example.com;return 301 https://hostrequest_uri;}server {listen 443 ssl http2;server_name example.com www.example.com;ssl_certificate /etc/ssl/certs/cloudflare-origin.pem;ssl_certificate_key /etc/ssl/private/cloudflare-origin.key;ssl_protocols TLSv1.2 TLSv1.3;ssl_ciphers HIGH:!aNULL:!MD5;root /var/www/html;index index.php index.html;location / {try_files $uri $uri/ /index.php?$args;}location ~ .php$ {include snippets/fastcgi-php.conf;fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;}}
Test the Nginx configuration file for errors using:
sudo nginx -t
If the syntax test passes, reload Nginx to apply the changes:
sudo systemctl reload nginx
Finally, return to your Cloudflare dashboard under SSL/TLS Overview and change your encryption mode from Flexible to Full (Strict). This completes the encrypted loop, keeping your origin server secure and permanently resolving the redirect error.
Solution 2: Configuring WordPress to Detect Reverse Proxies
If your hosting environment prevents you from installing an SSL certificate on the origin server, you must configure WordPress to recognize that the initial user request was indeed secure.When Cloudflare proxies traffic, it appends several custom HTTP headers to the request before forwarding it to your origin server. One of the most important headers is X-Forwarded-Proto, which tells your server whether the original connection was HTTP or HTTPS.To configure WordPress to read this header and prevent it from triggering unnecessary redirects, you must modify your wp-config.php file.Using your server terminal or an SFTP client, open the wp-config.php file located in your WordPress root directory:
sudo nano /var/www/html/wp-config.php
Add the following PHP code block near the top of the file, right before the line that defines your database configuration settings:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {$_SERVER['HTTPS'] = 'on';}
This script checks the incoming headers sent by Cloudflare. If the original connection used HTTPS, WordPress overrides the local PHP server variables and acts as though the local connection itself is secure. This stops the internal WordPress redirection engine from firing, instantly breaking the loop.
Solution 3: Updating Nginx Reverse Proxy Headers
If your application is behind an independent Nginx reverse proxy that routes requests to a backend web app or container, the proxy might be discarding the HTTP headers passed by Cloudflare. To fix this, you must explicitly instruct Nginx to forward the original protocol header.Open your Nginx configuration file and verify that the following proxy-set-header directives are included inside your location block:
location / {proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;proxy_pass http://backend_upstream_group;}
By passing the value of $http_x_forwarded_proto down to the upstream server, your backend application receives the correct context about the original client connection, preventing protocol confusion.
Common Configuration Mistakes to Avoid
When troubleshooting redirect loops, administrators often make several predictable errors that can compound the problem:Enabling Always Use HTTPS and Flexible SSL simultaneously: If you turn on Always Use HTTPS inside the Cloudflare dashboard but your origin server continues to redirect traffic locally because of the Flexible SSL handshake, you create an unresolvable loop.Hardcoding HTTP URLs in the WordPress database: If your WordPress settings (under Settings > General) use the http prefix while your server environment or Cloudflare configuration is forcing https, WordPress will constantly try to redirect back to the insecure URL database values.Forgetting to Clear System and Browser Caches: Modern web browsers cache 301 redirects aggressively. Even after you successfully apply the configuration fixes detailed in this guide, your browser may continue to display the redirect error from its local cache. Always clear your browser cache, perform tests inside a private browsing window, or purge the cache on your Cloudflare dashboard before verifying the success of your fix.
Best Practices for Cloudflare and SSL Integration
To keep your servers secure and highly performant, maintain these administrative guidelines:Consistently enforce Full (Strict) SSL: The Flexible SSL setting is a legacy feature meant for servers that cannot support HTTPS. In the modern web environment, there is rarely a justification for leaving the network segment between Cloudflare and your origin server unencrypted.Migrate from Page Rules to Redirect Rules: Cloudflare is phasing out its legacy Page Rules interface in favor of modular Rules. When implementing global HTTPS redirects at the edge, navigate to Rules > Redirect Rules and create a single rule to handle your protocol normalization instead of utilizing Page Rules.Set Up Health Checks: Utilize Cloudflare's health monitoring tools to alert your operations team if your origin server experiences connectivity failures, ensuring you can intervene before unexpected service disruptions affect your users.
Conclusion
The ERR_TOO_MANY_REDIRECTS error is not a random glitch, but a direct consequence of a communication mismatch between your security layers. By understanding how Cloudflare's Flexible SSL mode passes unencrypted HTTP requests to your origin server, you can pinpoint the exact configuration rules that are conflicting. Transitioning to Full (Strict) SSL mode using free Origin certificates is the best long-term solution. If that is not immediately viable, configuring your Nginx server and WordPress environment to respect the X-Forwarded-Proto header will ensure your site remains online, secure, and accessible to your visitors.
Fixing the Cloudflare Flexible SSL Infinite Redirect
Loop in WordPress and NginxSetting up secure socket layer (SSL) encryption is a fundamental requirement for modern web applications. It protects user data, satisfies security compliance standards, and provides a necessary ranking signal for search engine optimization. When deploying websites behind a content delivery network (CDN) like Cloudflare, configuration errors are common, with one of the most persistent and frustrating being the infinite redirect loop.This technical issue usually manifests in the web browser as an ERR_TOO_MANY_REDIRECTS error page. The problem occurs most frequently on platforms running WordPress coupled with Nginx or Apache web servers when using Cloudflare's Flexible SSL setting.This guide provides a detailed explanation of why this infinite loop happens, details the underlying network communication failure, and offers step-by-step solutions to resolve the error permanently.The Root Cause: Why the Flexible SSL Loop OccursTo resolve the infinite redirect loop, it is helpful to first understand the flow of traffic between a user, Cloudflare's edge servers, and your origin server.When you configure Cloudflare to use the Flexible SSL mode, the encryption pathway is split into two distinct segments:First, the connection between the user's browser and Cloudflare's edge network is fully encrypted via HTTPS. This ensures that the user sees the padlock icon in their browser address bar.Second, the connection between Cloudflare's edge servers and your origin web server is unencrypted, running over standard HTTP on port 80.The communication breakdown happens at the origin server. When a request arrives from Cloudflare, the origin server (Nginx or Apache) receives it as an unencrypted HTTP request. If your server or your content management system (such as WordPress) is configured to force all visitors to use HTTPS, the server sees the incoming HTTP request and immediately issues an HTTP 301 or 302 redirect pointing to the HTTPS version of the URL.The redirect response is sent back to Cloudflare. Cloudflare passes this redirect instructions to the visitor's browser. The browser follows the redirect and sends a new HTTPS request to Cloudflare. Cloudflare receives this secure request, strips the SSL layer as dictated by the Flexible setting, and sends another HTTP request to the origin server.The origin server once again sees an unencrypted HTTP request, assumes the visitor is accessing the site insecurely, and issues another redirect. This sequence repeats continuously until the browser detects the circular behavior and stops the connection, throwing the too many redirects error.Solution 1: Upgrading Cloudflare to Full or Full (Strict) SSLThe most secure and robust way to break the redirect loop is to abandon the Flexible SSL configuration entirely and upgrade your setup to Full or Full (Strict) encryption mode. This change forces Cloudflare to communicate with your origin server over an encrypted HTTPS connection on port 443, eliminating the protocol discrepancy that triggers the loop.To achieve this, you must have an SSL certificate installed directly on your origin server. Because Cloudflare sits between your users and your server, you do not need an expensive commercial certificate. You can use a free, self-signed certificate, a Let's Encrypt certificate, or a free Cloudflare Origin CA certificate.Follow these steps to generate and install a Cloudflare Origin CA certificate on an Nginx server:Log in to your Cloudflare dashboard and select your domain. Navigate to SSL/TLS, then select Origin Server and click Create Certificate. Keep the default settings to generate a private key and certificate with a 15-year expiration window. Copy the generated Origin Certificate text and the Private Key text to separate text files on your local machine.SSH into your Linux VPS or dedicated server as root or an administrative user. Create two files in your secure SSL directory:sudo nano /etc/ssl/certs/cloudflare-origin.pemsudo nano /etc/ssl/private/cloudflare-origin.keyPaste the corresponding certificate and private key text into these files, then save and exit.Next, update your Nginx configuration block to listen on port 443 and refer to these files:server {listen 80;server_name example.com www.example.com;return 301 https://hostrequest_uri;}server {listen 443 ssl http2;server_name example.com www.example.com;ssl_certificate /etc/ssl/certs/cloudflare-origin.pem;ssl_certificate_key /etc/ssl/private/cloudflare-origin.key;ssl_protocols TLSv1.2 TLSv1.3;ssl_ciphers HIGH:!aNULL:!MD5;root /var/www/html;index index.php index.html;location / {try_files $uri $uri/ /index.php?$args;}location ~ .php$ {include snippets/fastcgi-php.conf;fastcgi_pass unix:/var/run/php/php8.1-fpm.sock;}}Test the Nginx configuration file for errors using:sudo nginx -tIf the syntax test passes, reload Nginx to apply the changes:sudo systemctl reload nginxFinally, return to your Cloudflare dashboard under SSL/TLS Overview and change your encryption mode from Flexible to Full (Strict). This completes the encrypted loop, keeping your origin server secure and permanently resolving the redirect error.Solution 2: Configuring WordPress to Detect Reverse ProxiesIf your hosting environment prevents you from installing an SSL certificate on the origin server, you must configure WordPress to recognize that the initial user request was indeed secure.When Cloudflare proxies traffic, it appends several custom HTTP headers to the request before forwarding it to your origin server. One of the most important headers is X-Forwarded-Proto, which tells your server whether the original connection was HTTP or HTTPS.To configure WordPress to read this header and prevent it from triggering unnecessary redirects, you must modify your wp-config.php file.Using your server terminal or an SFTP client, open the wp-config.php file located in your WordPress root directory:sudo nano /var/www/html/wp-config.phpAdd the following PHP code block near the top of the file, right before the line that defines your database configuration settings:if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {$_SERVER['HTTPS'] = 'on';}This script checks the incoming headers sent by Cloudflare. If the original connection used HTTPS, WordPress overrides the local PHP server variables and acts as though the local connection itself is secure. This stops the internal WordPress redirection engine from firing, instantly breaking the loop.Solution 3: Updating Nginx Reverse Proxy HeadersIf your application is behind an independent Nginx reverse proxy that routes requests to a backend web app or container, the proxy might be discarding the HTTP headers passed by Cloudflare. To fix this, you must explicitly instruct Nginx to forward the original protocol header.Open your Nginx configuration file and verify that the following proxy-set-header directives are included inside your location block:location / {proxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;proxy_pass http://backend_upstream_group;}By passing the value of $http_x_forwarded_proto down to the upstream server, your backend application receives the correct context about the original client connection, preventing protocol confusion.Common Configuration Mistakes to AvoidWhen troubleshooting redirect loops, administrators often make several predictable errors that can compound the problem:Enabling Always Use HTTPS and Flexible SSL simultaneously: If you turn on Always Use HTTPS inside the Cloudflare dashboard but your origin server continues to redirect traffic locally because of the Flexible SSL handshake, you create an unresolvable loop.Hardcoding HTTP URLs in the WordPress database: If your WordPress settings (under Settings > General) use the http prefix while your server environment or Cloudflare configuration is forcing https, WordPress will constantly try to redirect back to the insecure URL database values.Forgetting to Clear System and Browser Caches: Modern web browsers cache 301 redirects aggressively. Even after you successfully apply the configuration fixes detailed in this guide, your browser may continue to display the redirect error from its local cache. Always clear your browser cache, perform tests inside a private browsing window, or purge the cache on your Cloudflare dashboard before verifying the success of your fix.Best Practices for Cloudflare and SSL IntegrationTo keep your servers secure and highly performant, maintain these administrative guidelines:Consistently enforce Full (Strict) SSL: The Flexible SSL setting is a legacy feature meant for servers that cannot support HTTPS. In the modern web environment, there is rarely a justification for leaving the network segment between Cloudflare and your origin server unencrypted.Migrate from Page Rules to Redirect Rules: Cloudflare is phasing out its legacy Page Rules interface in favor of modular Rules. When implementing global HTTPS redirects at the edge, navigate to Rules > Redirect Rules and create a single rule to handle your protocol normalization instead of utilizing Page Rules.Set Up Health Checks: Utilize Cloudflare's health monitoring tools to alert your operations team if your origin server experiences connectivity failures, ensuring you can intervene before unexpected service disruptions affect your users.ConclusionThe ERR_TOO_MANY_REDIRECTS error is not a random glitch, but a direct consequence of a communication mismatch between your security layers. By understanding how Cloudflare's Flexible SSL mode passes unencrypted HTTP requests to your origin server, you can pinpoint the exact configuration rules that are conflicting. Transitioning to Full (Strict) SSL mode using free Origin certificates is the best long-term solution. If that is not immediately viable, configuring your Nginx server and WordPress environment to respect the X-Forwarded-Proto header will ensure your site remains online, secure, and accessible to your visitors.
English
Arabic
French
Spanish
Portuguese
Deutsch
Turkish
Dutch
Italiano
Russian
Romaian
Portuguese (Brazil)
Greek
