Joomla has a built-in "Force HTTPS" option under System → Global Configuration → Server. Once your certificate is installed, set it to "Entire Site" — but this is also where most redirect loops start.
Why the redirect loop happens
If your host sits behind a load balancer, proxy, or Cloudflare, Joomla may not correctly detect that the incoming request is already HTTPS. It sees what looks like an HTTP request, redirects to HTTPS, and the proxy hands it back the same way — looping forever.
The fix
- Add to configuration.php:
$live_site = 'https://yourdomain.com';if it isn't already set correctly. - If you're behind Cloudflare, set SSL/TLS mode to "Full" or "Full (Strict)", not "Flexible".
- Add proxy-awareness to .htaccess:
RewriteCond %{HTTP:X-Forwarded-Proto} !httpsbefore your redirect rule.
Test in a private browser window after each change — cached redirect loops will persist in your regular browser even after the fix is live.
Why Joomla's setting alone isn't always enough
Joomla's "Force HTTPS" option controls how Joomla itself generates internal links and handles redirects within its own application logic — it doesn't control what happens at the web server level before Joomla ever runs. If a visitor's very first request arrives over plain HTTP, Joomla's setting only takes effect once Joomla starts processing that request; the actual redirect response still needs to come from somewhere. On most standard Apache hosting this works because Joomla's own .htaccess-based logic handles it, but on Nginx, or behind a CDN, you may still need an explicit server-level redirect alongside the Joomla setting, not instead of it.
The specific case of Cloudflare's "Flexible" SSL mode
If you're using Cloudflare in front of Joomla, its SSL mode setting matters more than almost anything else here. "Flexible" mode means Cloudflare accepts HTTPS from visitors but connects to your actual origin server over plain HTTP — which means Joomla, checking for an HTTPS connection, never sees one, and can end up redirecting a request that's already secure back to HTTP, which Cloudflare then upgrades again, creating an infinite loop. Switching Cloudflare to "Full" or "Full (strict)" mode, so the Cloudflare-to-origin hop is also encrypted, resolves this specific and very common cause.
Checking which layer is in practice causing a persistent loop
Running curl -IL http://yourdomain.com from the command line shows you the exact chain of redirects a request follows, independent of any browser caching — actually useful for confirming whether the loop is happening at Cloudflare, at your web server, or inside Joomla itself, rather than guessing based on what a browser displays.
Loading comments…