How to Fix Cloudflare WordPress Redirect Loop
A Cloudflare WordPress redirect loop can lock visitors out of your site, break login pages, and trigger endless browser errors.
The fix usually comes down to one of a few settings conflicts, but the exact cause is not always obvious.
This guide explains the most common reasons the loop happens and shows you how to correct Cloudflare, WordPress, and server settings without creating new problems.
What a redirect loop means
A redirect loop happens when one URL keeps sending the browser to another URL that sends it back again.
In a Cloudflare and WordPress setup, this usually involves a mismatch between HTTP and HTTPS, or between the origin server and Cloudflare edge settings.
Typical signs include:
- The browser shows “too many redirects” or “redirected you too many times.”
- WordPress admin login keeps reloading.
- Pages open on one device but not another.
- Changing the site URL or SSL settings appears to make the problem worse.
Why Cloudflare WordPress redirect loops happen
The most common causes are configuration conflicts between Cloudflare, WordPress, and your web server.
Because Cloudflare sits between visitors and your host, it can make HTTPS appear differently depending on how SSL/TLS is configured.
Common causes
- Flexible SSL with WordPress forcing HTTPS: Cloudflare connects to your server over HTTP while WordPress or a plugin redirects to HTTPS.
- Incorrect WordPress Address or Site Address: One URL uses HTTP and the other uses HTTPS.
- Misconfigured page rules or redirect rules in Cloudflare: Multiple rules can send requests in a circle.
- SSL mode mismatch: Cloudflare SSL/TLS mode does not match the certificate on the origin server.
- Plugin or .htaccess redirects: Security, caching, or redirect plugins can add another layer of forced redirects.
Check Cloudflare SSL/TLS mode first
Start with the SSL/TLS setting in Cloudflare because it is one of the most common sources of the problem.
In the Cloudflare dashboard, go to SSL/TLS and check which mode is active.
Use Full or Full (Strict) when possible
If your origin server has a valid SSL certificate, set Cloudflare to Full (Strict).
If the certificate is valid but not publicly trusted in every case, Full may still work.
These modes reduce the chance of HTTP and HTTPS conflicts.
Avoid Flexible SSL for WordPress sites
Flexible often causes redirect loops because Cloudflare uses HTTPS between the visitor and Cloudflare, but HTTP between Cloudflare and your server.
If WordPress forces HTTPS on the origin, the requests can bounce endlessly.
If your site is currently on Flexible, change it to Full or Full (Strict) only after confirming your server supports HTTPS.
Verify the WordPress URL settings
Open your WordPress admin area if possible and go to Settings > General.
Check these two fields:
- WordPress Address (URL)
- Site Address (URL)
Both should usually match and should both use either https:// or http://, depending on your final setup.
For most modern sites behind Cloudflare, both should use HTTPS.
When you cannot access wp-admin
If the redirect loop prevents login, you can update the URLs in wp-config.php or directly in the database.
Many hosts also let you change these values through phpMyAdmin or a control panel.
In wp-config.php, you can define:
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');Replace example.com with your domain name and make sure the protocol matches your intended SSL setup.
Make sure Cloudflare and WordPress agree on HTTPS
WordPress needs to know when a request is secure.
Behind Cloudflare, the application may receive traffic from Cloudflare instead of directly from the visitor, so HTTPS detection can be inconsistent if the server is not configured correctly.
Check the origin server SSL certificate
If you use Cloudflare Full (Strict), the origin server must have a valid certificate.
This can be a certificate from a public certificate authority or a Cloudflare Origin Certificate installed on your server.
If your server certificate is missing, expired, or installed for the wrong hostname, WordPress may redirect to HTTPS while Cloudflare cannot complete the secure connection properly.
Look for forced HTTPS redirects at the server level
Apache and Nginx configurations may contain rules that force all traffic to HTTPS.
These rules are not inherently bad, but when paired with Cloudflare Flexible SSL, they often create loops.
Review these settings in your host panel or server configuration files.
Examples of places to check include:
.htaccesson Apache servers- Nginx rewrite rules
- Hosting control panel redirect tools
- Security plugins that enforce SSL
Review Cloudflare page rules, redirect rules, and Always Use HTTPS
Cloudflare can redirect traffic in several places, and overlapping rules may create conflict.
The most important feature to review is Always Use HTTPS, but page rules and redirect rules can also be involved.
What to inspect
- Always Use HTTPS: This is useful only when your origin and WordPress are already aligned with HTTPS.
- Redirect Rules: Check for rules that send
http://tohttps://or switch between www and non-www in both directions. - Page Rules: Old page rules may still apply even if you added newer redirect logic elsewhere.
If more than one rule is handling the same URL pattern, simplify the setup so only one component performs the redirect.
Temporarily disable plugins that may interfere
WordPress redirect, cache, security, and SSL plugins are frequent contributors to loop problems.
If the issue began after installing or changing a plugin, test with a clean plugin stack.
Plugins to review
- SSL enforcement plugins
- Redirection plugins
- Security plugins with login protection
- Cache plugins that rewrite canonical URLs
Disable them one by one if possible, then clear both the WordPress cache and the Cloudflare cache.
If the loop stops, you have identified the source.
Clear caches in the right order
Redirect loops can persist because the browser, Cloudflare, and WordPress each store different versions of the site.
Clearing cache does not fix the root cause, but it helps confirm whether the settings change worked.
Recommended cache reset order
- Clear Cloudflare cache.
- Clear your WordPress cache plugin cache.
- Clear any server-side cache from your host.
- Test in an incognito window or a different browser.
This order reduces the chance of testing against stale redirects.
Use the correct www and non-www version
Another common cause of a Cloudflare WordPress redirect loop is a mismatch between www.example.com and example.com.
If Cloudflare redirects one version while WordPress expects the other, the browser may bounce back and forth.
Pick one canonical version and use it consistently across:
- WordPress Address and Site Address
- Cloudflare redirect rules
- Server-level redirects
- Internal links and SEO settings
Consistency matters more than which version you choose.
Advanced checks if the loop continues
If the basic fixes do not solve the problem, inspect the full redirect chain.
Tools such as browser developer tools, curl -I, or online redirect checkers can show where the loop begins.
What to look for in the redirect chain
- Repeated switches between HTTP and HTTPS
- Repeated switches between www and non-www
- Unexpected redirects to the login page
- Conflicting location headers from Cloudflare and the origin server
You may also need to review custom code in functions.php, theme files, or must-use plugins.
A hard-coded redirect in the application layer can be difficult to notice but easy to reproduce once identified.
Fast troubleshooting checklist
- Set Cloudflare SSL/TLS to Full or Full (Strict).
- Confirm the origin server has a valid SSL certificate.
- Make WordPress Address and Site Address match.
- Remove duplicate HTTPS or www redirects.
- Disable plugins that force SSL or rewrite URLs.
- Clear Cloudflare, server, and WordPress caches.
- Test the site in a private browser window.
When these settings align, a Cloudflare WordPress redirect loop usually disappears quickly.
The key is to let only one layer control each type of redirect and keep WordPress, Cloudflare, and the origin server using the same protocol and domain version.