WPFIX STACK — home
Hosting & aaPanel

WordPress Redirect Loop After Adding Cloudflare on aaPanel? Fix It in 3 Steps

WordPress stuck in a redirect loop after putting Cloudflare in front of aaPanel? It's almost always mismatched SSL modes — here's the exact 3-step fix.

By Published Updated 5 min read

Close-up of a modern server unit in a blue-lit data center environment.
Photo by panumas nikhomkhai on Pexels

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.

Likely causes, in order of how often they actually happen

  1. Cloudflare's SSL/TLS mode is set to Flexible while aaPanel also forces HTTPS. Cloudflare sits between your visitor and your aaPanel server, and both sides can independently decide to redirect HTTP to HTTPS. If Flexible mode has Cloudflare talking to your server over plain HTTP, but aaPanel keeps redirecting that request back to HTTPS, each side keeps redirecting to the other's version of "secure" — an infinite loop. This is by far the most common cause.
  2. Cloudflare's SSL/TLS mode doesn't match the certificate aaPanel actually has installed. This one usually shows up as a numbered Cloudflare error rather than a loop: Full (strict) pointed at a self-signed or expired certificate fails with error 526 (opens in a new tab). Step 1 fixes it too.

Only one side should own the HTTP→HTTPS redirect at a time — the fix is making sure Cloudflare and aaPanel agree on which one.

Fix it: lowest-risk steps first

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 — Cloudflare's own redirect-loop guide (opens in a new tab) points to the same fix.

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 (its Always Use HTTPS toggle under SSL/TLS → Edge Certificates, or a Redirect Rule — Page Rules are deprecated (opens in a new tab)), 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

Redirects can be cached — a 301 by your browser, and by Cloudflare too if the URL is cacheable. In the Cloudflare dashboard, go to Caching → Configuration → Purge Everything. Then test the site in a private/incognito window by visiting the plain http:// version of the domain and confirming it resolves to https:// cleanly with no loop.

Verify the fix

  1. Visit http://yourdomain.com in a private browser window and confirm it redirects once, cleanly, to https://yourdomain.com with a valid padlock.
  2. 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.
  3. 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.

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: Full encrypts the connection to your server without validating the certificate (opens in a new tab), while Flexible is what most commonly causes this loop and Full (strict) will 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.

Stefan Nistor

Founder, WP Fix Stack

Stefan runs WP Fix Stack. Every guide checks its commands, menu paths and limits against the official documentation of WordPress, PHP, the hosting panel, Cloudflare or the plugin involved, and links those sources so you can verify them. Fixes are ordered from the least risky step, each guide ends with a way to confirm the fix and roll it back, and guides are corrected, with a new Updated date, when the documentation or the software changes.

Every guide explains the symptom, likely causes, the safest order of checks and how to confirm the fix. How we check our guides.

On this page