A web application sits behind a reverse proxy that terminates TLS and forwards to the app over plain HTTP. Every HTTPS request now ends in an endless redirect loop: the app believes the scheme is http, redirects to https, and the next request reaches it as http again. What did the proxy hide from the app, and what has to change on each hop?

## What actually happened A reverse proxy does not hand your application the client's connection. It terminates that connection — TLS and all — and opens its own connection to the backend. If that second connection is plain HTTP, then plain HTTP is the truth of the request as far as the application's socket is concerned. There is no hidden channel that tells it otherwise. So the app's usual rule — *if the request is not secure, redirect to the https URL* — is behaving exactly as written. The browser obeys the redirect, connects over HTTPS, the proxy terminates TLS again, forwards plain HTTP again, and the app redirects again. Browsers cut this off after a fixed number of hops and show a "too many redirects" error, which is the symptom users report. ## Confirming it rather than guessing Two requests separate the layers. Ask the edge, then ask the backend directly, and compare the `Location` each returns: ```bash curl -sSI https://app.example.com/dashboard | grep -i '^location' curl -sSI http://10.0.0.12:8080/dashboard | grep -i '^location' ``` If the backend redirects to `https://...` when called over plain HTTP, you have reproduced the loop in isolation and know the app's rule is the actor. Then repeat the direct call while asserting the forwarded scheme: ```bash curl -sSI -H 'X-Forwarded-Proto: https' http://10.0.0.12:8080/dashboard | grep -i '^location' ``` If the redirect disappears, the app already understands the header and the proxy simply is not sending it. If the redirect persists, the app is not configured to honour forwarded headers at all. That one test tells you which hop to change, and it takes seconds. ## The fix on the proxy The edge is the only place that knows the original scheme, so it has to say so explicitly, conventionally with `X-Forwarded-Proto` (alongside `X-Forwarded-For` for the address and `X-Forwarded-Host` where the app builds absolute URLs). The critical detail is that the edge must **set** these values, not append to or pass through whatever arrived from the client. Everything the client sent for those fields is a claim by an untrusted party; at the trust boundary it must be replaced. ## The fix on the application The app must stop asking the socket and start asking the forwarded values — for the scheme, and usually for the host and client address too. Most web frameworks and servers have an explicit forwarded-headers mode for exactly this, and it is off or restricted by default *on purpose*. It must also be told **which peers are allowed to make that claim**: the proxy's addresses, or the internal network the proxy sits on. This is the half that candidates skip, and it is the half that matters. ## Why blanket trust is dangerous If the app honours `X-Forwarded-Proto: https` from any source, then any party who can open a connection to the backend directly — another workload in the same network, something that found the pod or instance port, an SSRF chain inside your own estate — can assert that its request already arrived securely. That defeats force-https redirects, any "secure transport only" gate, and any audit that records how a request arrived. The same reasoning applies with more force to a forwarded client address, where a spoofed value bypasses address allowlists and per-client rate limits and poisons abuse attribution. The rule that survives every product: **overwrite at the trust boundary, trust only from the hop you operate, and make the backend unreachable except through that hop.** ## Everything else that breaks the same way Once you see the loop as *the proxy hid a property of connection one*, the rest of the family is predictable: - Absolute URLs generated by the app — password-reset links, canonical tags, pagination links — come out as `http://` or carry the backend's internal port. - Cookies marked `Secure` are set on what the app thinks is a plain connection, and logic gated on "is this request secure" takes the wrong branch. - Pages load over HTTPS but pull sub-resources over `http://`, so the browser blocks them as mixed content. - Application logs and any per-client limiting show the proxy's address for every request. - Anything keyed on the protocol version or on a client certificate is likewise invisible unless deliberately forwarded. ## What a strong answer sounds like Name the two-connection model as the cause, not "a misconfiguration". Show the two-curl isolation. Give the fix on both hops. Then, unprompted, state the trust boundary — that the edge overwrites and the app trusts only its own proxy — because the interviewer's next question is otherwise "and what if a client sends that header itself?"