Secure cookies and redirects break behind TLS-terminating proxy, forwarded-header support plugin

A Ktor server deployed behind a TLS-terminating reverse proxy may see inbound requests as plain HTTP. Features that depend on the original client-facing scheme and host, such as secure cookies and absolute redirects, can behave differently from local direct testing where no proxy rewrites the connection.

The forwarded-header support plugin is the documented component for reconstructing origin information from X-Forwarded-* or RFC 7239 Forwarded headers. Ktor does not enable trust for these headers by default because unvalidated headers can be spoofed by clients that bypass the proxy.

The decision point is how to opt in safely, given differences in proxy header names and the need to restrict trust to known proxy addresses. Plugin names and configuration properties vary across Ktor major versions.

Which configuration options control which forwarded headers are accepted and how trust is restricted to known proxy addresses? What is the expected behavior for request origin scheme and host when forwarded headers are ignored? How do differences between X-Forwarded-Proto, X-Forwarded-Host and the Forwarded header affect configuration?