starred/nginx-proxy-manager-NginxProxyManager

Fork 0

mirror of https://github.com/NginxProxyManager/nginx-proxy-manager.git synced 2026-04-25 17:35:52 +03:00

[GH-ISSUE #95] Confused by Custom location usage/settings #84

New issue

Closed

opened 2026-02-26 05:34:14 +03:00 by kerem · 6 comments

kerem commented

2026-02-26 05:34:14 +03:00

Owner

Originally created by @binhex on GitHub (Mar 6, 2019).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/95

I see that custom locations has been added to proxy hosts, fantastic!, however im struggling to get my head around the configuration.

so firstly what i want to achieve is to be able to externally access url:-
https://<domain name>/<name of app>

and have it reverse proxy to:-
http(s)://<internal ip address or hostname>:<port number>/<optional sub folder name>

e.g. https://foo.bar.com/plex => http://192.168.1.10:1234/

So at the moment i dont think the 'custom locations' let you do this, correct?.

the other thing i cant quite grasp is the requirement to fill in a 'forward hostname / ip' for both the details AND the custom location(s), surely if you are using custom locations then you shouldnt require a global 'forward hostname / ip' in the 'details' tab, not really sure what should go in there, or why its required, im obviously not thinking about this in the way its been designed, can you tell me how it should work?.

Thanks again for your hard work, i truly appreciate it, this has been something i have wanted for a very long time.

Originally created by @binhex on GitHub (Mar 6, 2019). Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/95 I see that custom locations has been added to proxy hosts, fantastic!, however im struggling to get my head around the configuration. so firstly what i want to achieve is to be able to externally access url:- `https://<domain name>/<name of app>` and have it reverse proxy to:- `http(s)://<internal ip address or hostname>:<port number>/<optional sub folder name>` e.g. `https://foo.bar.com/plex => http://192.168.1.10:1234/` So at the moment i dont think the 'custom locations' let you do this, correct?. the other thing i cant quite grasp is the requirement to fill in a 'forward hostname / ip' for both the details AND the custom location(s), surely if you are using custom locations then you shouldnt require a global 'forward hostname / ip' in the 'details' tab, not really sure what should go in there, or why its required, im obviously not thinking about this in the way its been designed, can you tell me how it should work?. Thanks again for your hard work, i truly appreciate it, this has been something i have wanted for a very long time.

kerem

2026-02-26 05:34:14 +03:00

closed this issue
added the
product-support
label

kerem commented

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

Author

Owner

@jc21 commented on GitHub (Mar 7, 2019):

https://foo.bar.com/plex => http://192.168.1.10:1234/ <- Yep that should work.

The optional sub-folder on the destination server you've suggested, isn't supported yet though.

So yes you need a default forwarding service for a proxy host. If you don't want to forward to anywhere specific, just put in 127.0.0.1 with port 1000 or something random, it won't forward and you have no problems.

I personally don't understand why everyone wants sub-folders at all anyway. For me, plex.example.com is better than example.com/plex.

On the topic of upstream web services, this sub-folder forwarding is an advanced feature. Only people who understand the reverse proxying should attempt it. In my testing with some services I found that the upstream service (ie Plex) returned HTML with assets linking to /styles.css as an example, not /plex/styles.css as you might expect. So the page won't render anything more than HTML. This is because the service has no idea what you're doing in front of it. Some services allow you to specify a "base url" parameter in their configs, but not always.

In my software for example, I assume that the base url of the admin interface is going to be / and I don't have anyway for people to modify that.

@jc21 commented on GitHub (Mar 7, 2019): `https://foo.bar.com/plex => http://192.168.1.10:1234/` <- Yep that should work. The optional sub-folder on the destination server you've suggested, isn't supported yet though. So yes you need a default forwarding service for a proxy host. If you don't want to forward to anywhere specific, just put in `127.0.0.1` with port 1000 or something random, it won't forward and you have no problems. I personally don't understand why everyone wants sub-folders at all anyway. For me, `plex.example.com` is better than `example.com/plex`. On the topic of upstream web services, this sub-folder forwarding is an advanced feature. Only people who understand the reverse proxying should attempt it. In my testing with some services I found that the upstream service (ie Plex) returned HTML with assets linking to `/styles.css` as an example, not `/plex/styles.css` as you might expect. So the page won't render anything more than HTML. This is because the service has no idea what you're doing in front of it. Some services allow you to specify a "base url" parameter in their configs, but not always. In my software for example, I assume that the base url of the admin interface is going to be `/` and I don't have anyway for people to modify that.

kerem commented

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

Author

Owner

@binhex commented on GitHub (Mar 7, 2019):

I personally don't understand why everyone wants sub-folders at all anyway. For me, plex.example.com is better than example.com/plex.

the reason (at least for me) that i would like sub folders is to reduce admin, having a single domain and thus a single certificate to manage is a lot easier (and cheaper - not using letsencrypt) than having say a dozen hostnames and certificates. i understand that you can generate multiple certs for nothing using letsencrypt but even then the potential for the letsencrypt re-certification process to go wrong is increased due to the multiple requests for certs

In my testing with some services I found that the upstream service (ie Plex) returned HTML with assets linking to /styles.css as an example, not /plex/styles.css as you might expect. So the page won't render anything more than HTML.

yeah this is a downside of using sub-folders most definitely, it can mostly be worked around by configuring the application to use a sub-folder that matches thus the problem goes away, not all apps can be configured though, so for those apps you have no option but to use a separate domain name and cert.

i have taken on board your comments and i appreciate the reply.

@binhex commented on GitHub (Mar 7, 2019): > I personally don't understand why everyone wants sub-folders at all anyway. For me, `plex.example.com` is better than `example.com/plex`. the reason (at least for me) that i would like sub folders is to reduce admin, having a single domain and thus a single certificate to manage is a lot easier (and cheaper - not using letsencrypt) than having say a dozen hostnames and certificates. i understand that you can generate multiple certs for nothing using letsencrypt but even then the potential for the letsencrypt re-certification process to go wrong is increased due to the multiple requests for certs > In my testing with some services I found that the upstream service (ie Plex) returned HTML with assets linking to `/styles.css` as an example, not `/plex/styles.css` as you might expect. So the page won't render anything more than HTML. yeah this is a downside of using sub-folders most definitely, it can mostly be worked around by configuring the application to use a sub-folder that matches thus the problem goes away, not all apps can be configured though, so for those apps you have no option but to use a separate domain name and cert. i have taken on board your comments and i appreciate the reply.

kerem commented

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

Author

Owner

@creedda commented on GitHub (Oct 2, 2020):

I personally don't understand why everyone wants sub-folders at all anyway. For me, plex.example.com is better than example.com/plex.

the reason (at least for me) that i would like sub folders is to reduce admin, having a single domain and thus a single certificate to manage is a lot easier (and cheaper - not using letsencrypt) than having say a dozen hostnames and certificates. i understand that you can generate multiple certs for nothing using letsencrypt but even then the potential for the letsencrypt re-certification process to go wrong is increased due to the multiple requests for certs

In my testing with some services I found that the upstream service (ie Plex) returned HTML with assets linking to /styles.css as an example, not /plex/styles.css as you might expect. So the page won't render anything more than HTML.

yeah this is a downside of using sub-folders most definitely, it can mostly be worked around by configuring the application to use a sub-folder that matches thus the problem goes away, not all apps can be configured though, so for those apps you have no option but to use a separate domain name and cert.

i have taken on board your comments and i appreciate the reply.

Hey @binhex did you get this working?

If so, could you send a screenshot showing what your configuration looks like in the gui? Been struggling to get this to work over the last few days.

Thanks,

@creedda commented on GitHub (Oct 2, 2020): > > I personally don't understand why everyone wants sub-folders at all anyway. For me, `plex.example.com` is better than `example.com/plex`. > > the reason (at least for me) that i would like sub folders is to reduce admin, having a single domain and thus a single certificate to manage is a lot easier (and cheaper - not using letsencrypt) than having say a dozen hostnames and certificates. i understand that you can generate multiple certs for nothing using letsencrypt but even then the potential for the letsencrypt re-certification process to go wrong is increased due to the multiple requests for certs > > > In my testing with some services I found that the upstream service (ie Plex) returned HTML with assets linking to `/styles.css` as an example, not `/plex/styles.css` as you might expect. So the page won't render anything more than HTML. > > yeah this is a downside of using sub-folders most definitely, it can mostly be worked around by configuring the application to use a sub-folder that matches thus the problem goes away, not all apps can be configured though, so for those apps you have no option but to use a separate domain name and cert. > > i have taken on board your comments and i appreciate the reply. Hey @binhex did you get this working? If so, could you send a screenshot showing what your configuration looks like in the gui? Been struggling to get this to work over the last few days. Thanks,

kerem commented

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

Author

Owner

@123dev commented on GitHub (Nov 30, 2020):

https://foo.bar.com/plex => http://192.168.1.10:1234/ <- Yep that should work.

Care to clarify how to get this to work?

We have two services running on host1
host1:port1 and host1:port2
We setup Proxy Host "Domain name" to forward to
http://host1:port1

So we are able to access http://domain_name and can reach to host1:port1 without any issues.

Next we wanted to access http://domain_name/api to reach to host1:port2
We added custom locations: (to the same proxy host configuration)
location: /api
scheme: http
Forward host/ip: host1
Forward port: port2

Sounds simple, but we're getting 502
What are we missing?

Thanks

@123dev commented on GitHub (Nov 30, 2020): > > > `https://foo.bar.com/plex => http://192.168.1.10:1234/` <- Yep that should work. > Care to clarify how to get this to work? We have two services running on host1 host1:port1 and host1:port2 We setup Proxy Host "Domain name" to forward to http://host1:port1 So we are able to access http://domain_name and can reach to host1:port1 without any issues. Next we wanted to access http://domain_name/api to reach to host1:port2 We added custom locations: (to the same proxy host configuration) location: /api scheme: http Forward host/ip: host1 Forward port: port2 Sounds simple, but we're getting 502 What are we missing? Thanks

kerem commented

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

Author

Owner

@123dev commented on GitHub (Nov 30, 2020):

It looks like domain/api is being proxied to host1:port2/api instead of host1:port2/

From the logs

GET /api HTTP/1.1", upstream: "http://10.10.64.64:5001/api

@123dev commented on GitHub (Nov 30, 2020): It looks like domain/api is being proxied to host1:port2/api instead of host1:port2/ From the logs ``` GET /api HTTP/1.1", upstream: "http://10.10.64.64:5001/api ```

kerem commented

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

Author

Owner

@123dev commented on GitHub (Nov 30, 2020):

OK,
Setting: Forward host/ip: to ip: host1/ instead of ip: host1
Gets me to what I need.
Sorry about the noise

@123dev commented on GitHub (Nov 30, 2020): OK, Setting: Forward host/ip: to `ip: host1/` instead of `ip: host1` Gets me to what I need. Sorry about the noise

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

starred/nginx-proxy-manager-NginxProxyManager#84

No description provided.

Rows
Columns