mirror of
https://github.com/NginxProxyManager/nginx-proxy-manager.git
synced 2026-04-27 02:15:51 +03:00
[GH-ISSUE #439] Custom Locations not accepting wildcards (related to Organizr ServerAuth) #368
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#368
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 @eriksneff on GitHub (May 31, 2020).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/439
First off, I've used Traefik v1/v2, and Caddy v1/v2, and generally been displeased with them. I used all four primarily for the purposes of reverse proxying my home services. I've invested hundreds of hours into learning them, and I feel like in <3 hours, I've managed to get Nginx Proxy Manager working as well or better than I ever did with any of them. The initial setup and overall experience has been magnificent, intuitive, and struck just the right balance of providing advanced capabilities without complicating the experience. I'm so impressed. So, kudos to you, you've made a truly remarkable product that I will definitely be using for years to come, and influencing others to do the same!
Alright... so, I just got ServerAuth working for lots of services that are reverse proxied by nginx proxy manager and are now also using Organizr for ServerAuth. It took a long time though, mainly due to several problems with the instructions provided in Organizr's docs that seem to assume wildcards and variables a la nginx config files would work inside Nginx Proxy Manager's Custom Locations fields. It's unclear to me if those instructions were accurate in the past, but no longer are, or if they were never accurate and I'm one of the first to point it out. Here's the instructions from Organizr's official site that explain how to configure Nginx Proxy Manager so that Organizr can perform ServerAuth duties:
What I observed was - when I did what's in the first screenshot in that link above and added a custom location where the location field has:
and saved it - no matter what else was in the fields on that modal, Organizr would immediately appear offline to Nginx Proxy Manager, and would become unreachable. Similarly, in the forward hostname field, if I did as instructed and used the $1 variable (which assumes that the (.*) wildcard from above was valid) in the Forward Hostname / IP field, like:
and saved it - no matter what else was in the fields in that Custom Locations modal, Organizr would become unreachable and appear offline to Nginx Proxy Manager.
For what it's worth, my solution to this ended up being replacing those wildcards and variables in the Custom Locations fields with hard-coded values, like:
and
and once saved, everything started working. Again, not sure if the instructions were once correct and it's a recent change that's causing them to be incorrect, or if they've been wrong all along and what I'm describing is expected behavior, but it took a couple hours to figure out, and half an hour to describe here, so I'm hoping to start the process of helping others not suffer the same fate as me. Thoughts?
@Subv commented on GitHub (May 31, 2020):
The Organizr proxy host showing as offline means the nginx config for it failed to validate, what does the log say? You can hover over the "Offline" indicator to get a quick report of the error like this:
If that doesn't show anything useful, you can also check the nginx error log inside the container at
/data/logs/error.log(or directly from the mounted Docker volume)@chaptergy commented on GitHub (May 12, 2021):
The suggestion above is a great first starting point.
You can also check the generated nginx config inside the docker container at
/data/nginx/proxy_host(or whichever host you are creating). It's hard to match the id with a host though (see issue https://github.com/jc21/nginx-proxy-manager/issues/174), but if it is the last host you have created, going with the largest number is your best bet.I think this is a great starting point for others with the same issue, and as there hasn't been much activity in the past year, I will close this issue.