mirror of
https://github.com/NginxProxyManager/nginx-proxy-manager.git
synced 2026-04-28 10:55:54 +03:00
[GH-ISSUE #879] Different services on the same proxy host #743
Labels
No labels
awaiting feedback
bug
cannot reproduce
dns provider request
duplicate
enhancement
enhancement
enhancement
good first issue
help wanted
invalid
need more info
no certbot plugin available
product-support
pull-request
question
stale
troll
upstream issue
v2
v2
v2
v3
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/nginx-proxy-manager-NginxProxyManager#743
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @smamudhan on GitHub (Feb 8, 2021).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/879
Hello, I am trying to set up the nginx proxy manager but cannot seem to figure this out after reading the FAQs and several other issues.
I am trying to accomplish this:
home.mydomain.com --> index.local (webserver)
home.mydomain.com/nas --> synology.local:5000 (synology NAS)
home.mydomain.com/nvr --> nvr.local:443 (security camera recorder)
… and so on
I have tried specifying both the IP addresses and hostnames in the custom locations. I know this is possible with nginx as I had this set up by manually adding conf files in the /sites-available directory. What am I missing here?
@lieven121 commented on GitHub (Feb 11, 2021):
Hi
(As far a I know)
This should work but is dependent on the application you are trying to do this with. This is because paths are also visible for the underlying hosts.
For example if I use home.example.com/files --> www.filemanager.local
the filemanager will try to open in the path /files. You should see this in the console if this is the case since a lot of resources would fail to load.
Maybe a solution (that I use) if you have full control of the domain. Use subdomains:
home.mydomain.com --> index.local (webserver)
nas.home.mydomain.com --> synology.local:5000 (synology NAS)
nvr.home.mydomain.com --> nvr.local:443 (security camera recorder)
I know this technically doest solve the problem but I hope it might help
@smamudhan commented on GitHub (Feb 12, 2021):
The thing is; I have DDNS set up; and it's wildly inconvenient to set up all these subdomains over and over; back to Ajenti, then!
Perhaps this could be a feature request? To change the behavior for specific proxy-hosts using a toggle or something like that...?
It's so much more convenient to monitor/manage via this awesome webgui
On an unrelated note; do you happen to know if I could achieve similar behavior via the custom config? I wasn't able to find much relevant documentation; standard nginx conf didn't do it for me.
Would be happy to write up documentation/blog post detailing the instructions.
@xannor commented on GitHub (Feb 13, 2021):
I actually do this, along with subdomains as well. Using IP/DNS should work as long as they are resolvable from within the container (i.e. if your network dns can lookup .local, not just your shell login, as usually .local is handled by a locally run mdns resolver which I dont think docker containers can use by default without a local resolver in the container).
If the target app is "smart" you should be fine. But some apps assume they are a root, or are not possible to configure as a sub, so in those cases you have to add a / after the hostname or IP. This will setup proxy pass to rewrite a request to /nas/ as http://synology.local:5000/, however this can have problems as well if the target app has directs or builds non-relative urls. The workaround for that also depends on the target app. Some will allow custom headers to be passed to tell them the appropriate url, such as SCRIPT_NAME, or config entries in the app.
Unfortunately this is when the proxy manager is hit or miss, but not because of the proxy app, but because of the many possibilities that could be.
@github-actions[bot] commented on GitHub (Mar 19, 2024):
Issue is now considered stale. If you want to keep it open, please comment 👍