[GH-ISSUE #1028] When Redirecting to Folder Path, Force SSL Setting is Ignored

kerem commented

2026-02-26 06:34:43 +03:00

Owner

Originally created by @dgsharpe on GitHub (Apr 19, 2021).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/1028

Background

I have an existing web server which serves applications at folder paths - for example, http://192.168.1.105/something, http://192.168.1.105/differentthing . I would like to use Nginx Proxy Manager to point a subdomain directly to these paths, i.e. https://something.mywebsite.com --> http://192.168.1.105/something (without having to go to something.mywebsite.com/something). The ability to do this was discussed and implemented on issue #104 , with these steps provided by @jc21 :

Create a proxy host

On the details tab, enter any ip address and port, it's required for the form but it won't actually be used, so it can be anything

On the Custom Locations tab, create a location with / as the location path and for the Forward Hostname / IP enter 192.168.0.10/phpmyadmin/ making sure you have that trailing slash, it's important.

Save, and test.

The Problem

When you actually do this, something.mywebsite.com will respond on http (port 80), even if you configure an SSL certificate and enable the "Force SSL" setting. It should instead respect the setting, and not respond on unencrypted http when the setting is enabled.

Reproduction

Simply set up a configuration like the one described above, and enable the Force SSL setting (screenshots also provided below). This bug was also reported in #104 by @gmag11 and @meichthys, so I'm confident that it isn't just me.

Screenshots (actual domain and path redacted, and even though you can't see it in the screenshot, I promise you I didn't forget the trailing slash in the Forward Hostname / IP box)

Originally created by @dgsharpe on GitHub (Apr 19, 2021). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/1028 **Background** I have an existing web server which serves applications at folder paths - for example, http://192.168.1.105/something, http://192.168.1.105/differentthing . I would like to use Nginx Proxy Manager to point a subdomain directly to these paths, i.e. https://something.mywebsite.com --> http://192.168.1.105/something (without having to go to something.mywebsite.com/something). The ability to do this was discussed and implemented on issue #104 , with these steps provided by @jc21 : > 1. Create a proxy host >2. On the details tab, enter any ip address and port, it's required for the form but it won't actually be used, so it can be anything >3. On the Custom Locations tab, create a location with `/` as the location path and for the **Forward Hostname / IP** enter `192.168.0.10/phpmyadmin/` making sure you have that trailing slash, it's important. >4. Save, and test. **The Problem** When you actually do this, something.mywebsite.com will respond on http (port 80), even if you configure an SSL certificate and enable the "Force SSL" setting. It should instead respect the setting, and not respond on unencrypted http when the setting is enabled. **Reproduction** Simply set up a configuration like the one described above, and enable the Force SSL setting (screenshots also provided below). This bug was also reported in #104 by @gmag11 and @meichthys, so I'm confident that it isn't just me. **Screenshots (actual domain and path redacted, and even though you can't see it in the screenshot, I promise you I didn't forget the trailing slash in the Forward Hostname / IP box)** <img width="492" alt="1" src="https://user-images.githubusercontent.com/6392530/115168198-11d37800-a088-11eb-9898-615d1f103179.png"> <img width="492" alt="2" src="https://user-images.githubusercontent.com/6392530/115168202-139d3b80-a088-11eb-8940-63654d2be4a3.png"> <img width="492" alt="3" src="https://user-images.githubusercontent.com/6392530/115168205-15ff9580-a088-11eb-9567-e46a421291e6.png">

kerem

2026-02-26 06:34:43 +03:00

closed this issue
added the
stale

bug
labels

kerem commented

2026-02-26 06:34:44 +03:00

Author

Owner

@meichthys commented on GitHub (Apr 19, 2021):

I can confirm that I am also able to access my proxy host using port 80 in a scenario like this even when Force SSL is enabled.

@meichthys commented on GitHub (Apr 19, 2021): I can confirm that I am also able to access my proxy host using port 80 in a scenario like this even when `Force SSL` is enabled.

kerem commented

2026-02-26 06:34:44 +03:00

Author

Owner

@N1co93 commented on GitHub (Apr 19, 2021):

I think this is an old issue, I read about it on github some times ago.

There is currently a workaround available you can add this line to the "custom location".

include conf.d/include/force-ssl.conf;

I think #1017 will resolve this problem.

@N1co93 commented on GitHub (Apr 19, 2021): I think this is an old issue, I read about it on github some times ago. There is currently a workaround available you can add this line to the "custom location". `include conf.d/include/force-ssl.conf;` ![image](https://user-images.githubusercontent.com/59510296/115263047-5ff28500-a135-11eb-9bfa-8b787c6a319c.png) I think #1017 will resolve this problem.

kerem commented

2026-02-26 06:34:44 +03:00

Author

Owner

@3Dscrewer commented on GitHub (Apr 20, 2021):

Sorry, English is not my native language.
So, to make things more clear to me.
You have two sites like /var/www/something/ and /var/www/different/

nginx is listening at port 80 and 443. Even if you’re routing to an internal site using SSL, you can use every port you like.

So you have to setup site something to listen for example at port 8000 and site different at port 8001

Then the setup in npm is custom path /something and the second /different and not only / (may be you need the full path i.e /var/www/something/)
In that case you might see that the SSL is broken by example, pictures or/and fonts.googleapis are not save. That is a problem because the site is not forwarding the header correctly, or it is using external sites. That is not a nginx fault. You can fix by add_header Content-Security-Policy (see example) and a following list. Sometimes a simple server.use-forward-headers=true is fixing.

example

add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' www.gstatic.com; img-src 'self' *.akamaized.net; style-src 'self' 'unsafe-inline' fonts.googleapis.com; font-src 'self' fonts.gstatic.com; frame-src 'self'; object-src 'none'";

Last Edit :) There might be another situation like my. I’m using by security reasons a stand alone proxy server (a raspberry 4 is still oversized) and my sites running at different machines. In that case you don’t need a custom path at all. Only IP:Port :-)

Absolute last Edit: I don’t know what your sites are doing, but have a look at the config files.
There might be a context_path with a # in front i.e context_path= /something if that exists and you will remove that sign in front you also don’t need the custom path in npm

@3Dscrewer commented on GitHub (Apr 20, 2021): Sorry, English is not my native language. So, to make things more clear to me. You have two sites like /var/www/something/ and /var/www/different/ nginx is listening at port 80 and 443. Even if you’re routing to an internal site using SSL, you can use every port you like. So you have to setup site something to listen for example at port 8000 and site different at port 8001 Then the setup in npm is custom path /something and the second /different and not only / (may be you need the full path i.e /var/www/something/) In that case you might see that the SSL is broken by example, pictures or/and fonts.googleapis are not save. That is a problem because the site is not forwarding the header correctly, or it is using external sites. That is not a nginx fault. You can fix by add_header Content-Security-Policy (see example) and a following list. Sometimes a simple `server.use-forward-headers=true` is fixing. example `add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' www.gstatic.com; img-src 'self' *.akamaized.net; style-src 'self' 'unsafe-inline' fonts.googleapis.com; font-src 'self' fonts.gstatic.com; frame-src 'self'; object-src 'none'";` Last Edit :) There might be another situation like my. I’m using by security reasons a stand alone proxy server (a raspberry 4 is still oversized) and my sites running at different machines. In that case you don’t need a custom path at all. Only IP:Port :-) Absolute last Edit: I don’t know what your sites are doing, but have a look at the config files. There might be a context_path with a # in front i.e context_path= /something if that exists and you will remove that sign in front you also don’t need the custom path in npm

kerem commented

2026-02-26 06:34:44 +03:00

Author

Owner

@dgsharpe commented on GitHub (Apr 20, 2021):

I can confirm that the workaround provided by @N1c093 works for me. However, since the workaround shouldn't be necessary and this issue can create a security vulnerability, I think the ticket should remain "open" until the Force SSL toggle works as intended in this scenario.

@dgsharpe commented on GitHub (Apr 20, 2021): I can confirm that the workaround provided by @N1c093 works for me. However, since the workaround shouldn't be necessary and this issue can create a security vulnerability, I think the ticket should remain "open" until the Force SSL toggle works as intended in this scenario.

kerem commented

2026-02-26 06:34:44 +03:00

Author

Owner

@3Dscrewer commented on GitHub (Apr 20, 2021):

@dgsharpe In my opinion it is not an issue. It’s a wrong setup and misunderstanding.
The SSL certificate is dropped at nginx and not your site. If you’re forwarding port 443 the SSL certificate must be at your site and not at nginx.
Have a look at the pictures. As you can see, cloud and airsonic is the same IP, ldap is for a future project I have just disabled. They are all SSL even if airsonic is forwarded as http. If you don’t believe, ask by PM for the links and try by your self.
Airsonic was before used as custom path /airsonic, but then I found, as mentioned above, the context_path. Since that time I don’t need the custom path. BTW also HSTS is working.

@3Dscrewer commented on GitHub (Apr 20, 2021): @dgsharpe In my opinion it is not an issue. It’s a wrong setup and misunderstanding. The SSL certificate is dropped at nginx and not your site. If you’re forwarding port 443 the SSL certificate must be at your site and not at nginx. Have a look at the pictures. As you can see, cloud and airsonic is the same IP, ldap is for a future project I have just disabled. They are all SSL even if airsonic is forwarded as http. If you don’t believe, ask by PM for the links and try by your self. Airsonic was before used as custom path /airsonic, but then I found, as mentioned above, the context_path. Since that time I don’t need the custom path. BTW also HSTS is working. ![4DF4606B-DF73-4AD0-B6F7-EE70F0DEB839](https://user-images.githubusercontent.com/34925249/115417509-f63baf00-a1f8-11eb-841d-5fdb9d0db312.jpeg) ![268E12D9-B793-482F-B44B-EE42495DFA4C](https://user-images.githubusercontent.com/34925249/115417519-f89e0900-a1f8-11eb-9a30-8cbd58f1e72e.jpeg) ![C508523F-8EF8-4730-A847-745F0CD9DA69](https://user-images.githubusercontent.com/34925249/115417521-f9369f80-a1f8-11eb-8a99-9964bb2ca9bc.jpeg) ![A9352279-C09E-48E2-82CB-52854014E1B6](https://user-images.githubusercontent.com/34925249/115417523-f9cf3600-a1f8-11eb-852d-88abcf60c5ab.jpeg)

kerem commented

2026-02-26 06:34:44 +03:00

Author

Owner

@dgsharpe commented on GitHub (Apr 20, 2021):

I think I understand the point you're making, @3Dscrewer , but this is a "human factors" issue if nothing else. Most users will expect that the "Force SSL" setting will force SSL unconditionally in all scenarios. If it doesn't, that's unexpected and frustrating. Unexpected and unintuitive behavior is as much a bug as anything else.

The setting should either be made to work in all scenarios, or the UI should change so that users won't be surprised. For example, there could be a link to an explanation of the toggle's actual capabilities, or, if the proxy host is configured as I described above, the toggle could be grayed out. There are any number of possible solutions, but the bottom line is that for this particular scenario, the toggle is not functioning as most users would expect and therefore something should change.

@dgsharpe commented on GitHub (Apr 20, 2021): I think I understand the point you're making, @3Dscrewer , but this is a "human factors" issue if nothing else. Most users will expect that the "Force SSL" setting will force SSL unconditionally in all scenarios. If it doesn't, that's unexpected and frustrating. Unexpected and unintuitive behavior is as much a bug as anything else. The setting should either be made to work in all scenarios, or the UI should change so that users won't be surprised. For example, there could be a link to an explanation of the toggle's actual capabilities, or, if the proxy host is configured as I described above, the toggle could be grayed out. There are any number of possible solutions, but the bottom line is that for this particular scenario, the toggle is not functioning as most users would expect and therefore something should change.

kerem commented

2026-02-26 06:34:44 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Mar 13, 2024):

Issue is now considered stale. If you want to keep it open, please comment 👍

@github-actions[bot] commented on GitHub (Mar 13, 2024): Issue is now considered stale. If you want to keep it open, please comment :+1:

kerem commented

2026-02-26 06:34:44 +03:00

Author

Owner

@github-actions[bot] commented on GitHub (Apr 25, 2025):

Issue was closed due to inactivity.

@github-actions[bot] commented on GitHub (Apr 25, 2025): Issue was closed due to inactivity.

Rows
Columns

[GH-ISSUE #1028] When Redirecting to Folder Path, Force SSL Setting is Ignored #863