ERR_TOO_MANY_REDIRECTS: How to Find and Fix a Redirect Loop

ERR_TOO_MANY_REDIRECTS is Chromium net error -310, "Attempting to load an URL resulted in too many redirects." Chrome follows at most 20 redirects per request (kMaxRedirects = 20 in the network stack) and then stops with the page "This page isn't working. example.com redirected you too many times. Try deleting your cookies."

Everything below HTTP worked: DNS resolved, TCP connected and TLS succeeded on every hop. Each response is a valid 301, 302, 307 or 308; the problem is where they point. In practice it is a loop, such as http to https and back, or www to the bare domain and back. A legitimate chain longer than 20 hops is rare and is a bug of its own. The certificate is not the cause, even though the loop often starts right after HTTPS is switched on.

The classic loop is a TLS termination mismatch. A CDN or load balancer talks HTTPS to the visitor but plain HTTP to the origin; the origin sees an HTTP request, redirects to HTTPS, and the next request again arrives over HTTP. The second pattern is two rules that disagree: the web server sends www to the bare domain while the CMS, whose site URL is set with www, sends it back. The same happens with trailing slashes and with language or geo redirects.

Two causes live in the browser. Redirects that depend on a cookie (login, consent, locale) loop when the cookie cannot be stored, which is why Chrome suggests deleting cookies. And a site that has sent an HSTS header but now redirects HTTPS to HTTP loops because the browser rewrites every http:// request back to https:// internally (shown in DevTools as "307 Internal Redirect").

Cloudflare's own troubleshooting page names three sources. With SSL/TLS encryption mode Flexible, Cloudflare connects to the origin over HTTP, so an origin that redirects HTTP to HTTPS loops forever: set the mode to Full (strict), which needs a valid certificate on the origin (a free Cloudflare Origin CA certificate works), or remove the origin redirect. With Full or Full (strict), an origin that redirects HTTPS to HTTP loops. The same applies to Always Use HTTPS combined with an origin that downgrades to HTTP, and to redirect rules that overlap with origin rules.

On nginx, give each scheme and host exactly one job, and redirect straight to the final URL:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name www.example.com;
    return 301 https://example.com$request_uri;
}
server {
    listen 443 ssl;
    server_name example.com;
    # canonical host: no scheme or host redirects here
}

When TLS ends at a load balancer, the application must read the original scheme from X-Forwarded-Proto instead of the connection. For WordPress behind a proxy, add to wp-config.php:

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

1. Print the chain. curl -sIL --max-redirs 25 https://example.com/ | grep -iE '^(HTTP|location)'. The loop is visible as the same two Location values repeating; curl itself stops after 50 with Maximum (50) redirects followed.
2. Test the origin without the proxy. curl -sI --resolve example.com:443:203.0.113.10 https://example.com/ (your origin IP). If the origin alone answers 200, the loop comes from the CDN mode or a CDN rule.
3. Align the CMS URL. In WordPress, Settings > General (or the WP_HOME and WP_SITEURL constants) must match the canonical scheme and host exactly; other CMSs have an equivalent site URL setting.
4. Remove duplicate rules. Search .htaccess, nginx includes, plugin settings and CDN redirect rules for scheme and host redirects; keep one place that owns them.
5. Check HSTS against downgrades. If the site sends Strict-Transport-Security, no rule may redirect HTTPS to HTTP.
6. Mind cached 301s. Browsers cache permanent redirects, so test fixes with curl or a fresh profile, and prefer 302 while you experiment.

Delete the cookies for this site (Chrome: the lock or tune icon in the address bar > Cookies and site data) and reload; this fixes loops that depend on a broken login or consent cookie. An incognito window is a quick test of the same idea. Because 301 redirects can be cached, clearing cached images and files also helps if the site was fixed recently.

If the loop appears in every browser and on every network, it is a server or CDN configuration error, and nothing on your device will fix it. Your system clock, antivirus and DNS settings are not involved.

curl -sIL -o /dev/null -w '%{http_code} after %{num_redirects} redirects\n' http://www.example.com/
# expect: 200 after 1 redirects (or 2 at most)

Run it for all four entry points (http and https, with and without www); each should reach the canonical URL in one or two hops. The redirect chain checker shows every hop with its status code and target, and the HTTP status checker confirms the final page answers 200.

• HSTS error
• ERR_HTTP_RESPONSE_CODE_FAILURE — the redirect chain ends on a 4xx/5xx
• How to redirect www to non-www
• ERR_TOO_MANY_REDIRECTS troubleshooting guide
• How to check redirects
• Redirect chains and SEO