Super slow downloads in binhex-qBittorrentvpn

As of this morning I’m getting ridiculously slow downloads where just last night I was getting 40mbps+. I have a bunch that are stalling too.

I use PIA and I do have privoxy enabled. I replaced my .ovpn file thinking that might help but no luck at all.

To test it I grabbed one of them and tried it on my metal windows machine and immediately started at 50mbps+ and climbing so I know it isn’t my internet.

Special note: I reinstalled binhex-qBittorrent this morning because I tried to enable the remote web user interface to it to use with a mobile app and as soon as I allowed the port 8080 for it, it crashed altogether without a way to get back into the GUI to disable it. I don’t need help with this, I won’t use it or try to use it again lol.

So ever since I reinstalled I’m getting these slow speeds. Link to configs below.

https://imgur.com/a/e4pogPU

Update:

  • I installed and ran openspeedtest (LAN) and got 900ish Mbps up and down.
  • I installed speedtest-tracker (WAN) and got 301.2Mbit/s.

So it has to be the docker image.

I’d use wireguard instead of openvpn, it gives me much better speeds. That binhex container supports both.

I would also suggest changing your config to use tcp only. Utp protocol is for slow connections, with a fast connection tcp only is much faster. Turn off upnp, doesn’t do anything on a vpn connection

Last, check the container logs, the final few lines should report the port number it received from pia. The script should set your torrent client to use the same port, just check to be sure. And make sure you’re using a pia location that supports port forwarding

Is there a sure way to find out if port forwarding works correctly? I don’t want to be missing out on my full speed potential.

I highly doubt it’s the docker image. It could be your NIC on the server, all the way to the cabling to your server.

Unless you’re testing them both near simultaneously it’s hard to say.

Where are you downloading to? I had similar issues and setup Deluge to download to cache and then have the isos automoved after the download completes.

Hijacking your thread to ask a question i’ve always wondered. Sorry OP!

In your advanced tab under “Network Interface” you have it set to “Any interface” does this mean it can route outside of the VPN as it’s not bound to the VPN interface? I always assumed given the routing within the container it wouldn’t but clarification from someone in the know would be great. I wouldn’t really question it but if you use the delugevpn from binhex the outgoing interface is set to “wg0” which i assume is binding it?

Anyone know?

Did you limit the upload speed in the settings of qbit?

Did you set STRICT_PORT_FORWARD in the config to yes?

Update to my previous reply to this comment. Here’s my log after changing the .ovpn file again.

Still getting about 20 KiB/s max downloads plus about 30 that are totally stalled out.

2024-01-11 17:06:42,015 DEBG ‘start-script’ stdout output:

[info] Successfully assigned and bound incoming port ‘25152’

2024-01-11 17:06:42,810 DEBG ‘watchdog-script’ stdout output:

[info] qBittorrent listening interface IP 0.0.0.0 and VPN provider IP 10.3.112.52 different, marking for reconfigure

2024-01-11 17:06:42,812 DEBG ‘watchdog-script’ stdout output:

[info] qBittorrent not running

2024-01-11 17:06:42,812 DEBG ‘watchdog-script’ stdout output:

[info] qBittorrent incoming port 6881 and VPN incoming port 25152 different, marking for reconfigure

2024-01-11 17:06:42,813 DEBG ‘watchdog-script’ stdout output:

[info] Removing session lock file (if it exists)…

2024-01-11 17:06:42,821 DEBG ‘watchdog-script’ stdout output:

[info] Attempting to start qBittorrent…

2024-01-11 17:06:42,833 DEBG ‘watchdog-script’ stdout output:

[info] qBittorrent process started

[info] Waiting for qBittorrent process to start listening on port 8080…

2024-01-11 17:06:42,941 DEBG ‘watchdog-script’ stdout output:

[info] qBittorrent process listening on port 8080

I actually turned off upnp a little bit ago after some research. I just set it to tcp only.

Confirmed the PIA location (toronto, ca) supports port forwarding and p2p as it’s all the same I was using before today when I was getting great speeds across the board.

I’ll try a new .ovpn file again though and see if it changes anything.

Udp is faster than tcp if I’m not mistaken, at least protocol wise. Can you explain why it would become slower than tcp on a fast connection?

Yeah I’m out of ideas. Everything was perfect and the only change was that I reinstalled it.

I download straight to a couple torrents/subfolders which goes from cache to the array.

I uninstalled and deleted app data again. Reinstalled and tried it without a VPN configured and it immediately started ramping up to speed.

Just added my VPN and resynced my radarr feed so and it seems to be doing better. It isn’t what it was before today but I’m at least in the hundreds of KiB/s on a handful of things now lol.

I check the app log every time I launch lol. It never really says anything out of the ordinary.

And yeah I deleted app data so it was a completely fresh install too.

As a safety measure, it’s always safest to bind the client to the VPN. If you have it set to “wg0” I believe that is wireguard, so you’d be bound to the VPN (assuming you’re using wireguard). I’d recommend using ipleak.net to test if you are connected to the VPN when torrenting via their “Torrent Address detection”. Add the torrent magnet link to the client, and it’ll show you the ip address and the port that it sees. If it matches your VPN, then you’re good to go.

That container uses iptables to make sure that you’re only using the VPN interface, so binding to the interface isn’t necessary

Yes. Ultimately I switched back to Deluge and my speeds went back to normal. No clue what was causing the issue with qBit.

Should it be yes or no?

Not UDP, but µTP