mirror of
https://github.com/NginxProxyManager/nginx-proxy-manager.git
synced 2026-04-25 01:15:51 +03:00
[GH-ISSUE #2078] Redirecting #1500
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#1500
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 @aeternum1986 on GitHub (May 29, 2022).
Original GitHub issue: https://github.com/NginxProxyManager/nginx-proxy-manager/issues/2078
Checklist
jc21/nginx-proxy-manager:latestdocker image?Describe the bug
I am having an issue whereby NPM will redirect to internal domains. For example, I set up Searx on 192.168.1.100:8080 and i want to connect to that with https://searx.my.domain. Unfortunately, when I go to https://searx.my.domain, it automatically redirects to http://localhost:8080 which doesn't work, because I'm on a different machine. I had a similar issue with Bitwarden, whereby it would redirect to my internal DNS name. Which is why I think it's a problem with NPM, not either bitwarden or Searx
Nginx Proxy Manager Version
v2.9.18
Expected behavior
It should keep its domain and stay at searx.my.domain
Operating System
Ubuntu server 20.04 running on proxmox
@the1ts commented on GitHub (May 29, 2022):
It sounds like you are setting up redirect hosts in the UI which simply send back a redirect to the web browser to go to the new destination, think of google.com redirecting you to google.de if in Germany or google.fr if in france.
What you want is to setup proxy hosts. This does exactly what you want, i.e. put an SSL proxy in front of http://localhost:8080 allowing you to see the http://localhost:8080 content while seeing searx.my.domain in the web browser.
@aeternum1986 commented on GitHub (May 29, 2022):
Thanks for the response.
It's definitely a proxy host, not a redirection host.
@the1ts commented on GitHub (May 29, 2022):
Well the redirect is probably coming from the proxied to webserver.
A standard NPM proxy_host doesn't have any redirect config except when force SSL is used but that is a simple http -> https redirect not a domain1 -> domain2 redirect, also this redirecting is handled early in the config so is acted upon before the proxy_pass is seen and uses the request_host variable not the proxy_host variable so the redirect stays on the same domain the web browser first issued.
However, NPM will pass back any redirects coming from the proxied to webserver. This is often done because the application wants to know what URL it is seen by so will issue a redirect to get clients on the domain its expecting. It could be in this case the application thinks it runs from http://localhost:8080 so hitting it with with this URL https://example.com/test_app will get a redirect to http://locahost:8080/test_app from the application side, not NPM.
@the1ts commented on GitHub (May 29, 2022):
This is an interesting read on the subject. Although they are talking about apache reverse proxy, they talk about the BASE_URL for searx needing to be set to how the domain the reverse proxy will receive traffic.
@aeternum1986 commented on GitHub (May 29, 2022):
so you think it's a problem with searx? I had a very similar issue with bitwarden, so I'm not sure if it's searx or not.
@aeternum1986 commented on GitHub (May 29, 2022):
also, I saw that with the base_url thing and tried it before, but it didn't work
@the1ts commented on GitHub (May 29, 2022):
yes I do, a real test would be to use curl to do full test.
and see where the redirect comes from. One other test is to do it on the docker host itself as below, this takes NPM out of the flow, but still hits the searx as if it was
This will hit the searx directly, but ask for searx.my.domain. If a redirect is seen then its the searx doing the redirect.
@the1ts commented on GitHub (May 29, 2022):
bitwarden install also has steps to tell it the URL you'll be hitting it from i.e. the url in NPM (bitwarden.my.domain) not http://localhost:8080
@aeternum1986 commented on GitHub (May 29, 2022):
when i tried your first command, it just sat on "Trying ip.ad.dr:443" and didn't move for the 2-3 minutes i had it running. I tried your second command, and it outputted the html of the first page
@aeternum1986 commented on GitHub (May 29, 2022):
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Content-Length: 5275
< Server-Timing: total;dur=2.39, render;dur=1.097
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< X-Download-Options: noopen
< X-Robots-Tag: noindex, nofollow
< Referrer-Policy: no-referrer
< Connection: close
<
then the rest is html. this was from your second command
@the1ts commented on GitHub (May 29, 2022):
The first one not connecting is very suspicious, its exactly what a web browser would send may be a problem from where you running it. But I'm still convinced NPM setup as you say isn't doing any redirects. Its either before it (CDN like cloudflare) or after it (app config).
@aeternum1986 commented on GitHub (May 29, 2022):
ok. thanks for the help. I will take it up with the SearxNG people
@aeternum1986 commented on GitHub (May 29, 2022):
I just tested it again, and it works as expected when i take NPM out of the mix. So it's gotta be NPM
@github-actions[bot] commented on GitHub (Feb 16, 2024):
Issue is now considered stale. If you want to keep it open, please comment 👍
@github-actions[bot] commented on GitHub (Apr 1, 2025):
Issue was closed due to inactivity.