The redirect loop isn't always in Nginx

A browser says "too many redirects." The Nginx rule looks innocent:

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

For a direct HTTP request, that rule does what it says. The odd part starts when a proxy sits in front of it.

Take Cloudflare's Flexible encryption mode. The browser speaks HTTPS to Cloudflare, but Cloudflare speaks HTTP to the origin. Nginx sees HTTP and sends the browser back to HTTPS. The browser is already there. The next request reaches the origin over HTTP again, and the cycle repeats.

The 301 isn't necessarily wrong. It is making a decision with only one hop of the journey in view.

That distinction matters when debugging. A redirect response tells you where the request was sent next, not which layer decided it should move. Edge rules, the origin's Nginx config, another reverse proxy, and the app can each issue a redirect. A browser error compresses all of them into the same message.

Cloudflare documents this specific Flexible-mode loop and says Full or Full (strict) requires TLS at the origin. A different setup can loop the other way: an HTTPS request reaches an origin that redirects it back to HTTP. Changing the Nginx rule without identifying the hop can just move the loop.

The useful question isn't "which redirect directive should I paste?" It's "what scheme did each layer receive, and which layer returned this Location header?" Once that is visible, the fix is usually much less mysterious.

I wrote more about the basic Nginx HTTP-to-HTTPS setup in the original post. The loop is a reminder that a correct rule can still be wrong for the path a request actually took.