Fix ERR_TOO_MANY_REDIRECTS behind Cloudflare

Updated 5 November 2026 · By Brent Alexis

Reproduced in the lab with ProxyForge's own HTTPS output on the official nginx image (Nginx 1.30.6) and Apache image (2.4.68). Cloudflare can't run in a lab, so an Nginx container stood in for it, connecting to the server the way Cloudflare's documentation describes each mode: 43 checks. The browser behaviour was checked in Chromium 153. Dashboard settings and error 526 come from Cloudflare's documentation. How it's tested

• Is it this loop?
• Why Flexible loops
• Fix: Full (strict)
• No certificate on the server yet?
• Other loops behind Cloudflare
• After the fix: test in a private window

Is it this loop?

Chrome shows:

This page isn’t working
example.com redirected you too many times.
Try deleting your cookies.
ERR_TOO_MANY_REDIRECTS

Deleting cookies doesn't fix this one: the loop is between Cloudflare and your server. To see it, ask for the page from a terminal:

curl -sI https://example.com/ | grep -iE '^(HTTP|location)'

HTTP/2 301
location: https://example.com/

A redirect to the same address you asked for is the loop. Following it gives up after 20 tries:

curl -sS -L --max-redirs 20 -o /dev/null https://example.com/

curl: (47) Maximum (20) redirects followed

Why Flexible loops

Cloudflare's SSL/TLS mode decides how Cloudflare talks to your server (source: Cloudflare's encryption modes page, checked 5 November 2026):

With Flexible, every visit goes round the same circle:

1. The visitor asks Cloudflare for https://example.com/.
2. Cloudflare asks your server for the page over plain HTTP, on port 80.
3. Your port-80 site answers with a redirect to https://example.com/.
4. Cloudflare passes that redirect back to the visitor, who asks for https://example.com/ again.

In the lab, ProxyForge's own HTTPS output looped exactly like this on Nginx 1.30.6 and Apache 2.4.68 behind a stand-in for Flexible, and so did deeper pages such as /blog/post?id=1. The server config itself was fine: on its own it redirected http:// to https:// once and served the page.

Fix: Full (strict)

Keep your server's HTTPS redirect and make Cloudflare connect over HTTPS:

1. Put a certificate on your server that's valid for your domain: a Let's Encrypt certificate from Certbot (the SSL Generator gives you the command), or a free Cloudflare Origin CA certificate. An Origin CA certificate is trusted by Cloudflare only, not by browsers, so it only works while the site stays proxied (orange cloud) (source: Cloudflare Origin CA, checked 5 November 2026).
2. Serve HTTPS on port 443 with that certificate. ProxyForge's Config Generator with HTTPS and Behind Cloudflare ticked gives you both server blocks (or Apache virtual hosts), and restores real visitor IPs too.
3. In the Cloudflare dashboard, open your domain, go to SSL/TLS, Overview, and check Current encryption mode. Click Configure and choose Full (strict). If the page says Automatic mode enabled, Cloudflare picks the mode from a scan of your server; choosing Full (strict) yourself makes sure.

In the lab, the same Nginx and Apache output worked behind Full and Full (strict): the page loaded, a visit to http:// was redirected once and then loaded, and the app was told X-Forwarded-Proto: https.

Full (strict) is the mode that checks the certificate. In the lab it refused a self-signed certificate on the server, while plain Full accepted it. With Full (strict), Cloudflare shows error 526 when it can't validate your certificate: expired, self-signed, the wrong domain name, or a missing intermediate certificate (source: Cloudflare error 526, checked 5 November 2026). Plain Full would hide a broken certificate, so use Full (strict).

No certificate on the server yet?

Cloudflare's other fix is to keep Flexible and remove the redirect from your server, letting Cloudflare send visitors to HTTPS instead (Always Use HTTPS, under SSL/TLS, Edge Certificates). In ProxyForge, that's the output with HTTPS unticked: port 80 only, no redirect.

In the lab this stopped the loop: http:// was redirected once by the stand-in for Cloudflare, and https:// loaded. But the app behind Nginx was told X-Forwarded-Proto: http, because the request reached Nginx over plain HTTP. Apps that use that header to build links or to force HTTPS see every visit as insecure.

Treat it as a stopgap: the hop from Cloudflare to your server is unencrypted, and apps that force HTTPS on their own can start the loop again. Getting a certificate and moving to Full (strict) fixes both.

Other loops behind Cloudflare

• Your HTTPS site redirects back to HTTP. Then even Full loops: in the lab, a server whose HTTPS site redirected to http:// looped behind Full just like Flexible. Look for a return 301 http:// or a site URL still set to http:// (WordPress: Settings, General).
• Two redirect rules point at each other, for example www to the bare domain in Cloudflare and back to www on your server. Pick one direction and remove the other (source: Cloudflare's redirect loop page, checked 5 November 2026). This case isn't lab-tested.

After the fix: test in a private window

Chrome remembers a 301 redirect. In our Chromium 153 test, after the loop was fixed on the server, the same browser still showed ERR_TOO_MANY_REDIRECTS without asking the server again, while a new private window loaded the page at once. So after changing the mode, check in a private (incognito) window or with curl, which doesn't cache anything. Your usual window may keep showing the error until its cache is cleared.

If the change still seems to do nothing, check that the server config really applied: see nginx -s reload said OK, but my change didn't apply.

Generate an HTTPS config for a site behind Cloudflare →

How to use ProxyForge · FAQ: common errors · Guides · What's new · About