How to fix ERR_TOO_MANY_REDIRECTS and redirect loops

What ERR_TOO_MANY_REDIRECTS means

ERR_TOO_MANY_REDIRECTS is Chrome's message for a redirect loop. The server answered your request with a redirect (a 301, 302, 303, 307 or 308 status and a Location header), the browser followed it, and the next address redirected again, back to where it started or round a longer circle. After a set number of hops the browser gives up rather than loop for ever. Firefox reports the same fault as "The page isn't redirecting properly"; Edge and other Chromium browsers use the Chrome wording.

In almost every case the fault is on the website, not your computer: two parts of the stack disagree about the correct address, such as HTTPS versus HTTP, or www versus the bare domain.

Quick-fix checklist

1. Visitor: open the page in a private or incognito window. If it loads there, delete the cookies for that one site and reload.
2. Owner: run curl -sSIL --max-redirs 10 http://example.in/ and read the Location lines to see where the loop turns back.
3. Owner on Cloudflare: check the SSL/TLS encryption mode. Flexible plus an HTTPS redirect on the server is the most common loop.
4. Owner: look for two redirect rules that fight, in .htaccess, the Nginx config, the cPanel Force HTTPS toggle and any CDN redirect rules.
5. WordPress owner: confirm the WordPress Address and Site Address match the address you actually want, scheme and www included.
6. WordPress owner: disable redirect, SSL and caching plugins one at a time, then purge every cache.

Visitor side vs site owner side

If a private window shows the same error, clearing anything on your side will not help. Tell the site owner the exact URL and the time you tried.

In Chrome, click the icon to the left of the address and delete that site's cookies and site data.

How to trace the loop

Ask the server what it is doing. From any terminal:

curl -sSIL --max-redirs 10 http://example.in/

-I asks for headers only, -s hides the progress meter while -S still shows errors such as the redirect limit, -L follows each redirect, and --max-redirs stops curl after ten hops. A loop looks like this:

HTTP/1.1 301 Moved Permanently
Location: https://example.in/

HTTP/2 301
location: http://example.in/

HTTP/1.1 301 Moved Permanently
Location: https://example.in/
...
curl: (47) Maximum (10) redirects followed

The pattern tells you the cause. HTTPS sending you back to HTTP points at a CMS URL setting or a server rule written for plain HTTP. www and the bare domain swapping means two host rules disagree. A server: cloudflare header on every hop means the request passes through Cloudflare, so check its SSL mode first. An online redirect checker shows the same chain if you have no terminal, but curl also lets you add -H "Cookie: ..." to reproduce cookie-based loops.

Cause 1: Cloudflare Flexible SSL with an HTTPS redirect on the server

In Flexible mode Cloudflare serves HTTPS to the visitor but connects to your server over plain HTTP. Your server sees an HTTP request, applies its "force HTTPS" rule and replies with a redirect to HTTPS. The browser asks for HTTPS again, Cloudflare fetches over HTTP again, and the loop never ends.

The fix:

1. Make sure the origin has a valid certificate (a Let's Encrypt certificate is fine).
2. In the Cloudflare dashboard go to SSL/TLS and set the encryption mode to Full (strict), or Full if the certificate cannot yet be validated.
3. Keep one HTTP-to-HTTPS redirect: either your server rule or Cloudflare's Always Use HTTPS setting under Edge Certificates, not a chain of both plus a plugin.

The reverse loop also happens: in Full or Full (strict) mode, an origin rule that sends HTTPS requests back to HTTP will loop. Remove that rule. If you have enabled HSTS, the browser insists on HTTPS whatever the server says, so any rule pushing visitors to HTTP must go.

Cause 2: conflicting HTTPS and www rules

A common mess is one rule that adds www, a second that strips it and a third that forces HTTPS. Pick one canonical address, for example https://example.in, and send every other combination there in a single hop.

.htaccess (Apache and LiteSpeed)

RewriteEngine On
RewriteCond %{HTTPS} !=on [OR]
RewriteCond %{HTTP_HOST} ^www\. [NC]
RewriteRule ^ https://example.in%{REQUEST_URI} [L,R=301]

This redirects only when the request is not HTTPS or uses www. A request for https://example.in/ matches neither condition, so it is served and the loop cannot start. Put it at the top of the file, above the WordPress block, and delete any older HTTPS or www rules further down. Apache's HTTPS variable reads "on" only when the connection to this server is encrypted, so behind a proxy that talks plain HTTP to the origin it is always "off" and this rule will loop. That is Cause 1 again: fix the proxy mode rather than the rule.

On cPanel, also check Domains: the Force HTTPS Redirect toggle is a second HTTPS redirect. Use the toggle or the rule, not both, and look under Domains → Redirects for leftover redirects.

Nginx

Nginx's own documentation recommends a separate server block per host name rather than if tests on the host:

# All plain HTTP, both names: one hop to the canonical address
server {
    listen 80;
    listen [::]:80;
    server_name example.in www.example.in;
    return 301 https://example.in$request_uri;
}

# HTTPS on www: one hop to the bare domain
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name www.example.in;
    ssl_certificate     /etc/ssl/example.in/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.in/privkey.pem;
    return 301 https://example.in$request_uri;
}

# The canonical site: no redirect here
server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.in;
    ssl_certificate     /etc/ssl/example.in/fullchain.pem;
    ssl_certificate_key /etc/ssl/example.in/privkey.pem;
    root /var/www/example.in;
}

The canonical block contains no return, so nothing can send a visitor back out. Test with sudo nginx -t and reload with sudo systemctl reload nginx. If Nginx proxies to an application, pass the scheme on with proxy_set_header X-Forwarded-Proto $scheme; so the application knows the visitor used HTTPS.

Cause 3: WordPress site URL mismatch

WordPress redirects requests to the address stored as its Site Address. If that is http://www.example.in while the server forces https://example.in, the two bounce visitors between them. Check under Settings → General, or, if you cannot reach the dashboard, set the values in wp-config.php:

define( 'WP_HOME', 'https://example.in' );
define( 'WP_SITEURL', 'https://example.in' );

Both must match your canonical address exactly. Constants in wp-config.php override the database values, so remember they are there if you change domain later.

HTTPS behind a proxy or load balancer

When a proxy ends the TLS connection and talks to WordPress over HTTP, WordPress believes every request is insecure and keeps redirecting to HTTPS, especially with FORCE_SSL_ADMIN set. The WordPress documentation describes this exact loop. Add this to wp-config.php above the line that loads wp-settings.php:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] )
    && strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) {
    $_SERVER['HTTPS'] = 'on';
}

The isset check avoids a PHP warning when the header is absent. Only use this when a proxy you control sets the header, because a visitor can send it too.

Cause 4: plugin and application redirects

SSL plugins, redirect managers, multilingual plugins and security plugins all issue redirects, and two of them can disagree with each other or with the server. If the curl trace shows a redirect only on certain paths, or an x-redirect-by header naming a plugin, that plugin is your suspect. If you cannot log in, rename wp-content/plugins to plugins-off through the file manager or SSH, which deactivates them all, then rename it back and reactivate one at a time. Purge the page cache and any CDN cache afterwards, since a cached 301 can keep the loop alive after the fix.

Cause 5: cookie-based loops

Some redirects depend on a cookie: a login wall that sends you to the sign-in page until a session cookie exists, a language or region chooser, or a consent gate. If the cookie is never stored, because its Domain attribute names a different host, it is marked Secure on an HTTP page, or the browser blocks it, the site redirects for ever. Compare the Set-Cookie headers in the curl trace with the host and scheme of the final address.

How this applies on Bigdomainhost

On Web & cPanel hosting and WordPress hosting, sites run on LiteSpeed servers in Mumbai and use .htaccess rules, so the single-rule example above applies directly. A free Let's Encrypt certificate is issued for each domain once it points to the server; you can check it under cPanel → SSL/TLS Status, as described in the SSL section of the docs. Confirm the certificate is active before switching Cloudflare to Full (strict). On WordPress hosting the HTTPS redirect and HSTS are already configured, so a second HTTPS plugin or rule only adds hops, and nothing should send visitors back to HTTP.

On a KVM VPS you have root access and write the Nginx or Apache config yourself, so the separate-server-block pattern is the one to use. If you are moving a site, the migration guide explains how to check URLs and DNS before switching over. If a loop persists, call or WhatsApp +91 75994 50220 or email support@bigdomainhost.com with the curl output.

Sources (checked 15 November 2026)

• Cloudflare Docs: ERR_TOO_MANY_REDIRECTS
• MDN Web Docs: Redirections in HTTP
• Apache HTTP Server: Apache Module mod_rewrite
• nginx.org: Converting rewrite rules
• WordPress Developer Resources: HTTPS (Advanced Administration)
• cPanel Docs: Domains