ERR_TOO_MANY_REDIRECTS: how to break a redirect loop

The browser shows "ERR_TOO_MANY_REDIRECTS" (on Chrome) or "The page isn't redirecting properly" (on Firefox): the site asks to go to another address, that address sends you back, and the loop never closes. In practice, two redirect rules are contradicting each other.

The quickest check

Before looking at any configuration file, look at the actual chain. From a Linux or macOS terminal:

curl -IL --max-redirs 10 https://yourdomain.co.uk

-I requests only the headers, -L follows redirects, and --max-redirs 10 stops the command after 10 hops instead of running forever. If the site is looping, you'll see the same pair of URLs alternating (e.g. http://yourdomain.co.uk → https://yourdomain.co.uk → http://yourdomain.co.uk...) until curl stops on its own with a "too many redirects" error. The line that matters is the one with Location:, which tells you where the browser is being sent at each step.

The four causes, in order of frequency

1. Double HTTPS rule: server and application in conflict

This happens when both the web server and the CMS (WordPress, a .htaccess file, an Nginx rule) force a switch to HTTPS, but one of the two starts from a faulty condition (e.g. it doesn't recognise the header indicating the connection is already encrypted behind a proxy).

How to tell if this is your case: in the curl -IL chain, only the protocol changes (http↔https), never the domain.

How to fix it, on Ubuntu 24.04 with Nginx and PHP-FPM: check whether there's a redirect rule both in the Nginx server block (return 301 https://...) and in the application code (on WordPress, often in wp-config.php with $_SERVER['HTTPS']). Keep only one, preferably at server level.

On cPanel: check under "Domains" whether "Force HTTPS Redirect" is enabled alongside a manually written redirect in the domain's .htaccess file: these are the two rules fighting each other.

On Plesk: the automatic redirect is enabled from Websites & Domains → Hosting Settings → "Permanent SEO-safe 301 redirect"; if there's also a manual rule in .htaccess or in the domain's additional nginx directives file, one of the two needs to be removed.

2. www and non-www configured in two different places

One point redirects www→non-www, another (CDN, DNS, control panel) redirects the opposite way.

How to tell if this is your case: the chain shows a host change (www.yourdomain.co.uk ↔ yourdomain.co.uk) in addition to, or instead of, the protocol change.

How to fix it: choose a single canonical version and make sure the rule is written in only one point of the chain (DNS/CDN or web server, never both). On Nginx, check that there aren't two server blocks redirecting to each other; on Plesk/cPanel, check both the hosting settings and any rules manually added to the additional configuration files.

3. CDN in "flexible" mode in front of a server that redirects

If the CDN speaks HTTP to your server while promising HTTPS to the visitor (a mode often called "flexible"), and your server in turn forces HTTPS on every request it doesn't recognise as already encrypted, the server redirects to the CDN, which redirects back to the server: an infinite loop.

How to tell if this is your case: temporarily remove the CDN (point the DNS straight at the server's IP) and run curl -IL again. If the loop disappears, that's the cause.

How to fix it: in the CDN's control panel, change the encryption mode to "full" or "full (strict)", so the CDN also speaks HTTPS to your server, instead of "flexible". If the problem persists even with the CDN disabled, the cause lies in the server, not the provider.

4. Wrong site address in the application settings

On WordPress, Nextcloud and other CMSs, the site URL is also stored at application level (database or configuration file), not just in the web server. If that URL doesn't match the real domain (e.g. it's still http:// after switching to HTTPS, or still points to the old domain after a migration), the application redirects on its own to the wrong address, conflicting with the server's rules.

How to tell if this is your case: the loop appears only on certain pages (e.g. the admin area) and not on a static HTML page placed in the same folder.

How to fix it: on WordPress, correct siteurl and home in the wp_options table (or in the wp-config.php file if you've forced them there) so that they exactly match the correct domain and protocol.

Where to look if the commands aren't enough

If you want to see what's happening server-side while you make the request, on Ubuntu 24.04 with Nginx the error log is, by default, at /var/log/nginx/error.log, according to the official Nginx documentation: on RHEL, Debian and Ubuntu the default path is /var/log/nginx/error.log. Follow it in real time with:

sudo tail -f /var/log/nginx/error.log

On cPanel, logs can be viewed from "Metrics" → "Errors" in the panel; on Plesk from Websites & Domains → Logs → error_log, as described in the official Plesk documentation.

How to check that it's fixed

Run curl -IL --max-redirs 10 https://yourdomain.co.uk again: the chain must end with a single HTTP/1.1 200 (or HTTP/2 200), without ever returning to a previously visited URL. Also check the www and http versions, if the domain accepts both: they should all converge on the same final address.

When to call the provider's support

If the loop only disappears when you disable the CDN but you can't work out why, open a ticket with the CDN provider attaching: the output of curl -IL run through the CDN, the same command run pointing at the server's IP (bypassing the CDN), and the encryption mode currently set in the panel. Without these three pieces of information, support will ask you to reproduce them anyway, wasting time you don't have while the site is down.