A redirect loop after enabling HTTPS (the browser reports "too many redirects" or similar) has a small number of common root causes, and identifying which one applies is usually quick once you know what to check.
1. Application and server both redirecting
If your CMS or framework has its own "force HTTPS" setting enabled at the same time as a server-level (.htaccess/Nginx) redirect, and one of them can't correctly detect the connection is already secure, they can end up redirecting each other indefinitely. Pick one layer to own the redirect — usually the server level — and disable the application-level one, or vice versa.
2. A proxy or CDN not signaling HTTPS correctly
If you're behind Cloudflare, a load balancer, or any reverse proxy, and it's forwarding plain HTTP to your origin (common with Cloudflare's "Flexible" SSL mode) while your origin also tries to force HTTPS, you get the same loop — the origin sees HTTP, redirects, the proxy redirects back. Fix the proxy's SSL mode, or make your origin check the X-Forwarded-Proto header instead of a raw HTTPS check.
3. Browser cache of a bad old redirect
Browsers aggressively cache 301 redirects. If you fixed a loop but it's still happening in your regular browser, test in a private/incognito window first — you may have already fixed the actual problem, and just be looking at a cached bad response.
Why testing in a private browser window rules out half of false positives
Browsers cache redirect responses aggressively, meaning a genuinely fixed loop can still appear broken in your regular browser simply because of a cached prior redirect — testing in a private or incognito window, which has no such cache, is the fastest way to confirm whether a fix actually worked or whether you're just looking at stale cached behavior.
What order to check causes in when multiple layers could be responsible
Start from the outside in: check any CDN or proxy's SSL mode setting first, then check your application's own redirect logic and whether it correctly reads the forwarded-protocol header, and only then investigate more exotic causes — this order resolves the large majority of redirect loops, since CDN/proxy misconfiguration and forwarded-header handling account for most real-world cases.
Why a loop that only affects some visitors points toward a caching or CDN cause
A redirect loop reported by only some visitors, rather than universally, often points toward a CDN or caching layer serving inconsistent behavior to different visitors based on their specific edge location or cache state, rather than a uniform server-side misconfiguration that would affect everyone equally.
What browser extensions can sometimes contribute to an apparent redirect loop
Certain browser extensions, particularly ones that rewrite requests or enforce their own HTTPS-related behavior (HTTPS Everywhere-style extensions, some ad blockers), can occasionally interact unexpectedly with a site's own redirect logic — testing with extensions disabled rules out this specific, less commonly considered variable.
How to use curl's verbose output to trace exactly where a loop originates
Running curl with the -v flag and following each redirect manually, rather than letting curl auto-follow with -L, shows you the exact sequence of Location headers being returned at each hop — invaluable for pinpointing exactly which layer is issuing the redirect that creates the loop.
Why clearing HSTS settings in your own browser can help isolate a testing issue
If you've previously visited a domain with a problematic HSTS configuration, your own browser may have cached that policy — clearing HSTS settings for the specific domain in your browser's security settings (or simply testing in a fresh browser profile) rules out your own cached state as the cause of a persistent-seeming loop.
A final systematic approach worth keeping as a reference
Working through causes in order, application-versus-server redirect conflicts, then proxy/CDN configuration, then browser caching, resolves the large majority of redirect loops without needing to guess — worth keeping this general troubleshooting sequence as a standing reference for any future redirect issue.
What a browser's own developer tools network tab reveals beyond just the console
The Network tab shows the actual sequence of requests and redirect responses for a page load, including status codes and response headers for each hop — complementary to the Console tab's error messages, and often the more direct place to trace exactly where an unexpected redirect is originating.
How to explain this issue clearly when asking for help in a support forum or ticket
Including the exact curl output showing the redirect chain, your current server configuration relevant to the redirect, and a clear description of expected versus actual behavior gives anyone helping you the specific information needed to diagnose the issue quickly, rather than requiring back-and-forth to gather basic details.