A redirect loop that appears right after putting a WordPress site on aaPanel behind Cloudflare is caused by one specific mismatch: Cloudflare and aaPanel are both trying to enforce HTTPS, using different assumptions about how the connection between them is secured. Fix the mismatch between Cloudflare's SSL/TLS mode and aaPanel's own HTTPS settings, and the loop resolves immediately — no plugin or code fix is needed.
Symptoms
- Browser shows "ERR_TOO_MANY_REDIRECTS" (Chrome) or "The page isn't redirecting properly" (Firefox).
- The site worked fine before Cloudflare was added, or worked fine immediately after adding Cloudflare and then broke once SSL was enabled on one side.
- The loop happens on every page, not just specific ones.
- Visiting the site directly by server IP (bypassing Cloudflare) works fine, which confirms the problem is between Cloudflare and aaPanel, not WordPress itself.
The core rule
Cloudflare sits between your visitor and your aaPanel server. Both Cloudflare and aaPanel/WordPress can independently decide to redirect HTTP to HTTPS. If both of them force that redirect, but the connection between Cloudflare and your server isn't actually using HTTPS the way Cloudflare's mode assumes, each side keeps redirecting to the other's version of "secure," and you get an infinite loop. Only one side should own the HTTP→HTTPS redirect at a time — the fix is making sure they agree on which one.
Fix it in order
Step 1 — Set Cloudflare's SSL/TLS mode to match your aaPanel certificate
In your Cloudflare dashboard, go to SSL/TLS → Overview and check the current mode:
- Flexible tells Cloudflare to connect to your server over plain HTTP, then serve HTTPS to the visitor itself. This mode is the single most common cause of this exact loop, because if aaPanel is also set to force HTTPS (Step 2), your server keeps redirecting Cloudflare's HTTP request back to HTTPS, which Cloudflare then re-wraps and sends again — looping.
- Full connects Cloudflare to your server over HTTPS too, but doesn't validate the certificate is legitimate (a self-signed cert is enough).
- Full (strict) connects over HTTPS and requires a valid, trusted certificate on your server — which is exactly what aaPanel's Let's Encrypt integration provides.
If your aaPanel site has a valid Let's Encrypt certificate installed (confirm under Website → SSL in aaPanel — it should show a green/valid status, not a self-signed placeholder), switch Cloudflare to Full (strict). This is the correct long-term setting for an aaPanel site with a real certificate, and it removes the mismatch that Flexible mode creates.
Step 2 — Let aaPanel handle the HTTP→HTTPS redirect, not both sides at once
In aaPanel, go to Website → your site → SSL, and check whether Force HTTPS (sometimes labeled as a redirect toggle in the same panel) is enabled. With Cloudflare now set to Full (strict) from Step 1, it's safe to leave aaPanel's Force-HTTPS on — the connection between Cloudflare and your server really is HTTPS now, so aaPanel's redirect and Cloudflare's edge behavior agree with each other instead of fighting.
If you'd rather have Cloudflare own the redirect instead (for example, using a Cloudflare Page Rule or its "Always Use HTTPS" toggle under SSL/TLS → Edge Certificates), that also works — just don't force it on both layers using assumptions that contradict each other, which is what caused the loop in the first place.
Step 3 — Purge Cloudflare's cache and test in a clean session
Redirect responses are sometimes cached at Cloudflare's edge. In the Cloudflare dashboard, go to Caching → Configuration → Purge Everything. Then test the site in a private/incognito browser window (a normal browser window may have the old redirect loop cached locally too) by visiting the plain http:// version of the domain and confirming it resolves to https:// cleanly with no loop.
Verify the fix
- Visit
http://yourdomain.comin a private browser window and confirm it redirects once, cleanly, tohttps://yourdomain.comwith a valid padlock. - Check that wp-admin loads normally too — sometimes only the front end is tested, and login loops are a separate symptom of the same mismatch.
- In WordPress, confirm Settings → General has both "WordPress Address" and "Site Address" set to the
https://version of your domain — a mismatch here can reintroduce a similar-looking loop even after Cloudflare/aaPanel are aligned.
If you need to roll back
If switching Cloudflare to Full (strict) causes a different error instead (like "Error 526: Invalid SSL certificate"), your aaPanel-side certificate isn't actually valid yet — go to Website → SSL in aaPanel and re-issue the Let's Encrypt certificate before retrying Full (strict). In the meantime, you can temporarily set Cloudflare back to Full (non-strict) to keep the site reachable while you fix the certificate, then move to Full (strict) once it's confirmed valid. Avoid reverting to Flexible as a long-term fix — it will reintroduce the same loop risk any time aaPanel's Force-HTTPS is also on.
Related fixes
- aaPanel Won't Renew Your Let's Encrypt SSL — For SSL certificate issues on the same aaPanel + Cloudflare setup.
- Cloudflare Killed Page Rules — Why Your Redirects Broke — If your redirect issue isn't aaPanel-specific.
- Fix WordPress 404 Errors After Changing Permalinks — If you're seeing 404s rather than a redirect loop.
FAQ
Which SSL/TLS mode should I use if I don't have a valid certificate installed in aaPanel yet?
Use Full (not strict, not Flexible) as a temporary measure while you get a proper Let's Encrypt certificate issued in aaPanel, since Flexible is what most commonly causes this loop and Full (strict) will hard-fail without a trusted cert. Move to Full (strict) as soon as the aaPanel certificate is confirmed valid.
Does this loop mean my WordPress site is misconfigured?
Not necessarily — WordPress itself is usually a passive victim here. The loop happens between Cloudflare and your server's web layer before WordPress's own redirect logic (like the siteurl/home mismatch mentioned in Verify) even comes into play. Fix the Cloudflare/aaPanel mismatch first; only chase a WordPress-level cause if the loop persists after Steps 1–3.
Can I just disable Cloudflare's proxy (grey-cloud it) instead of fixing the SSL mode?
That will stop the loop, since traffic then goes directly to your server and Cloudflare's edge redirect logic is bypassed entirely — but you also lose Cloudflare's caching, DDoS protection, and CDN benefits, which is presumably why you added it. Treat grey-clouding as a temporary diagnostic step to confirm the cause, not a permanent fix.