Cloudflare too many redirects: why it starts after a DNS move and how to fix it

First, work out which loop you have

A redirect loop means two parts of the setup keep sending the browser back and forth until it gives up. Cloudflare's own ERR_TOO_MANY_REDIRECTS troubleshooting page lists the usual causes: the SSL/TLS encryption mode, two settings on the Edge Certificates page (Always Use HTTPS and HSTS), and redirect rules that conflict. The quickest way to tell them apart is to look at the chain of redirects.

1. Open a private or incognito window, so old cached redirects do not confuse things.
2. Open Chrome's developer tools, go to the Network tab and tick Preserve log.
3. Load the site and click the first few entries with a 301, 302, 307 or 308 status. The Location response header shows where each hop sends the browser.

Then match what you see:

If you cannot inspect the chain, check the encryption mode anyway. Flexible mode on a server that already forces HTTPS is the classic cause of a loop straight after the nameserver change, so it is the first setting to look at.

Fix 1: Change Flexible to Full (strict) or Full

In Flexible mode, Cloudflare encrypts the connection to the visitor but talks to your server over plain HTTP. If the server, a plugin or an .htaccess rule redirects HTTP to HTTPS, it redirects every request Cloudflare sends. The browser asks again over HTTPS, Cloudflare forwards it as HTTP again, and round it goes. Cloudflare's Flexible mode page says plainly that this 'creates a redirect loop that makes your site inaccessible'.

1. In the Cloudflare dashboard, open the domain and go to the SSL/TLS Overview page.
2. If the zone uses Automatic SSL/TLS, select the custom option so you can set the mode yourself, as described in Cloudflare's encryption modes guide.
3. Choose Full (strict) if the server has a valid certificate: unexpired, issued by a publicly trusted authority such as Let's Encrypt or by Cloudflare Origin CA, and matching the hostname. If the site loaded over https:// without warnings before the DNS move, the server already has a certificate.
4. Choose Full instead if the certificate is self-signed or expired. Cloudflare does not validate the certificate in this mode.
5. Reload the site in a new private window.

How to check it worked: the page loads over https:// with no loop. If you now see error 526, the certificate fails the Full (strict) checks, so use Full while you sort out the certificate. Error 525 means the server is not accepting HTTPS on port 443, which Full mode needs.

If the server has no certificate and the host cannot add one: stay on Flexible, but remove the HTTPS redirect from the server (the host's force HTTPS option, an .htaccess rule or a plugin) and let Cloudflare redirect at its edge with Always Use HTTPS (see Fix 3). On WordPress, the WordPress HTTPS guide warns that forced SSL options behind a proxy that provides SSL will 'initially send any requests into an infinite redirect loop' unless WordPress is set up to recognise the HTTP_X_FORWARDED_PROTO header. That is a job for whoever manages the server. Treat Flexible as a stopgap. Cloudflare recommends Full or Full (strict) wherever possible and advises against Flexible for sites with logins or personal data.

Fix 2: Remove an HTTPS to HTTP redirect on the server

In Full and Full (strict) modes, Cloudflare connects to the server over HTTPS. If the server then redirects HTTPS requests to http://, you get a loop, especially when Always Use HTTPS or HSTS pushes the browser straight back. Cloudflare's fix is to remove HTTP redirects from the origin.

Common places where this kind of redirect hides:

• WordPress site addresses that still start with http://. Go to Settings then General and check that both WordPress Address (URL) and Site Address (URL) start with https:// (the fields are described in WordPress's migration guide, and its HTTPS guide says to set the address to the https version).
• An old rewrite rule in the server configuration or .htaccess file that sends traffic to http://.
• A plugin or host setting that forces one particular protocol.

If the loop stops you reaching the WordPress dashboard, ask the host to change the addresses. Cloudflare's own advice for redirects coming from the server is to contact your hosting provider or site administrator. For WordPress sites, Cloudflare also suggests installing the Cloudflare WordPress plugin on the server and turning on its Automatic HTTPS rewrites option to reduce redirect loops and mixed content errors.

How to check it worked: load the https:// address in a private window with the Network tab open. The first response should be the page itself (status 200), not a redirect to http://.

Fix 3: Stop Always Use HTTPS fighting the server

Always Use HTTPS redirects every http:// request to https:// at Cloudflare, for all subdomains and hosts. That is what you want, unless the server is redirecting HTTPS back to HTTP. Then the two bounce the visitor between them.

Cloudflare documents two ways out:

• Better: remove the HTTPS to HTTP redirect from the server (Fix 2) and keep Always Use HTTPS on. Cloudflare recommends not doing redirects on the origin server at all, and its guide to enforcing HTTPS notes that it is much faster for Cloudflare to redirect requests before they reach the server.
• Quick but temporary: go to the Edge Certificates page (under SSL/TLS) and switch Always Use HTTPS off. The loop stops, but visitors may end up on the insecure http:// version, so only use this until the server redirect is gone.

Always Use HTTPS is hidden when the encryption mode is Off. Cloudflare also advises turning it on only when the whole site supports HTTPS. If only part of it does, use a single redirect rule instead.

The setup that stays fixed: Full (strict), Always Use HTTPS on, and no protocol redirects on the server. Make this the standard for every client zone, especially if you are managing multiple client websites.

Fix 4: Deal with HSTS carefully

HTTP Strict Transport Security (HSTS) tells compliant browsers to turn http:// links into https:// themselves. Cloudflare's troubleshooting page says it causes a loop when the server redirects HTTPS to HTTP, or when the encryption mode is set to Off.

1. Remove any HTTPS to HTTP redirect from the server (Fix 2).
2. On the SSL/TLS Overview page, make sure the mode is Flexible or higher, ideally Full (strict).
3. Test in a private window.

Cloudflare does list turning HSTS off as an alternative, but that does not help visitors whose browsers have already received the header. The HSTS documentation warns that if HTTPS is removed while HSTS is active, the site 'becomes inaccessible to visitors for the duration of the Max Age Header or until you enable HTTPS'. Getting HTTPS working is the real fix. If you still want HSTS off from now on:

1. Go to the Edge Certificates page.
2. Under HTTP Strict Transport Security (HSTS), select Enable HSTS.
3. Set Max Age Header to 0 (Disable). If No-Sniff was on and you want it removed, set it to Off. Select Save.

While HSTS is on, Cloudflare also warns against switching proxied DNS records to DNS only, pausing Cloudflare, moving the nameservers away, redirecting HTTPS to HTTP or disabling SSL. Do not try any of those as quick tests.

Fix 5: Untangle redirect rules and Page Rules

The last common cause is redirects that contradict each other. Cloudflare's example is https://a.example.com redirecting to http://b.example.com, which redirects back to https://a.example.com. After a DNS move, it is often a www rule in Cloudflare pointing one way while the host, or an older Page Rule, points the other way.

1. Go to the Rules Overview page and review every redirect rule for the domain.
2. Open Rules then Page Rules and look for any rule that redirects. Page Rules are deprecated, and Cloudflare's newer Rules products take precedence over them when both match. A disabled Page Rule does not trigger.
3. If the account uses Bulk Redirects (set at account level, across domains), check those too. When Single Redirects and Bulk Redirects both match, Single Redirects run first.
4. Check that no Cloudflare redirect sends visitors to an address beginning with http://, as Cloudflare's guide to enforcing HTTPS advises.
5. Compare what is left with the redirects on the server, and keep each redirect in one place only.

To see what Cloudflare actually does with a request, use Cloudflare Trace: go to the Trace page, enter the URL, choose the method and select Send Trace. The results list the configurations that ran, in evaluation order. Only users with the Administrator or Super Administrator role can use Trace, so on a client's account you may need them to run it or give you that role.

How to check it worked: every version of the address (http and https, with and without www) should reach the final URL in one hop, or two at most.

If none of this worked

Find out whether the loop comes from Cloudflare or from the server. Cloudflare suggests pausing it for a short while: on the domain's Overview page, choose Advanced Actions then Pause Cloudflare on Site. Traffic then goes straight to the server within five minutes or less, and visitors see the server's own certificate (see pausing Cloudflare). If the loop continues while paused, the redirect is on the server and the host needs to fix it. Do not pause if HSTS is enabled (see Fix 4).

Before asking for help, collect:

• A HAR file recorded in a private window. Cloudflare's guide to gathering troubleshooting information explains how. Remove sensitive data before you send it.
• The output of curl -svo /dev/null https://www.example.com/ (using your domain), plus the same request sent directly to the server's IP address with curl's --connect-to option, as the same guide shows.
• The Ray ID from the cf-ray response header, with the time in UTC.
• Screenshots of the SSL/TLS Overview and Edge Certificates pages, and a list of your redirect rules and Page Rules.

Where to go: on Cloudflare's Free plan, technical questions go to the Cloudflare Community, because Free accounts can only open support cases for billing, account and registrar issues. Pro, Business and Enterprise accounts can open a case from the Support page by choosing Technical Support (see Contacting Cloudflare Support). Cloudflare support cannot change settings for you, and anything on the server is the host's job. If the domain points at a hosted builder rather than a server you control, follow that platform's own domain instructions too. Our guide to a GoHighLevel domain not connecting is one example.

Frequently asked questions

Why did the site break right after I moved DNS to Cloudflare?

Cloudflare now sits between visitors and your server, and its encryption mode or HTTPS settings can clash with redirects the server was already doing. The classic case is Flexible mode, where Cloudflare connects over HTTP, meeting a server that forces HTTPS. Nothing on the server changed. Only the route to it did.

Which SSL/TLS encryption mode should I use?

Use Full (strict) whenever the server has a valid certificate. Cloudflare recommends Full or Full (strict) where possible because they protect the connection to your server. Use Full if the certificate is self-signed or expired. Keep Flexible for servers that cannot have a certificate at all, and avoid it for sites with logins or personal data.

Will switching from Flexible to Full (strict) break anything?

Not if the server has an unexpired certificate from a publicly trusted authority or from Cloudflare Origin CA that matches the hostname. If it does not, visitors see error 526. Full mode skips the certificate check but still needs HTTPS working on port 443, otherwise you get error 525.

I changed the setting but still see ERR_TOO_MANY_REDIRECTS. Why?

Your browser may have remembered the old redirect, so test in a private window or on another device first. If HSTS is enabled, browsers that already received it keep forcing HTTPS until the max age runs out, so the server must handle HTTPS properly. If it still loops, run a Cloudflare Trace and check the redirects on the server.

Should redirects live in Cloudflare or on my server?

Cloudflare advises generally avoiding redirects on the origin server, because it is faster for Cloudflare to redirect requests before they reach it. Whichever you choose, keep each redirect in one place. Loops start when Cloudflare and the server both try to decide the same thing.

If you would rather not manage a host and Cloudflare separately

Nearly every loop in this guide comes from two systems, a web host and Cloudflare, both trying to manage HTTPS. If you build small sites for clients and would rather have hosting and the certificate in one place, every WebNewBiz plan includes hosting with SSL, so you do not have to set up a certificate on a separate server and keep it matched to an encryption mode. The honest limits: it is a young platform with a much smaller app ecosystem than Wix, Squarespace or Shopify. Existing sites are not moved over as files (content and the domain move, and the layout is rebuilt). And if you still put the domain behind Cloudflare's proxy, everything above still applies.

Create your website for $1. The first month is $1, then the plan's normal price (from $9 a month), and you can cancel any time. If you are an agency, talk to us about white-label.