ptr78

Thank you for a very good explanation! I will also utilize a "multi-gluetun" configuration.

Could AirVPN instructions also be possible? :) So, basically auto-port-forward and separating a VPN client to its own container are the benefits of gluetun over having the VPN client and privoxy together inside, for example, a qbittorrent container?

No, I did not and I did not receive any private replies. Maybe it is something with network config but I cannot figure it out. As said it works without VPN flawlessly but with VPN it takes very long. However, curl to the test page is very fast even with VPN.

So, is there a trick to do to make the privoxyvpn network work with Byparr? I have set the VPN_INPUT_PORTS and Prowlarr can connect Byparr. But for some reason it takes a very long time to solve / retrieve the Prowlarr test page as I wrote.

Thank you for taking on this docker container also! I already tried this container but the results are the same as for FlareSolverr. That is, it works as it should if I do not route the container through the qBittorrentVPN container. However, if the traffic is routed through the qBittorrentVPN container, getting/solving the Prowlarr test page (https://prowlarr.servarr.com/v1/ping) takes several minutes. From Byparr console when traffic is routed through the qBittorrentVPN container, getting the Prowlarr test page utilizing the curl command takes only a few seconds. So, VPN is working but maybe there is something similarly wrong for both FlareSolverr and Byparr. @binhex, any ideas on this?

I have had the following setup for a very long time: Binhex qBittorrentVPN FlareSolverr routed via the qBittorrentVPN docker network Prowlarr also routed via the same qBittorrentVPN docker network I noticed that a certain site that requires FloreSolverr has not been working for me for about 2 weeks. I tried to find out what is the reason and it seems that routing the FlareSolverr via qBittorrentVPN somehow causes long delays in the network traffic. Please see the log below: Created by... ___. .__ .__ \_ |__ |__| ____ | |__ ____ ___ ___ | __ \| |/ \| | \_/ __ \\ \/ / | \_\ \ | | \ Y \ ___/ > < |___ /__|___| /___| /\___ >__/\_ \ \/ \/ \/ \/ \/ https://hub.docker.com/u/binhex/ 2025-05-04 18:51:05.045428 [info] Host is running unRAID 2025-05-04 18:51:05.064141 [info] System information: Linux 117540cbac2e 6.6.78-Unraid #2 SMP PREEMPT_DYNAMIC Thu Feb 20 13:33:15 PST 2025 x86_64 GNU/Linux 2025-05-04 18:51:05.083563 [info] Image tags: BASE_RELEASE_TAG=2024100402,IMAGE_RELEASE_TAG=3.3.21-2-01 2025-05-04 18:51:05.105010 [info] PUID defined as '99' 2025-05-04 18:51:05.200986 [info] PGID defined as '100' 2025-05-04 18:51:05.244856 [info] UMASK defined as '000' 2025-05-04 18:51:05.264793 [info] Permissions already set for '/config' 2025-05-04 18:51:05.286551 [info] Deleting files in /tmp (non recursive)... 2025-05-04 18:51:05.365048 [info] SHARED_NETWORK defined as 'yes' 2025-05-04 18:51:05.384325 [info] Starting Supervisor... 2025-05-04 18:51:05,549 INFO Included extra file "/etc/supervisor/conf.d/flaresolverr.conf" during parsing 2025-05-04 18:51:05,549 INFO Set uid to user 0 succeeded 2025-05-04 18:51:05,551 INFO supervisord started with pid 7 2025-05-04 18:51:06,553 INFO spawned: 'flaresolverr' with pid 62 2025-05-04 18:51:06,553 INFO reaped unknown pid 8 (exit status 0) 2025-05-04 18:51:06,818 DEBG 'flaresolverr' stdout output: 2025-05-04 18:51:06 INFO FlareSolverr 3.3.21 2025-05-04 18:51:06 INFO Testing web browser installation... 2025-05-04 18:51:06,818 DEBG 'flaresolverr' stdout output: 2025-05-04 18:51:06 INFO Platform: Linux-6.6.78-Unraid-x86_64-with-glibc2.40 2025-05-04 18:51:06,819 DEBG 'flaresolverr' stdout output: 2025-05-04 18:51:06 INFO Chrome / Chromium path: /opt/flaresolverr/chrome/chrome 2025-05-04 18:51:06,945 DEBG 'flaresolverr' stdout output: 2025-05-04 18:51:06 INFO Chrome / Chromium major version: 123 2025-05-04 18:51:06 INFO Launching web browser... 2025-05-04 18:51:07,945 INFO success: flaresolverr entered RUNNING state, process has stayed up for > than 1 seconds (startsecs) 2025-05-04 18:55:44,020 DEBG 'flaresolverr' stdout output: 2025-05-04 18:55:44 INFO FlareSolverr User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/123.0.0.0 Safari/537.36 2025-05-04 18:55:44 INFO Test successful! 2025-05-04 18:55:44,026 DEBG 'flaresolverr' stdout output: 2025-05-04 18:55:44 INFO Serving on http://0.0.0.0:8191 2025-05-04 19:01:53,725 DEBG 'flaresolverr' stdout output: 2025-05-04 19:01:53 INFO Incoming request => POST /v1 body: {'maxTimeout': 60000, 'cmd': 'request.get', 'url': 'https://prowlarr.servarr.com/v1/ping', 'proxy': {}} 2025-05-04 19:04:18,690 DEBG 'flaresolverr' stdout output: 2025-05-04 19:04:18 INFO Challenge not detected! 2025-05-04 19:06:35,285 DEBG 'flaresolverr' stdout output: 2025-05-04 19:06:35 INFO Response in 281.559 s 2025-05-04 19:06:35,285 DEBG 'flaresolverr' stdout output: 2025-05-04 19:06:35 INFO 127.0.0.1 POST http://localhost:8191/v1 200 OK As one can see it takes about 4.5 minutes to perform the test when FlareSolverr is started. Additionally, it takes almost 2.5 minutes when I try to create the FlareSolverr indexer proxy in Prowlarr. It fails in Prowlarr as the timeout limit is not met. I am aware that FlareSolverr is not working anymore for most of the users but this is different as also the startup test takes so much time. Additionally, this has worked for me until this strange behaviour started and I have not updated FlareSolverr for at least 6 months. If I change the network to bridge the startup test is passed instantly. So, it seems that something has changed how qBitTorrentVPN or Unraid handles the traffic routed via the qBittorrentVPN docker. Has anybody else faced anything like this? How could this be fixed? Thank you!

This info was very much appreciated, thank you!

Further, is it even possible to setup this so that I can access the docker containers from the server itself / server console?

I have a custom network (VLAN 9) defined for docker containers. I am able to access the docker containers from outside of my Unraid server. However, I cannot reach them from Unraid console (no route to host). Output of the route command: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.3.1 0.0.0.0 UG 1007 0 0 br0 172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0 172.31.200.0 0.0.0.0 255.255.255.0 U 0 0 0 br-bf45fa35cdfc 192.168.3.0 0.0.0.0 255.255.255.0 U 1007 0 0 br0 192.168.8.0 0.0.0.0 255.255.255.0 U 0 0 0 br0.8 192.168.9.0 0.0.0.0 255.255.255.0 U 0 0 0 br0.9 192.168.122.0 0.0.0.0 255.255.255.0 U 0 0 0 virbr0 Should I add another route to enable access also from the Unraid server to the docker containers or is the above route to br0.9 somehow wrong? I need to access the containers both from the Unraid server and from outside of it. Thank you!

OK. So, "removing the user template" means that I need to remove the docker and then reinstall it from CA?

Please, find attached a screenshot that shows what can be seen by clicking "Show more settings..."

It only shows 'AppData Config Path:' and it has been there from the beginning when I installed the docker.

I noticed that the "settings page" for this docker container has changed since I installed it. When I select 'Edit' it does not show the new variables such as "Path: /shared". What is the best practice to update the docker so that the latest set of variables will be visible? Thank you for any help!

Does this cause a security issue or are CRLs handled as they should (AirVPN) with this openssl version?

After some digging I found this: https://github.com/qbittorrent/qBittorrent/issues/17545#issuecomment-1232810370 @binhex, is the latest docker built using the libtorrent 1.2.x?

Has the issue with libtorrent 2.x been fixed yet (crashes-since-updating-to-v611x-for-qbittorrent-and-deluge-users)? I'm still on v4.3.9 but would prefer to use a more recent release. The "hugepages" fix didn't work for me. Thank you for any info!

Regarding DNS-definition found this from AirVPN Specs (https://airvpn.org/specs/ ) So, would it be possible to implement a feature which replaces an original DNS server definition in /etc/resolv.conf after the OpenVPN client has started successfully? That is, first using for example 1.1.1.1 when connecting to a VPN server and after the connection has been made successfully replace DNS server definitions with another definitions (here 10.4.0.1). Even better would be if the new DNS server definition could be dynamically set as the ip address returned by getvpnextip.sh.

This worked, thank you!!

I'm using AirVPN and have the same issue. I'm still on 4.3.9-2-01 and for few weeks on Unraid 6.11.5. Torrents load OK, only the traffic via the proxy doesn't work as it should. Did you find any solution other than not using the proxy? @binhex, is this something you have heard before?

Clearing the browser cache did the trick. Oh well, should have done that immediately...

OK, good, thank you! I was wondering that after setting the location, will qbittorrent move files to the default save directory after a file download has been completed. Are you or anyone else having the issue of empty status info / tabs?

First of all, thank you for a very fast response! Do you know how can I return the incomplete torrents to their correct directory?

Hi, I did an update from 4.3.9-2-01 to 4.4.5-2-02 and had the following issues The settings were reset default values. Unfinished download were moved from incomplete torrents directory to the default save path. How can this be corrected? I noticed that the "status tabs" (i.e., General, Trackers, Peers, HTTP Sources and Content) remain empty for all the torrents. In 4.3.9 this showed torrent related info normally. Has anybody else had these issues with any 4.4.x version of the software? Thank you for any help!

I'm still on version 4.3.9-2-01. @binhex, I remember that earlier you were also waiting before upgrading from that version. Have you since upgraded and what version are you currently using? Thank you for the info!

Solved. Rebooted the desktop computer where I was connected to the Unraid Server and the log file entries stopped to be generated. So, it was something on there.