so we've got an nginx and two servers in play. The first one's acting as a reverse proxy, forwarding requests to the second, which then communicates with internal resources. The magic happens in this 'location' block:

location / {
    include proxy_params;
    proxy_pass http://192.128.50.101:80;
}

Now, buried in that 'include' is the standard:

proxy_set_header X-Forwarded-Proto $scheme;

But here's the kicker - when we're accessing the main server via HTTPS, it's somehow getting downgraded to HTTP by the time it reaches the real servers. That's right, the X-Forwarded-Proto header isn't making the journey, it's getting stuck at the previous request. The million-dollar question is, can we somehow preserve the initial protocol, the one the user originally connected with, as it travels down the proxy chain?

Option 1: Upgrade Nginx
Ensure your Nginx version is up-to-date. Older versions might not pass the X-Forwarded-Proto header correctly. Upgrade to the latest stable release and retry.

Option 2: Use X-Forwarded-For
Instead of relying on X-Forwarded-Proto, use X-Forwarded-For to preserve client's original IP. This might not solve your HTTPS issue, but it's a good practice for debugging.

Option 3: SSL Termination
If the downgrade happens due to SSL termination at the reverse proxy, consider moving SSL termination to the second server. This way, the original protocol is preserved.

Option 4: Custom Header
Create a custom header in your reverse proxy configuration to pass the protocol. For example, proxy_set_header X-Custom-Proto $scheme;. Then, in your second server, read this custom header instead of X-Forwarded-Proto.

Here's a setup:

proxy_set_header X-Forwarded-Proto $http_actual_proto;

where 'actual_proto' is what X-Forwarded-Proto looks like in the request.

When you set up a reverse proxy using the directive proxy_pass http://192.148.50.101:80;, you're essentially routing incoming requests to that specified IP address and port. The first Nginx instance will handle the request and forward it to the second one.

Now, when the second Nginx server processes the request, it will recognize the protocol being used as HTTP, which you can verify through the $scheme variable. However, to ensure proper protocol forwarding, you need to manipulate the X-Forwarded-Proto header. Instead of using the $scheme variable, which might not accurately reflect the original protocol, you should utilize $http_x_forwarded_proto. This way, the second server will get the correct context about how the initial request was made, allowing it to handle the request appropriately.