Force SSL's redirection was activated when forwarding requests from another npm instance which already handled ssl staffs

[jerry-yuan]

Is your feature request related to a problem? Please describe.
I have a relatively complex reverse proxy topology that involves multiple Nginx Proxy Manager instances. As shown in the diagram, I have two servers—one located on the internal network and the other on the public internet—each hosting several Docker services and using Nginx Proxy Manager for reverse proxying. I have established a tunnel between the two servers to traverse the firewall. To allow public internet access to the internal services, I added the internal Nginx Proxy Manager as an upstream backend server in the public server’s NPM configuration.

However, as illustrated in the diagram below, when I enable Force SSL on both servers, a problem occurs. The public server’s Nginx Proxy Manager uses HTTP to communicate with the internal upstream (since the tunnel is already encrypted, I prefer not to add another layer of SSL encryption). This causes the internal server’s Nginx Proxy Manager, upon receiving the HTTP request, to apply its Force SSL rule and return a 301 redirect to an HTTPS address. Consequently, even though the public client is already accessing the site via HTTPS, it gets redirected to the same HTTPS URL again, triggering a browser ERR_TOO_MANY_REDIRECTS error.

Describe the solution you'd like

I developed a program capable of returning the request headers in response body, and used Nginx Proxy Manager to reverse proxy it. As shown in the screenshot below, I discovered that Nginx Proxy Manager adds the X-Forwarded-Scheme and X-Forwarded-Proto request headers. Furthermore, when a client correctly accesses a virtual host with Force SSL enabled via HTTPS, these headers already indicate that the original request was made over HTTPS.

I modified the newly introduced conf.d/include/force-ssl.conf file, which is applied when Force SSL is enabled. I added a condition to prevent the 301 redirect from being triggered when the upstream X-Forwarded-Proto header is https. The modifications are as follows:

set $test "";
if ($scheme = "http") {
	set $test "H";
}
if ($request_uri = /.well-known/acme-challenge/test-challenge) {
	set $test "${test}T";
}
# Added code begin
if ($http_x_forwarded_proto = "https") {
    set $test "${test}S";
}
# Added code end

if ($test = H) {
	return 301 https://$host$request_uri;
}

After reload nginx, this problem has been resolved.

Describe alternatives you've considered

Under my solution, the two-layer Nginx Proxy Manager proxy configuration works, but it may not be suitable for more layers. This is because I found that the X-Forwarded-Proto header received by deeper layers may be overwritten as http by the preceding Nginx Proxy Manager instance. I believe that if support for multiple Nginx Proxy Manager instances in a forwarding chain is desired, additional handling of the X-Forwarded-Proto and X-Forwarded-Scheme headers may be necessary to ensure that the original protocol used by the client is not lost during multiple forwarding hops.

In addition, I have considered the security implications. Such modifications could potentially cause the Force SSL feature to fail if clients spoof the X-Forwarded-* headers. Therefore, a more thorough design may be necessary.

[jerry-yuan]

It is unfortunate to discover a similar issue: #3365. I have realized that, at their core, both this issue and the referenced one stem from Nginx Proxy Manager being designed with the assumption that it operates as the outermost gateway. May I kindly ask if you currently have any new insights on this topic and whether there are plans to support scenarios where NPM itself acts as a proxied upstream host?@jc21

[jc21]

I encountered this just today, where someone has a Cloudflare Proxy with SSL passing to a forced-HTTPS npm host (not cloudflared as mentioned in #3365). In the case of Cloudflare UI, they don't allow specifying a proxy to a https endpoint :(

Your concept may well work, but it might have to be an opt-in configuration per host. Since this checks supplied headers, which can be spoofed, I don't want to open it up by default.

[jc21]

Actually, I'm changing my mind. I like your implementation across the board.

[jc21]

Please test with this docker image:

nginxproxymanager/nginx-proxy-manager-dev:develop

it works for me

[jerry-yuan]

Please test with this docker image:

nginxproxymanager/nginx-proxy-manager-dev:develop

it works for me

Thank you so much for your response! I'm genuinely surprised and very pleased to see that you've reviewed the concept and even implemented it into the development branch so quickly.

I will test the provided Docker image (nginxproxymanager/nginx-proxy-manager-dev:develop) in my multi-layer proxy setup and report back with my findings.

Thank you again for your support!

[jerry-yuan]

Please test with this docker image:

nginxproxymanager/nginx-proxy-manager-dev:develop

it works for me

I have tested the new image, and overall it is functional and meets my needs for the scenario. However, there are still a couple of issues that might be worth investigating:

1. Security: Would it be possible to add some options on the proxy host configuration page? This could allow control on a per-host basis or based on an allow/deny list for upstream proxy IPs, as you initially mentioned, to better guard against spoofed headers.
2. X-Forwarded-Proto Header Propagation: I continued debugging the chain using my custom HTTP header echo program. When an HTTP request passes through two layers of NPM proxies, the X-Forwarded-Proto header received by the final application (or a deeper proxy instance) reverts back to http. This means the end service or further proxy layers remain unaware that the client originally connected via HTTPS. Potentially, this could cause the redirect loop issue to reappear in setups with more than two proxy layers. I understand that supporting this correctly might require ensuring the X-Forwarded-Proto header is both properly passed through and generated at each stage.

If you do not have the time to develop these features, I would be very happy to contribute this logic to Nginx Proxy Manager myself. However, before proceeding, I would greatly appreciate aligning on a design approach that you approve of. I am ready to follow your guidance regarding the project's development direction.

[jc21]

Ok so my thoughts..

1. In principle, yes this would be ok to add, but in reality, this project's goal is to be simple, so I am always hesitant to add too much or to appease a minority. Any work on this wouldn't come from me as I don't the have time and any contributions would need to be opt-in with well written and explained UI.

2. What is the likelihood that users of this product are going to go through more than 1 https proxy before geting hitting the final npm server? I'd suggest that if the header is not sent correctly along the chain then it's that link's responsibility to address.