ERR_TOO_MANY_REDIRECTS behind a CDN: the two settings that loop together.
A CDN that fetches the origin over plain HTTP and an origin that forces HTTP to HTTPS are each fine alone and loop together. How to recognise the pair, reproduce it in one request and close both ends.
In this article 4 sections
- The pair to look for when a site behind a CDN returns ERR_TOO_MANY_REDIRECTS: a CDN SSL mode that fetches the origin over plain HTTP, and an origin that force-redirects HTTP to HTTPS without checking what the proxy already did.
- Two faults, each harmless alone. Plenty of origins serve HTTP behind a CDN that terminates TLS, and plenty of origins force HTTPS. Only the two together loop.
- The loop can leave no access-log entry at all, because the tier answering the redirect may not log routine requests. Silence looks like no traffic, and points the search the wrong way.
- Reproduce it with one request against the origin, along the path visitors take, then fix both ends so the loop cannot form however the site is fronted.
Enabling the CDN proxy in front of an origin that forces HTTPS is enough to start the loop. Both settings are reasonable, and neither one breaks anything by itself. Toggling one setting and testing from a path that bypasses the CDN looks like a fix while every real visitor still loops.
The mechanism: two ends, one loop
The CDN's SSL mode was set to "Flexible": the browser talks HTTPS to the CDN, but the CDN talks plain HTTP to the origin. A defensible setting on its own. Plenty of origins serve HTTP behind a CDN that terminates TLS.
The origin's edge, meanwhile, force-redirected every HTTP request to HTTPS, without being proxy-aware: it issued the redirect without checking the header that says this request was already HTTPS at the front door. So the CDN fetches over HTTP, the origin answers go to HTTPS, the browser's next request arrives at the CDN as HTTPS, the CDN fetches the origin over HTTP again, and the origin redirects again. Infinite, by construction. Flexible alone is fine. Force-redirect alone is fine. Only the two together loop.
The bug that logged nothing
If the tier that answers the redirect does not log routine requests, the loop leaves nothing in the access log. Silence looks like no traffic arrived, and the investigation goes everywhere except the right place. The rule: when a bug leaves no logs, stop hunting the silence and reproduce the mechanism.
Reproduce the mechanism
$ curl -I -H 'X-Forwarded-Proto: https' http://origin.example/
HTTP/1.1 301 Moved Permanently
Location: https://origin.example/
# told the origin the request was already HTTPS. it redirects anyway.One request reproduces the loop, from the path visitors take. A test from any other path passes and proves nothing.
Fix both ends
| THE END | THE FIX |
|---|---|
| The CDN side | SSL mode moved to "Full (Strict)": the CDN speaks real, verified HTTPS to the origin. |
| EITHER FIX BREAKS THE LOOP. BOTH MAKE IT IMPOSSIBLE.The origin side | The redirect made proxy-aware: it checks the forwarded-protocol header and never bounces a request that was already HTTPS at the front door. |
Fixing one end of a two-end incompatibility leaves a loaded configuration waiting for the next change. Close both ends and no combination is left that circles: pause the CDN, swap the CDN, change the origin, and the loop has nowhere to form again.
“Neither end was broken. The two of them together were.”
Straight answers
How do I fix ERR_TOO_MANY_REDIRECTS behind a CDN?+
Check the pair, not one setting. If the CDN fetches your origin over plain HTTP (a "Flexible"-style SSL mode) and your origin force-redirects HTTP to HTTPS, they loop. Move the CDN to full, strict HTTPS to the origin, and make the origin's redirect proxy-aware.
Why does my redirect loop show nothing in the access logs?+
The tier that loops may not log routine requests, so the loop is invisible. Do not hunt the silence. Reproduce the mechanism with one request against the origin and read what it does.
What does X-Forwarded-Proto do?+
A proxy sets it to tell the origin what protocol the visitor actually used. An origin that redirects HTTP to HTTPS must check it, otherwise it bounces requests that were already HTTPS at the proxy, which is how loops start.
Is Flexible SSL mode bad?+
It is a trade with a sharp edge: traffic between CDN and origin is unencrypted, and combined with an origin force-redirect it loops. Full, strict mode, with a real certificate on the origin, removes both problems.
Why did it work when I tested it?+
A test that does not pass through the CDN follows a different path than your visitors. Reproduce along the exact path that fails, headers included. That difference is where this class of bug hides.
Fighting a bug that logs nothing?
Silence is a symptom too. We reproduce the failure, read the primary sources, and fix both ends.
Talk to an engineerYou’ve reached the end.
Put the reading to work
What are
you running?
Tell us about the workload, traffic and recovery requirements. Start with the server builder, or talk through the details with an engineer.
Written by the engineers who build and run the infrastructure it describes.Talk to an engineer