[GH-ISSUE #34] [NOOB] Redirecting to proxy host with SSL

kerem commented

2026-02-26 05:33:16 +03:00

Owner

Originally created by @Daxx13 on GitHub (Dec 12, 2018).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/34

Hi,

First of all, sorry because is very possible that I misunderstood something or I'm doing something wrong.

The problem is I have some apps that runs only over SSL-enabled connections, so I need to reverse proxy to a SSL server but I can't find a way in the WebUI for this, this is the scenario:

User <----> (Signed SSL) Proxy <----> (Self-signed SSL) Server

The problem comes when in the UI I can type a server and port, but no the protocol (HTTP/HTTPS). Inside the app container, I can see in /etc/nginx/conf.d/include/proxy.conf the following variable filling:

proxy_pass http://$server:$port;

So I think this is ready to enter only the IP and HTTP port in the WebUI, witch fills this variables in the proxy config, but in anyway this will be http://[whatever]

The workarround for us is delete the http:// in this file, and fill the server input with the protocol (http://[whatever] or https://[whatever]) in the Web UI. This workarround worked like a charm.

SO

Is possible to add a dropdown just at the left of server imput field in "New Proxy Host" modal, to pick the protocol, and fill the variables in this way?

proxy_pass $protocol://$server:$port;

Many thanks,

Aitor.

Originally created by @Daxx13 on GitHub (Dec 12, 2018). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/34 Hi, First of all, sorry because is very possible that I misunderstood something or I'm doing something wrong. The problem is I have some apps that runs only over SSL-enabled connections, so I need to reverse proxy to a SSL server but I can't find a way in the WebUI for this, this is the scenario: `User <----> (Signed SSL) Proxy <----> (Self-signed SSL) Server` The problem comes when in the UI I can type a server and port, but no the protocol (HTTP/HTTPS). Inside the app container, I can see in `/etc/nginx/conf.d/include/proxy.conf` the following variable filling: `proxy_pass http://$server:$port;` So I think this is ready to enter only the IP and HTTP port in the WebUI, witch fills this variables in the proxy config, but in anyway this will be `http://[whatever]` The workarround for us is delete the `http://` in this file, and fill the `server` input with the protocol (`http://[whatever]` or `https://[whatever]`) in the Web UI. This workarround worked like a charm. **SO** Is possible to add a dropdown just at the left of server imput field in "New Proxy Host" modal, to pick the protocol, and fill the variables in this way? `proxy_pass $protocol://$server:$port;` Many thanks, Aitor.

kerem

2026-02-26 05:33:16 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-26 05:33:18 +03:00

Author

Owner

@jc21 commented on GitHub (Dec 12, 2018):

Yep it's certainly a possible improvement. I've found myself wanting this in one scenario before as well. Just need to be careful when the upstream server is another http proxy that expects the destination hostname to be supplied and that might be different from the source hostname. Some testing scenarios would need to be considered.

In the meantime, if you want to hack things right now to get moving, find the specific nginx conf file in your data directory for the host you've set up, edit it and look at the location / { block. There will be a line that is:

  include conf.d/include/proxy.conf;

Replace that line with the following:

  add_header       X-Served-By $host;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-Scheme $scheme;
  proxy_set_header X-Forwarded-Proto  $scheme;
  proxy_set_header X-Forwarded-For    $remote_addr;
  proxy_pass https://$server:$port;

Save the file, then restart the docker container and it will pick up those changes. However, if you make changes to that proxy host inside Nginx Proxy Manager interface, it will overwrite your custom changes, so be careful there.

@jc21 commented on GitHub (Dec 12, 2018): Yep it's certainly a possible improvement. I've found myself wanting this in one scenario before as well. Just need to be careful when the upstream server is another http proxy that expects the destination hostname to be supplied and that might be different from the source hostname. Some testing scenarios would need to be considered. In the meantime, if you want to hack things right now to get moving, find the specific nginx conf file in your data directory for the host you've set up, edit it and look at the `location / {` block. There will be a line that is: ``` include conf.d/include/proxy.conf; ``` Replace that line with the following: ``` add_header X-Served-By $host; proxy_set_header Host $host; proxy_set_header X-Forwarded-Scheme $scheme; proxy_set_header X-Forwarded-Proto $scheme; proxy_set_header X-Forwarded-For $remote_addr; proxy_pass https://$server:$port; ``` Save the file, then restart the docker container and it will pick up those changes. However, if you make changes to that proxy host inside Nginx Proxy Manager interface, it will overwrite your custom changes, so be careful there.

kerem commented

2026-02-26 05:33:18 +03:00

Author

Owner

@Daxx13 commented on GitHub (Dec 13, 2018):

  include conf.d/include/proxy.conf;

Replace that line with the following:

  add_header       X-Served-By $host;
  proxy_set_header Host $host;
  proxy_set_header X-Forwarded-Scheme $scheme;
  proxy_set_header X-Forwarded-Proto  $scheme;
  proxy_set_header X-Forwarded-For    $remote_addr;
  proxy_pass https://$server:$port;

Thanks for this workarround.

What needs to be tested? Maybe I can help here! About https:// I can say It works for IP address proxyed servers on SSL enabled ports with the workarround. I'll try to proxy to a named server but It should work while the proxy can resolve the DNS. I think this should not be related to the protocol anyway.

Thanks,

Aitor.

@Daxx13 commented on GitHub (Dec 13, 2018): > ``` > include conf.d/include/proxy.conf; > ``` > Replace that line with the following: > > ``` > add_header X-Served-By $host; > proxy_set_header Host $host; > proxy_set_header X-Forwarded-Scheme $scheme; > proxy_set_header X-Forwarded-Proto $scheme; > proxy_set_header X-Forwarded-For $remote_addr; > proxy_pass https://$server:$port; > ``` Thanks for this workarround. What needs to be tested? Maybe I can help here! About `https://` I can say It works for IP address proxyed servers on SSL enabled ports with the workarround. I'll try to proxy to a named server but It should work while the proxy can resolve the DNS. I think this should not be related to the protocol anyway. Thanks, Aitor.

kerem commented

2026-02-26 05:33:18 +03:00

Author

Owner

@jc21 commented on GitHub (Dec 13, 2018):

Yeah so I was more thinking the following scenario:

Edge proxy running NPM             Internal https server
https://myserver.com       =>      https://otherserver.com

NPM will resolve and find otherserver.com via dns, but when it hits that upstream web server in this scenario, the server is running multiple SSL sites on the same web server and differentiating them by the hostname (SNI).

With the workaround code above, when you hit https://myserver.com in your browser, it will send through the Host header as myserver.com to the upstream server when in fact it is expecting otherserver.com to be the host header value. While that is easy to code for in this application by changing the Host header to the upstream server name, it introduces a new problem where the upstream web application might be using fixed URLs in it's content instead of relative ones. So, you request https://myserver.com, the HTML returned has a link to https://otherserver.com because it doesn't know it's behind a reverse proxy.

Nginx can rewrite the html response before returning it to the user to replace these paths using LUA scripts, but I don't feel that brave yet..
Not sure how common this is going to be, so I'm not going to code for it yet. Just going to get the minimal viable product working for your particular problem

@jc21 commented on GitHub (Dec 13, 2018): Yeah so I was more thinking the following scenario: ``` Edge proxy running NPM Internal https server https://myserver.com => https://otherserver.com ``` NPM will resolve and find `otherserver.com` via dns, but when it hits that upstream web server in this scenario, the server is running multiple SSL sites on the same web server and differentiating them by the hostname (SNI). With the workaround code above, when you hit `https://myserver.com` in your browser, it will send through the `Host` header as `myserver.com` to the upstream server when in fact it is expecting `otherserver.com` to be the host header value. While that is easy to code for in this application by changing the `Host` header to the upstream server name, it introduces a new problem where the upstream web application _might_ be using fixed URLs in it's content instead of relative ones. So, you request `https://myserver.com`, the HTML returned has a link to `https://otherserver.com` because it doesn't know it's behind a reverse proxy. 1. Nginx _can_ rewrite the html response before returning it to the user to replace these paths using LUA scripts, but I don't feel that brave yet.. 2. Not sure how common this is going to be, so I'm not going to code for it yet. Just going to get the minimal viable product working for your particular problem

kerem commented

2026-02-26 05:33:18 +03:00

Author

Owner

@jc21 commented on GitHub (Dec 13, 2018):

I've pushed this https upstream proxy support to the jc21/nginx-proxy-manager:develop docker tag. Give it a try and see if it does what you need.

@jc21 commented on GitHub (Dec 13, 2018): I've pushed this https upstream proxy support to the `jc21/nginx-proxy-manager:develop` docker tag. Give it a try and see if it does what you need.

kerem commented

2026-02-26 05:33:18 +03:00

Author

Owner

@Daxx13 commented on GitHub (Dec 20, 2018):

Hi!

First of all, thanks for the great explaination, you're totally right.

I've tested the dev branch and worked as expected with no vhosts on real servers, or when you're asking for a domain the real server can handle with root or vhost. I can see some issues when you're asking for a domain the real server don't know and you're forwarding to an IP address, but i should test this a bit more.

After all the HTTPS proxy hosts are working. Thanks!

Aitor.

@Daxx13 commented on GitHub (Dec 20, 2018): Hi! First of all, thanks for the great explaination, you're totally right. I've tested the dev branch and worked as expected with no vhosts on real servers, or when you're asking for a domain the real server can handle with root or vhost. I can see some issues when you're asking for a domain the real server don't know and you're forwarding to an IP address, but i should test this a bit more. After all the HTTPS proxy hosts are working. Thanks! Aitor.

kerem commented

2026-02-26 05:33:18 +03:00

Author

Owner

@SaulGoodman1337 commented on GitHub (Dec 21, 2018):

Perfect. just wanted to open a feature request and then I came across this one. works perfectly, thanks a lot !

@SaulGoodman1337 commented on GitHub (Dec 21, 2018): Perfect. just wanted to open a feature request and then I came across this one. works perfectly, thanks a lot !

kerem commented

2026-02-26 05:33:19 +03:00

Author

Owner

@jlesage commented on GitHub (Dec 21, 2018):

HTTPs upstream proxy support is a really good feature that covers a common scenario. Thanks! I hope this will be merged in an official release.

@jlesage commented on GitHub (Dec 21, 2018): HTTPs upstream proxy support is a really good feature that covers a common scenario. Thanks! I hope this will be merged in an official release.

kerem commented

2026-02-26 05:33:19 +03:00

Author

Owner

@mackcoding commented on GitHub (Jan 1, 2019):

Looking forward to this feature as well!

@mackcoding commented on GitHub (Jan 1, 2019): Looking forward to this feature as well!

kerem commented

2026-02-26 05:33:19 +03:00

Author

Owner

@jc21 commented on GitHub (Jan 3, 2019):

Added in v2.0.7

@jc21 commented on GitHub (Jan 3, 2019): Added in v2.0.7

kerem commented

2026-02-26 05:33:19 +03:00

Author

Owner

@jlesage commented on GitHub (Jan 3, 2019):

Thank you very much!

@jlesage commented on GitHub (Jan 3, 2019): Thank you very much!

Rows
Columns

[GH-ISSUE #34] [NOOB] Redirecting to proxy host with SSL #33