X-Forwarded-ProtoX-Forwarded-Proto (XFP) is the de facto header that conveys the original scheme (`http` or `https`) the client used to reach the proxy to the backend. It corresponds to the Forwarded standard's `proto` parameter.
In the common setup where TLS termination happens at the proxy or load balancer, the internal connection to the backend is plain HTTP, but this header tells the backend the user's actual connection was HTTPS.
When a CDN or load balancer handles HTTPS and talks HTTP to the backend, the request looks like `http` to the backend. To let the app decide redirects, the cookie Secure flag, or canonical URLs on its own, it needs the original scheme, and XFP supplies it. A value of `https` means the client connected over HTTPS.
Getting this wrong classically produces an infinite redirect loop. If the backend has an 'if HTTP, redirect to HTTPS' rule but ignores XFP, it keeps mistaking an already-HTTPS request for `http` and loops. You must feed XFP into your framework's 'HTTPS awareness' setting.
This value is spoofable too, so don't trust XFP from outside the trust boundary. An attacker can forge `X-Forwarded-Proto: https` to bypass a security check (e.g. 'issue cookies only over HTTPS'), so use only the value set by a trusted proxy and reset externally supplied XFP at the outermost hop. Be especially careful if HSTS or Secure-cookie decisions depend on it.
X-Forwarded-Proto: <scheme>e.g. X-Forwarded-Proto: https