Hello people

I have a problem with speed in my qbittorrentvpn container. i have a 2.5 gbps connection, and the problem is that im only able to reach about half. I tried to set another internal ip than the bridge, and that helped a little, but now i went back to bridge (because of other issues), which took a little of the speed. I use protonvpn..

I tried to test the Hdds and ISP connection so i tested using sabnzbd and im getting full speed there..

So where is the problem.??

Thank you

VPNs often limit to 1Gbit per user.

Getting that on torrents usually means many simultaneous connections and some routers can't cope with that load either.

Edited September 26Sep 26 by Kilrah

On 9/25/2026 at 1:37 PM, ccwod said:

I just noticed this issue on my configuration too, using the Wireguard configuration. I was using ca toronto with port forwarding. Toronto is still on the binhex list of published endpoints (updated today, 9/25), but the container logs say that it's not part of the list anymore. I also tried the ...pvt.site version which also didn't work. I changed the Endpoint line in wg0.conf to ca-montreal.privacy.network:1337 and got it going again.

I had same issues and used ca-toronto.pvt.site as the endpoint

4 minutes ago, tooviral said:

I had same issues and used ca-toronto.pvt.site as the endpoint

The list is provided by PIA. I would recommend contacting them about this.

hey guys, need your help on this one. This was working couple of days ago but after I restarted my docker container, I'm seeing this. Seems like wireguard issue?
my credentials are correct.

supervisord.log

Edited Sunday at 11:12 PM5 days by gwapong_bata
updated log

1 hour ago, gwapong_bata said:

hey guys, need your help on this one. This was working couple of days ago but after I restarted my docker container, I'm seeing this. Seems like wireguard issue?
my credentials are correct.

supervisord.log

Having the exact same issue as you

1 hour ago, gwapong_bata said:

hey guys, need your help on this one. This was working couple of days ago but after I restarted my docker container, I'm seeing this. Seems like wireguard issue?
my credentials are correct.

supervisord.log

Just now, loyalsnoopdoge said:

Having the exact same issue as you

Several people have reported that PIA has changed the url for the endpoints they are using. I would suggest trying a different one.

1 minute ago, wgstarks said:

Several people have reported that PIA has changed the url for the endpoints they are using. I would suggest trying a different one.

I checked my configured endpoint against PIA’s current server list: switzerland.pvt.site is still listed. The failure occurs earlier, while fetching a token from www.privateinternetaccess.com/gtoken/generateToken and that request returned HTTP 504 from both my server and laptop

3 minutes ago, loyalsnoopdoge said:

I checked my configured endpoint against PIA’s current server list: switzerland.pvt.site is still listed.

Yes, that matches earlier reports. Changing endpoints may not fix the problem but it’s an easy test.

13 minutes ago, wgstarks said:

Yes, that matches earlier reports. Changing endpoints may not fix the problem but it’s an easy test.

tried several others same issue, but it just magically started working again

1 hour ago, loyalsnoopdoge said:

tried several others same issue, but it just magically started working again

Perhaps the server was down???

I was having an issue yesterday that I was able to solve, but couldn't find much help searching. Google does index this thread so I wanted to post for the benefit of others:

I've been using this container for years with almost no issues, but yesterday a problem emerged where the container would hang/fail silently during startup after the log message "script finished to assign incoming port". At first I thought this might have been a problem with having too many torrents open because that had caused the container to get progressively slower in the past.

I also suspected a DNS issue because of the way qBittorrent was behaving prior to me restarting it. It sounds like some of the other commenters are talking about a potential PIA issue occurring yesterday as well, which may have been part of the problem as I am also a PIA user.

It turned out that I may have had my container misconfigured all this time. I had STRICT_PORT_FORWARD set to 'yes', but I don't think I've ever needed or used that functionality (again, it's been several years running this container with minimal issues and I may have forgotten). As I recall, the log messages have always complained that my chosen VPN region did not support port forwarding, but it always worked anyway so there was no need to fix something that wasn't broken.

EDIT/UPDATE: It turned I did actually need port forwarding for one of the trackers I use, though this is somewhat irrelevant because it did (apparently) solved the hanging issue, though I don't want to be bothered restarting the container to be sure at the moment. I expect I can probably just tamper with the .ovpn file to open the port but that's a project for another day. I just wanted to update my message for completeness.

Setting STRICT_PORT_FORWARD to 'no' solved the problem. As an added bonus, the container now starts much faster than it usually does. That may be due to clearing out a rather large log file that had accumulated and/or some other housekeeping step I took while trying to figure this out.

What caused this problem to emerge now rather than any other time remains a mystery. It's possible the issue the other commenters are describing was the catalyst, although the log messages didn't indicate anything that led me in the direction of a PIA outage. I had used an interactive terminal to check DNS from within the container and it seemed to be working correctly.

And just as a post-script: Thanks for such an easy to use torrent client for Unraid. When I first got set up years ago it would have been well beyond my capability to DIY anything like this from scratch. I appreciate you.

Edited Wednesday at 02:56 AM2 days by nft2

I also have the same issue, it can't fetch the token, I believe this is the reason why:-

The error occurs because Private Internet Access (PIA) disabled the gtoken/generateToken endpoint on September 27, 2026, causing it to return 504 errors or timeouts.

To resolve this, you must update your VPN container (e.g., binhex, gluetun, or delugevpn) to use the new v2 API endpoint.

• Endpoint Change: Switch the token generation URL from https://www.privateinternetaccess.com/gtoken/generateToken to https://www.privateinternetaccess.com/api/client/v2/token.

• Container Updates: Update your Docker container images to the latest versions, as recent patches (such as PR #58 in binhex/arch-int-vpn) have implemented this v2 API fallback.

• Manual Fixes: If using custom scripts, modify wireguard.sh and getvpnport.sh to point to the /api/client/v2/token route.

Edited Monday at 10:02 PM4 days by ollieuk
removed from quote

17 hours ago, wgstarks said:

Perhaps the server was down???

Still problematic or me so I dont think so.

1 minute ago, Olick said:

Still problematic or me so I dont think so.

And did you try another server?

Just now, wgstarks said:

And did you try another server?

Tried ca-toronto.pvt.site like the guy mentioned above, doesnt work.
Same with ca-montreal.privacy.network

I'm having a problem with QBit where it keeps causing the unraid GUI to crash. It still pings but dockers dont work either. Could this be a CPU leak?

my qbit stopped working last week Sept 22. Now I can't even access the UI. Is that a sign that I am having the same VPN issues others mentioned from openvpn? I did have the ca_torontoa .ovpn file in my config file but even swapping it to another file I still have the same issue.

38 minutes ago, BartyB said:

my qbit stopped working last week Sept 22. Now I can't even access the UI. Is that a sign that I am having the same VPN issues others mentioned from openvpn? I did have the ca_torontoa .ovpn file in my config file but even swapping it to another file I still have the same issue.

It’s a sign that the app probably failed to start. If you want help with this attach your supervisord log and docker run command to your next post. Be sure to redact users/passwords.

I had the same issue as many people here over the past few days, where the PIA VPN failed to start up in a timely manner.

I found a fix posted by zaraki here on this github issues page: https://github.com/binhex/arch-qbittorrentvpn/issues/378

After editing it into the tools shell script of the binhex-qbittorrentvpn container everything is back to normal with smooth and quick connection of the vpn again.

On 9/28/2026 at 4:01 PM, Cicero said:

I'm having a problem with QBit where it keeps causing the unraid GUI to crash. It still pings but dockers dont work either. Could this be a CPU leak?

For the purposes of helping you I'm going to assume by "crash" you mean its hanging or becoming inaccessible. If you follow up with an answer try to explain the problem clearly (not intending to be rude but I'm about to explain quite a bit based on a guess of what you meant). I'm also assuming that you mean all the other Docker containers on your system are hanging, or the Docker page and/or entire Unraid GUI is slow.

I had the problem as I described it earlier this year and the issue was that qBittorrent was hogging a ton of FUSE descriptors. This is a problem that emerged over time because a fresh server with no torrents doesn't have many files it's accessing, so even a poorly-configured setup like mine was fine for several years. The other part of the problem (the configuration issue) was that it was a mistake to use the FUSE abstraction for qBittorrent's AppData Config Path (Docker > qBittorrent/Edit > Scroll to the bottom and uncollapse "Show more Settings").

As far as I'm aware, that statement is true for any Docker container if you have a cache drive on which your Dockers reside. It's probably true if you don't as well. From memory, I think you can tell if it's using the FUSE abstraction layer if the path is something like /mnt/user/cache/appdata/binhex-qbittorrentvpn. You want to change it to the non-abstracted path, which in this case would be /mnt/cache/appdata/binhex-qbittorrentvpn.

Note that if you do this and you had a badly configured setup like mine, you may need adjust your cache share to move the files from Array BACK to the Cache, which sounds strange but it allows the system to marshal all the randomly distributed Docker-related files back to where they need to be. The alternative is simply starting fresh with a new, correctly configured qBittorrent install and not worrying about it.

This was a real head-scratcher to figure out when it happened to me, so I hope this helps you or someone else who encounters this post.

PIA VPN failed to start hot fix that worked for me, figured I would share it with everyone else that comes looking until binhex has a perm fix

corrected copy of tools.sh

https://github.com/TRusselo/arch-int-vpn/blob/3f6f0f83a11db712a3781035f9644af789b3f568/run/local/tools.sh

bind-mount corrected tools.sh method:

corrected copy of tools.sh goes here:

/mnt/user/appdata/binhex-qbittorrentvpn/tools.sh

1. edit the binhex-qbittorrentvpn container in the Unraid GUI.

2. Go to: Docker → binhex-qbittorrentvpn → Edit

3. At the bottom choose:

Add another Path, Port, Variable, Label or Device

Configure it as:

Config Type:

Path

Name:

tools.sh Fix

Container Path:

/usr/local/bin/tools.sh

Host Path:

/mnt/user/appdata/binhex-qbittorrentvpn/tools.sh

Access Mode:

Read Only

Edited 3 hours ago3 hr by Docshaker

3 minutes ago, Docshaker said:

until binhex has a perm fix

corrected copy of tools.sh

It’s already merged in latest release.