Configuration for WebUI base url for use in reverse proxy

[Fastjur]

This issue seems to be getting quite some thumbs up's from people who would like to see this added
Please, to keep the mailboxes of everyone clean, do not +1 this as a comment, but rather click the thumbs up icon beneath this very first message.

For the people landing here from Google:

A workaround can be found here: https://github.com/qbittorrent/qBittorrent/wiki/NGINX-Reverse-Proxy-for-Web-UI

---

I have searched for this and it appears to not be possible as of yet.

It would be really useful if there is an option to specify the base URL path for use in reverse proxies. This way one can circumvent having to type the port number into the URL.

For instance, when the qBittorent web UI is running on port 8080, and the base url is set to /qbt. Then the complete URL would become 127.0.0.1:8080/qbt. One can then use, per example, nginx to reverse proxy this to a more friendly url like so:

server {
  listen  80;
  server_name jt.REDACTED.net localhost 192.168.1.6;

  location /qbt {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

Thus allowing one to goto jt.REDACTED.net/qbt and land on the qBittorrent page.

---

There is a $50 open bounty on this issue. Add to the bounty at Bountysource.
DISCLAIMER: There are trustworthiness and solvency issues with BountySource. qBittorrent is not affiliated with them. Use them at your own risk.

[sruon]

Since this is pretty much the only result that comes up when searching for reverse proxy support in QBittorrent, here's a workaround that I'm using and appears to work fine.

location ~ /qbt/(?<url>.*) {
         proxy_pass  http://127.0.0.1:8080/$url;
<insert other directives..>
}

[MichaelHub]

The above configuration worked for me. The only issue was that when navigating to the URL (ex. domain.com/qbt) Nginx would return a 404 error, but when a trailing slash was added (ex. domain.com/qbt/) it would work fine. I ended up just configuring a redirect to the trailing slash URL.

location /qbt {
	rewrite ^(.*[^/])$ $1/ permanent;
}

[jdmag00]

Would love to see a base URL, or root folder option added for reverse proxy.

[pozemka]

Both @sruon and @MichaelHub workarounds work, but when I select "Peers" tab it shows empty list and displays something like "qbittorrent client inaccessible". However using direct connection via ip:port works fine.
Another thing is that reverse-proxied interface have no favicon.

[MichaelHub]

@asc7uni Oh, I hadn't used the WebUI before setting it up and thought it was just flakey like that. I'll take a look at my configuration this week and see if I can find a fix.

[thalieht]

This looks like a popular request, tagging @Chocobo1 if he's interested.

[SuperTrembler]

+1
Current nginx config in wiki breaks bypass authentication for clients in subnet as it wont pass real ip I believe

[Fastjur]

As stated in the original feature request:

This issue seems to be getting quite some thumbs up's from people who would like to see this added
Please, to keep the mailboxes of everyone clean, do not +1 this as a comment, but rather click the thumbs up icon beneath this very first message.

[kurosh]

Another +1 for this, not working for me behind Nginx. Login screen appears (without any images strangely) then when I submit the password appears in the URL and goes to blank screen :|

[Routhinator]

I've put a bounty on this. I'd like something that works with Apache.

[boredazfcuk]

I'd like to see this added too... I'm running everything inside Docker containers, so my nginx reverse proxy configuration would look like this:

location /qbittorrent/ {
   include      reverse_proxy.conf;
   include      security_headers_https.conf;
   set          $qbittorrent_upstream   http://qbittorrent:8080;
   proxy_pass   $qbittorrent_upstream;
}

I'm using set $qbittorrent_upstream http://qbittorrent:8080; so nginx evaluates the IP address of the qbittorrent container on every connection. Without it, nginx will only evaluate the IP address of the qbittorrent container when nginx launches. Without the set command, nginx will continue to contact a dead IP address if the qbittorrent container changes IP after a restart, or host migration. Restarting nginx to pick up the new IP address of the qbittorrent container disrupts other services.

Unfortunately the set directive in nginx does not allow the variable to end with a trailing slash, so the published nginx solution doesn't work.

Having qbittorrent operate out of a webroot such as http://<IP Address>:8080/qbittorrent would be ideal for all reverse proxies to handle.

[Ferk]

The reason the proxying fails for me is because the Web UI is internally sending requests to the host without using the base URL.
In order for this to work the Web UI would need to send the api requests to /qbt/api rather than /api (or at least use relative paths). And the same will happen with any assets, images or external css/js that the WebUI might want to load.

Just for the record, this would be how it's done in lighttpd, in case someone wants to use that instead of nginx:

$HTTP["url"] =~ "^/qbt" {
    proxy.server = ( "" => ( ( "host" => "127.0.0.1", "port" => 1340 ) ) )
    proxy.header = ( "map-urlpath" => ( "/qbt" => "/" ) )
}

But of course it has the same issue.

[glassez]

I'm sorry, maybe I'm off topic and don't understand something... but I am sure that Proxies should not require any additional worries on the part of the services behind them.

at least use relative paths

Maybe that's really the problem?
@Chocobo1, what do you think of all this?

[kharenis]

I'm sorry, maybe I'm off topic and don't understand something... but I am sure that Proxies should not require any additional worries on the part of the services behind them.

at least use relative paths

Maybe that's really the problem?
@Chocobo1, what do you think of all this?

At present, all the client-side references point to the root directory. You're able to load the first page, but none of the dependencies load because they don't include whatever path you've configured your reverse proxy to use.
Having a configurable base path seems to be a pretty commonplace way to account for this.

Edit:
I've done some more testing and it seems the problem lies in the trailing / on the URL, reverse proxies must be configured with a / on the end of the path. (eg. http://locahost/qbt/ rather than http://localhost/qbt)

In the changes I've made, I'm prepending all the resource URLs in the client-side code with a static path including the configured base path. This forces everything to point to the right place without having to worry about the URL being correct for relative paths.

[Chocobo1]

@Chocobo1, what do you think of all this?

I've done some more testing and it seems the problem lies in the trailing / on the URL.

I think we can fix this trailing / issue, but we'll need more info on it, it isn't clear how/where we should handle this.

(and have their proxy setup to remove duplicate / )

I suppose qbt could add a workaround for this (duplicate /) IF this is a separate issue of the aforementioned one.
https://stackoverflow.com/a/40683096

[kharenis]

@Chocobo1, what do you think of all this?
I've done some more testing and it seems the problem lies in the trailing / on the URL.

I think we can fix this trailing / issue, but we'll need more info on it, it isn't clear how/where we should handle this.

The simplest way without a configurable base path would probably be a js snippet in the index page to redirect the page if it's missing the trailing /.
It's only a problem because the relative paths only work if the path is empty, or there's a trailing / in the URL if there is a path.

(and have their proxy setup to remove duplicate / )

I suppose qbt could add a workaround for this (duplicate /) IF this is a separate issue of the aforementioned one.
https://stackoverflow.com/a/40683096

On second thoughts a duplicate / isn't really an issue for qbt, it's up to the user to configure their reverse proxy correctly. (And would only be caused if they hadn't done so)

I'll throw together a branch that redirects the page with a trailing / if missing and do a bit of testing to see if everything works correctly.

[boredazfcuk]

I run SABnzbd, whose URL ends with a trailing slash, and that has no issues. Proxies handle trailing slashes on URLs just fine.

Double forward slash in a URL would be an issue though. Nginx would need a non-default module installing to perform a string replacement (https://github.com/yaoweibin/ngx_http_substitutions_filter_module) of "//" to "/".

That's going to cause issues with any legitimate uses of double forward slashes though... e.g. https://mydomain.com, for example, would become https:/mydomain.com.

[luzpaz]

What's left to do here ?

[jakobbouchard]

I think there's still an issue with the CSS and JS not loading correctly when using a different base URL. In my case, using the method from this comment, I could load all the HTML correctly, but the rest didn't load at all. Part of it could be fixed by adding a <base /> tag, but it wouldn't fix any JavaScript. It would also required adding an option to the Web UI tab where we could specify our base URL, a bit like Radarr and Sonarr do.

[CapivaraTupiniquim]

Is there any plan to have a Base URL configuration, like in raddar, sonarr and the like? I use Caddy as a reverse proxy

[markmetcalfe]

I've found the solution for NGINX defined in the wiki doesn't completely work for me. Some API requests - such as getting the content list for an individual torrent - do not work.

The NGINX solution specified in linuxserver's reverse proxy configs works completley for me - I haven't run into any issues with the following conf:

server {
    listen 443 ssl;
    server_name xyz.com;

    # ...

    location = /qbittorrent {
        return 301 /qbittorrent/;
    }

    location ~/qbittorrent(.*)$ {
        proxy_pass http://localhost:30000;
        include includes/proxypass.conf;
        rewrite /qbittorrent(.*) $1 break;
        
        # Extra options here, e.g: 
        # client_max_body_size 100M;
        # ...
    }
}

Note the rewrite directive is important.

[samwh1te]

I don't suppose there's any way around the CSS/JS issue without a base url being implemented? Does anyone know if there's an alternative frontend which might have base url support?

[Piccirello]

I have a draft PR up (#21471) that implements this feature and would like some feedback. Ideally, folks can test my branch and verify it adequately satisfies their use case. This is working well with my test nginx setup (nginx config included below), but you may have a different setup that this does not work for. If so, let me know.

Note the trailing slash in both the location directive and the proxy_pass directive:

server {
    listen 80;
    server_name example.com;

    location /qbit/ {
        proxy_pass  http://localhost:8080/;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

[kevinpeno]

Hey folks. Sorry to barge in on your 8 year old discussion, but I thought I'd bring some insight as someone who has worked with websites and services for almost 18 years. I'm sorry if I missed some important details, its a pretty long thread.

While silly compared to OSes, the web has a fairly strict requirement to know the difference between a "directory" and an "endpoint". In the file system, there's typically a directory mime type available for the system to extrapolate from and know that thing or thing/ refers to a directory. This was never standardized for HTTP and the web. (Note: it technically might have been standardized later on but no one has implemented it because it would break the web and the web hates breaking things)

As such, while there is nothing technically in the standards regarding directories, the consensus is that with a slash means a directory and without means an endpoint, aka resource or file. That means a trailing slash is a requirement when you're trying to do something like map an internal service from :80/ to :80/qbit/. To break it down, here's the use cases:

• If URL of :80/qbit with relative url of either something/thing.file or ./something/thing.file means grab something/thing.file from :80/something/thing.file.
• If URL of :80/qbit/ with relative url of either something/thing.file or ./something/thing.file means grab something/thing.file from :80/qbit/something.thing.file.

So, if you intend to resolve /qbit to a directory (or re-root qbit via proxy), add a 301 Permanent redirection rule for /qbit and point the user to /qbit/ and proxy via /qbit/ as was done by this comment and in the wiki referenced in the OP.

Other resources on the subject: Google Search Console, URL rewriting (StackOverflow; see top two answers for details)

Happy to answer any questions.