[BUG]: Prowlarr forces URL rewrite behind reverse proxy #233

Closed
opened 2026-02-20 09:40:31 -05:00 by deekerman · 2 comments
Owner

Originally created by @justsem on GitHub (Aug 5, 2021).

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

In my case I have this setup:

Sidenote: I have Sonarr, Radarr and Lidarr configured in the exact same way without any issues

A Debian 11 installation with Prowlarr in a netns (network namespace) in which an interface with IP 10.13.38.2 is available.
Using Systemd Prowlarr will be assigned to said netns in which it binds neatly to 10.13.38.2.

Nginx is configured to reverse-proxy to Prowlarr using the location blocks provided in the Wiki

It's important to note that I can't directly reach the 10.13.38.x range from my browser. Instead I point it to https://my.prowlarr.domain.name which will connect to nginx.

This is where it gets weird. Along the way some rewriting in the URL gets done, which I believe is being done by Prowlarr. This rewrites the url to http://10.13.38.2, instead of the URL I initially pointed my browser to.

Setting the logging to debug or even trace does not yield any valuable information when it comes to this.
I'm not sure if this can be resolved by some configuration directive, but I couldn't find any documentation on supported directives in the Config.xml file.

This same behaviour occurs when I remove the netns configuration.

Expected Behavior

In expected behaviour the URL should not be rewritten to Prowlarr's bind-address but instead remain as the actually requested URL.

Steps To Reproduce

  1. Install Prowlarr on Debian following the Servarr Wiki.
  2. Install nginx from the nginx mainline repo.
  3. Configure the reverse proxy following the Servarr Wiki
  4. Try to access prowlarr over the reverse proxy

Environment

- OS: Debian 11
- Prowlarr: 0.1.0.608
- Docker Install: No
- Using Reverse Proxy: Nginx
- Browser: Firefox

What branch are you running?

Develop

Anything else?

prowlarr.trace.txt
config.xml.txt

AB#1391

Originally created by @justsem on GitHub (Aug 5, 2021). ### Is there an existing issue for this? - [X] I have searched the existing issues ### Current Behavior In my case I have this setup: Sidenote: I have Sonarr, Radarr and Lidarr configured in the exact same way without any issues A Debian 11 installation with Prowlarr in a netns (network namespace) in which an interface with IP 10.13.38.2 is available. Using Systemd Prowlarr will be assigned to said netns in which it binds neatly to 10.13.38.2. Nginx is configured to reverse-proxy to Prowlarr using the `location` blocks provided in the Wiki It's important to note that I can't directly reach the 10.13.38.x range from my browser. Instead I point it to https://my.prowlarr.domain.name which will connect to nginx. This is where it gets weird. Along the way some rewriting in the URL gets done, which I believe is being done by Prowlarr. This rewrites the url to http://10.13.38.2, instead of the URL I initially pointed my browser to. Setting the logging to debug or even trace does not yield any valuable information when it comes to this. I'm not sure if this can be resolved by some configuration directive, but I couldn't find any documentation on supported directives in the Config.xml file. This same behaviour occurs when I remove the netns configuration. ### Expected Behavior In expected behaviour the URL should not be rewritten to Prowlarr's bind-address but instead remain as the actually requested URL. ### Steps To Reproduce 1. Install Prowlarr on Debian following the Servarr Wiki. 2. Install nginx from the nginx mainline repo. 3. Configure the reverse proxy following the Servarr Wiki 4. Try to access prowlarr over the reverse proxy ### Environment ```markdown - OS: Debian 11 - Prowlarr: 0.1.0.608 - Docker Install: No - Using Reverse Proxy: Nginx - Browser: Firefox ``` ### What branch are you running? Develop ### Anything else? [prowlarr.trace.txt](https://github.com/Prowlarr/Prowlarr/files/6940932/prowlarr.trace.txt) [config.xml.txt](https://github.com/Prowlarr/Prowlarr/files/6940934/config.xml.txt) [AB#1391](https://dev.azure.com/Servarr/7ab38f4e-5a57-4d70-84f4-94dd9bc5d6df/_workitems/edit/1391)
Author
Owner

@bakerboy448 commented on GitHub (Aug 5, 2021):

fairly certain this is an NGINX configuration issue not a Prowlarr app redirect issue.

The only way this would be a Prowlarr bug is if there is a missed commit/pull from Radarr that resolved this type of issue.

The sample Prowarr conf on the wiki does not work for a subdomain. I'd suggest using the radarr conf you're using and tweaking it accordingly.

@bakerboy448 commented on GitHub (Aug 5, 2021): fairly certain this is an NGINX configuration issue not a Prowlarr app redirect issue. The only way this would be a Prowlarr bug is if there is a missed commit/pull from Radarr that resolved this type of issue. The **sample** Prowarr conf on the wiki does not work for a subdomain. I'd suggest using the radarr conf you're using and tweaking it accordingly.
Author
Owner

@justsem commented on GitHub (Aug 5, 2021):

fairly certain this is an NGINX configuration issue not a Prowlarr app redirect issue.

The only way this would be a Prowlarr bug is if there is a missed commit/pull from Radarr that resolved this type of issue.

The sample Prowarr conf on the wiki does not work for a subdomain. I'd suggest using the radarr conf you're using and tweaking it accordingly.

It turns out you were right. I initially copied the radarr config file which had a different value in the Host header which gets forwarded. Editing the value for the host header fixed it.

For additional info, the error only occured when requesting / when I'd request /login the issue would not occur.

@justsem commented on GitHub (Aug 5, 2021): > fairly certain this is an NGINX configuration issue not a Prowlarr app redirect issue. > > The only way this would be a Prowlarr bug is if there is a missed commit/pull from Radarr that resolved this type of issue. > > The **sample** Prowarr conf on the wiki does not work for a subdomain. I'd suggest using the radarr conf you're using and tweaking it accordingly. It turns out you were right. I initially copied the radarr config file which had a different value in the Host header which gets forwarded. Editing the value for the host header fixed it. For additional info, the error only occured when requesting `/` when I'd request `/login` the issue would not occur.
Sign in to join this conversation.
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/Prowlarr#233
No description provided.