When NethSecurity terminates SSL/TLS in front of a plain-HTTP backend (e.g. Apache/Virtualmin, Nginx, PHP applications), the backend has no way to know the original request was HTTPS. CMS platforms like WordPress determine the protocol via $_SERVER['HTTPS'], and without X-Forwarded-Proto being forwarded, they can enter infinite HTTPS redirect loops — a default behavior for WordPress and many other CMS/frameworks. This currently forces admins to work around it via CLI/UCI on every affected domain.
Proposed solution
Allow the reverse proxy GUI to forward custom HTTP headers to the backend, either as:
- a generic, repeatable key/value list of custom headers, or
- at minimum, a one-click toggle to forward
X-Forwarded-Proto, since this is the most common need for SSL-terminating setups in front of application backends
Additional context
ns-api 3.7.1
When NethSecurity terminates SSL/TLS in front of a plain-HTTP backend (e.g. Apache/Virtualmin, Nginx, PHP applications), the backend has no way to know the original request was HTTPS. CMS platforms like WordPress determine the protocol via
$_SERVER['HTTPS'], and withoutX-Forwarded-Protobeing forwarded, they can enter infinite HTTPS redirect loops — a default behavior for WordPress and many other CMS/frameworks. This currently forces admins to work around it via CLI/UCI on every affected domain.Proposed solution
Allow the reverse proxy GUI to forward custom HTTP headers to the backend, either as:
X-Forwarded-Proto, since this is the most common need for SSL-terminating setups in front of application backendsAdditional context
ns-api 3.7.1