Quick answer
An HTTPS loop can occur when the application, web server, and proxy disagree about the original request scheme or preferred hostname. Identify the repeating redirect before changing unrelated DNS or disabling security.
Before you start
Record the affected URL, expected canonical hostname, certificate status, proxy configuration, and recent redirect changes. Preserve application and server rules and test a repair on staging where possible.
Steps
- Inspect the actual redirect destinations and status codes with a browser or trusted diagnostic tool. Determine whether the loop switches between HTTP/HTTPS, www/non-www, or two different application URLs.
- Check that the origin supports the intended HTTPS connection and that proxy encryption settings align with it. Avoid adding another force-HTTPS rule before understanding the existing ones.
- Review CMS site URLs and supported proxy-awareness settings, plus relevant server redirects. Change the confirmed source of the loop with a clear rollback.
- Test a fresh browser session, the canonical URL, common alternate hostname, and a deep page. Confirm the final page uses a valid certificate and does not require bypassing a warning.
Verify the result
Each supported alternate should reach the intended HTTPS address without cycling, while assets and login sessions continue to function. Record the final redirect chain.
Troubleshooting and recovery
If the loop persists, provide support with the sanitized redirect chain, hostname, time, and recent change. Do not turn off HTTPS or certificate validation merely to make the browser stop redirecting.
Related help
- Check and troubleshoot HTTPS certificates for your domain
- Find where your domain's DNS is managed before changing records
- Investigate a legitimate request blocked by Cloudflare
Official references
Reviewed October 31, 2026. Interfaces, vendor availability, and account features can change. Check your current account before making changes.
