Quick answer: Open DevTools → Network tab, check "Preserve log," reload, and look at the first 301/302 in the chain — that tells you whether it's a cookie problem (client-side) or a server rule sending you in circles.
What's actually happening here is that your browser and the server are stuck in a polite argument. The server says "go here," the browser goes, the server says "actually, go here," and around you both go until Chrome, Firefox, or Edge hits its 20-redirect limit and throws ERR_TOO_MANY_REDIRECTS. The real reason this happens is almost never the browser itself. It's either a stale cookie overriding a fresh one, an HTTP-to-HTTPS rule fighting with a Cloudflare page rule, or a WordPress plugin (usually Really Simple SSL or a caching plugin) rewriting URLs that another layer already rewrote.
I hit this most often on sites that just moved behind Cloudflare with "Flexible" SSL mode while the origin already had a forced HTTPS redirect. Cloudflare connects over port 80, origin 301s to HTTPS, Cloudflare sees an HTTP request again, loops. That one configuration mistake generates a support ticket a week on some hosts.
Step 1: Confirm it's actually a loop (not a bad URL)
In Chrome or Edge, hit F12 → Network tab → tick Preserve log. Reload the page. You'll see a wall of requests. Click the first one, then the second. If the Status Code column reads 301 or 302 across the board and the Location header keeps flipping between two URLs, you've got a loop. If it's a 200 followed by a 4xx, your problem is something else entirely — probably a bad link or DNS.
Step 2: Test in Incognito first
Open an incognito or private window and load the same URL. No extensions, no cookies. If the page loads fine there, the loop is client-side — a cookie, an extension, or cached HSTS. If it still loops in incognito, the problem is on the server, and you should skip straight to Step 5.
Step 3: Clear cookies for just that domain
Don't nuke your whole cookie jar. In Chrome: click the padlock icon in the address bar → Cookies and site data → Manage cookies and site data → delete entries for the domain and any www subdomain separately. Firefox: right-click the page → View Page Info → Security → View Cookies → remove all. The reason this works is that a redirect plugin will often set a cookie like wp_redirect_https=0, and if that cookie persists after you enable HTTPS, the plugin keeps bouncing you.
Step 4: Check for HSTS pinning
If you ever visited the site with HSTS enabled, Chrome remembers. Go to chrome://net-internals/#hsts, type the domain in Delete domain security policies, and hit delete. Firefox has a similar list under about:preferences#privacy → Cookies and Site Data → Manage Exceptions. This bites people who flip HTTPS on and off during development.
Step 5: If the loop persists in incognito — it's the server
Now you're debugging config, not the browser. The order I check:
- Cloudflare SSL mode. Go to SSL/TLS → Overview. If it says Flexible and your origin forces HTTPS, switch to Full (strict). This is the single most common cause of looping on Cloudflare-fronted sites.
- .htaccess or nginx config. Look for two redirect rules that both fire — one for HTTPS, one for adding/removing
www. Combine them into a single 301 with the final destination. - WordPress plugins. Deactivate Really Simple SSL, then whatever caching plugin you're using (WP Rocket, LiteSpeed Cache, W3 Total Cache). Reactivate one at a time. Nine times out of ten the loop reappears the moment the second one comes back.
- Load balancer headers. If you're behind an AWS ALB or nginx reverse proxy, the app might see
X-Forwarded-Proto: httpeven though the client is on HTTPS, and force another redirect. SetX-Forwarded-Proto httpsat the proxy.
Alternative fixes if the loop survives all that
- Try a different network. Corporate proxies and some ISP-level filters rewrite HTTP to HTTPS without telling you. Tether to your phone and retest.
- Disable extensions one by one. HTTPS Everywhere (now built into most browsers), Privacy Badger, and some ad blockers can inject redirects. Chrome's
chrome://extensions→ toggle off, retest. - Flush DNS.
ipconfig /flushdnson Windows,sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderon macOS. Rare, but if you recently changed A records, a stale resolver can send you to an old server that still has the loop rule.
Prevention: don't stack redirect rules
The root cause is almost always two systems trying to do the same job. Pick one place to enforce HTTPS and one place to enforce www (or non-www) — ideally in your origin's server config, and let Cloudflare or your CDN pass through. Audit .htaccess and your CDN page rules after any migration. And when you flip HTTPS on for the first time, invalidate the CDN cache and clear the site's own cookies, because your users' browsers are still holding the old ones.
One redirect is a fix. Three redirects is a bug waiting for a support ticket.