Remote Access Web UI not working on any Client after 3.3.11

[jeff15110168]

qBittorrent version and Operating System:

3.3.15 x86 or x64 on Win10 Pro x64

What is the problem:

Web UI is not working properly with version 3.3.15 in either x86 or x64 program. The localhost:8080 port works perfectly with 3.3.11 and 3.3.15, but as soon as upgrade is done from 3.3.11 to 3.3.15, it breaks functionality for remote accessing via DDNS servers (i.e. personalserver.ddns.net:1000, where 1000 is external port pointing to 8080 internal port).

The favicon in Chrome pops up when loading DDNS remote web UI, but it only loads a white page.

What is the expected behavior:

Cannot find reason as to why web UI is broken in this version and not 3.3.11, as no settings have changed between runs. All the ports are being correctly forwarded in router's setting, and NO-IP is working properly. Radarr and Sonarr are for example continuing to be accessible remotely through personalserver.ddns.net:1001 or personalserver.ddns.net:1002, etc.).

Steps to reproduce:

Installed qBittorrent 3.3.15 (both 32-bit and 64-bit), using old settings from 3.3.11 and web UI does not work now.

[sledgehammer999]

@Chocobo1 if you're not busy, take a look.

[Chocobo1]

All the ports are being correctly forwarded in router's setting

Could you try using the same port for this, i.e. qbt & router both listening to 54321 and the port forwarding maps it (wan) 54321 -> (lan) 54321.

[jeff15110168]

I used the same out and in port in my router settings and it still gives the same error. It will not load anything, only a white blank page when accessing externally. localhost:[internalport] still works fine on the local machine though.

[Chocobo1]

I used the same out and in port in my router settings and it still gives the same error.

I assume you made sure that qbt webUI listening port is also listening to the same port...

Then there was another user that have similar settings, he got it working with nginx: #6962
And the setting for nginx: https://github.com/qbittorrent/qBittorrent/wiki/NGINX-Reverse-Proxy-for-Web-UI

[xFaBx]

Similar problem, update from 3.3.13 -> 3.3.15. In my case I open the web page through a nginx proxy that passes the request through a reverse ssh.

EXT PROXY:
-- (qbit.example.com/qbit)
Local reverse ssh
-- http: // localhost: 12345
|
| Reverse ssh (tunnel localhost: 12345)
|
Reverse ssh server
-- (12345: qbittorrentserver: )
|
|
Qbittorrent server
-- (http: // qbittorrentserver: webuiport)

I'm trying to get around the problem with nginx but i'm having problems. The solution proposed in my case does not work.
P.S. With version 3.3.13 I used the nginx stream function and not the proxy with the server block.

[jeff15110168]

hmm, im not familiar with NGINX. is that another program that runs with this?

@xFaBx, did your 3.3.13 work with Web UI? I had separate issues with Sonarr having header issues with 3.3.13 which is why I was using 3.3.11.

[jeff15110168]

hmm, im not familiar with NGINX. is that another program that runs with this?

@xFaBx, did your 3.3.13 work with Web UI? I had separate issues with Sonarr having header issues with 3.3.13 which is why I was using 3.3.11.

[xFaBx]

@jeff15110168 Yes but with NGINX "Stream" option.
`
stream {

   ...options...

    upstream torrent {
            hash $remote_addr consistent;
            server localhost:<port>;

    }

    server {
            listen <port> ssl so_keepalive=on;
            proxy_connect_timeout 300s;
            proxy_timeout 300s;
            proxy_pass torrent;

    }

}
`

[Chocobo1]

Is it possible that you test this binary? I've a feeling that I did something wrong.
https://github.com/Chocobo1/temp/raw/master/hostheader/qbittorrent.exe
you can see the patch here: Chocobo1@52f9330

[xFaBx]

@Chocobo1 I did not specify. I'm using qbittorrent-nox on voyage-linux linux (debian 8). Do you have linux sources (Can I get them from the master repo?)?

[Chocobo1]

Do you have linux sources (Can I get them from the master repo?)?

No, I do not. You'll have to compile from source then.

[sledgehammer999]

@xFaBx the patch is now in master. You can clone it and compile it locally to test.

[xFaBx]

@Chocobo1 Does not work, same problem (3.3.14, 3.3.15, 3.4b). Compiled and tested on ubuntu 17.04 because debian 8 does not have qt 5.5.1.

[sledgehammer999]

Does not work, same problem (3.3.14, 3.3.15, 3.4b)

I hope when you say 3.4b you compiled latest code from master branch. Otherwise, you didn't compile source with the fix in.

[xFaBx]

@sledgehammer999 Yes, master branch!

[Chocobo1]

@xFaBx
sorry I can't debug everyone's setup, as a guideline, you should make sure qbt receive correct Host, X-Forwarded-Host, Referer, Origin header fields (if they are being used).

[xFaBx]

@Chocobo1 Ok, I'll try to make new configurations.
Thank you for your time.

[jeff15110168]

any update?

[Chocobo1]

any update?

Have you tried #7274 (comment)?

[Quiksmage]

On Windows QBT 3.3.15 x64. Same issue. White screen remotely, Sonarr/etc stop working when using external address. They all work fine with internal address.

[ghost]

Hi
The binary from #7274 works for me !
Thanks !

[GitHub010931]

How do you install? Overwrite the previous EXE in the install folder?

[Chocobo1]

@thombeck
You're welcome, the fix will be included in the upcoming release.

@GitHub010931

Overwrite the previous EXE in the install folder?

Exactly.

[jeff15110168]

replacing the referenced #7274 EXE file in my install folder C:/Program Files (x86)/ did not fix the issue. The EXE file itself worked (i.e. it opened, was seeding and downloading, could access it via localhost:[port XXXX] but again same issue with full white screen via an external DDNS address.

[jeff15110168]

any other people's thoughts? What exactly did it fix for @thombeck ?

I'm really waiting for qBittorrent to update their web UI so that you can limit amount uploaded (seed ratio rule) in the Web GUI. Right now I still have to remote into windows desktop to limit each torrent I add (or ideally, limit by tracker).

[ghost]

Exactly like you : replacing the referenced #7274 EXE file in my install folder C:/Program Files (x86)/ did not fix the issue. The EXE file itself worked

[Quiksmage]

we should clarify for the devs then.
so far, there is no official fix for remote webui other than a reverse proxy (because it gets treated like it's local)

[jeff15110168]

@thombeck well that's not helpful if exe itself works but doesn't fix the issue. how can you say "The binary from #7274 works for me !"

Must be english lost in translation. Still looking for a solution for this. 3.3.11 has become unstable for me recently.

[jeff15110168]

just installed 4.0 version and still has the same problem. Still stuck on 3.3.11 :(

[Chocobo1]

One last time, please post your execution log from qbt v4.0.0 in this thread and don't ignore my previous post. Otherwise I have no idea of what is going on...

[jeff15110168]

@Chocobo1 sorry for that, I upgraded to 4.0 and it caused a whole mess of issues with my RSS feeds so I spent a good chunk of time reconfiguring those as I forgot to back up the relevant appdata folders.

I am away for thanksgiving but when I get home, will back up the appdata Roaming + Local folders then upgrade to 4.0 and send you my logs. Apologies again and appreciate your help, and hope you had good thanksgiving.

[PegHorse]

@Chocobo1 This is complicated, there is no error but white page when accessing remote access web UI since you reworked this. I suggest you rollback definitely the WebAccess UI plugin to the working version which has no defect.
As i told you, i have to stay to version 3.3.12 to have a working program.
I've been following this thread since a while, since you asked me to test the new .exe but people did it before me which proof doesn't change anything.
I have a lots of torrents to manage, i do not wish to loose all neither my settings.

[jeff15110168]

@Chocobo1 @PegHorse same boat, im hesitant to do a lot of changes as I have upwards of 1000 torrents and last time when i upgraded to 4.0 then back down to 3.3.11, it forced rechecked dozens of active torrents (some large, like 500GB torrents still in process) which caused 2 days worth of rechecking on my array as well as reconfiguring all my RSS feeds as they disappeared and messing up my columns (a bunch of ghost empty columns appeared when downgrading).

How can we help troubleshoot this issue which i believe happened after 3.3.11, without causing too much issues? I'm going to see if I can take control of another windows PC to troubleshoot instead of doing it on my primary seed computer.

I have on my list of to-dos as getting you the log when i upgrade to 4.0 and access the Web UI. I assume @PegHorse @diogosena @knguyen87 and a few of the other guys above may have some helpful direction so that we can figure out a potential solution.

[Chocobo1]

How can we help troubleshoot this issue which i believe happened after 3.3.11, without causing too much issues?

You could move qbt configs to another location, then start qbt 4.0 and grab the logs and finally restore the configs and back to 3.3.x.

[geekotaku]

Same problem on my environment
4.0.3 on Linux Mint 18.3

I use tcpdump to capture the package use command
sudo tcpdump port 8080 -v

http://localip:8080 get package from access ip
http://ddns:8080(from local network) get package from my router ip, It can work.

http://ddns:8080(from internet) get nothing~

All other function work properly on my environment

[jeff15110168]

It isn't clear to me what's going in the above, as I'm unfamiliar with the "capture packet" process and heed wanting to make significant changes to my current setup of 3.3.11 due to seeding close to 10TB right now (last time i upgraded then downgraded it made me force a significant amount of my seeding torrents).

I have seen new issues mentioning web UI since this post, but wasn't clear to me that for those epople if web UI was specifically working for them on 4.0.x. Is anyone here able to to get web UI working without any sort of further adjustments (i.e. through a "reverse proxy" or anything)?

[diogosena]

yes, its working fine here, just changed default port.

[jeff15110168]

Hmm, what do you mean default port?

[rentalskorpion]

I found a solution when using the web gui over a ssh tunnel.
The port used in the browser and the port qbittorrent is listening on must be the same.
e.g.: qbittorrent listening on 8080, web browser url is localhost:8080
This solution works on version 4.0.3 .

[diogosena]

Hmm, what do you mean default port?

Just change the web ui port to something else like 12345, or whatever you want, and use that same port for external access

[jeff15110168]

I have it set to a different port for Web Ui (7020) than the actual listening port (that is another number between 50000-60000) but again, the Web UI doesn’t work after moving to any version after 3.3.11...

[BW52]

Here in the Netherlands webui does work only on the LAN (on my tablet) but not on the WAN. Using 4.04 version.
A friend of mine has the same problem. He didn't have this probem before when using 3.3.
Are using another port as 8080. The selected port is open.
As it works on the LAN i reckon settings are ok. IPadress:port in the browser doesn't connect remote in the WAN.

[jeff15110168]

Would be nice to hear from developers or others as seems it’s not just isolated to a few incidents.

Web UI continues to not work. For people not familiar with reverse proxy, NGINX or whatever (ie I run it on Windows Where I’m just forwarding ports to allow external WAN access), it would helpful to know what we can do to try figure this out.

[jeff15110168]

has this been fixed yet..? I'm having extreme stability issues on qBittorrent 3.3.11. It locks up every 30-60seconds and every few hours it fully freezes without being able to unlock and I have to force close it. Then when I restart, it re-checks through terabytes of data on my drive

It's unusable at this point. I have no idea how it got so unstable. I've stayed with 3.3.11 just for the ability to use Web UI...

[BW52]

I did leave qbittorrent.Had also issues with the inbuild tracker.
I went back to Utorrent 2.2.1 which is most of the time quite satisfactory

[jeff15110168]

dang :(

[thalieht]

@jeff15110168 i believe the WebUI problem has been fixed by now. Backup these folders just to be safe https://github.com/qbittorrent/qBittorrent/wiki/Frequently-Asked-Questions#Where_does_qBittorrent_save_its_settings

[Chocobo1]

Starting in v4.1.2 there will be a new option "Enable Cross-Site Request Forgery (CSRF) protection" under WebUI tab, try uncheck it.

[jeff15110168]

Okay, will have to try that. Waiting on a few private trackers to update compatibility with latest commits too.

[Chocobo1]

Also FYI that version just released is v4.1.1, you'll need to wait for the next one.

[jeff15110168]

just wanted to update after a year - thank you so much Chocobo, I upgraded from 3.3.11 finally to 4.1.5 and after unchecking both (i) Enable Cross-Site Request Forgery (CSRF) protection and (ii) enable Host Header verification, web UI is working :)

Thank you guys for an incredible product!