When using a VPN, will leak your IP address. Use https://ipleak.net/ to check. It'll show your VPN IP address, home ip address, and your IP address will leak your client information. Even if you bind it to the right bindings in the settings it'll still randomly do this.
When I saw that in the ipleak after seeding something to my private server I was in awe; that good software like this would allow something like that.
I think you mean proxy, not VPN? AFAIK qBittorrent doesn't natively do any kind of VPN stuff, so the issue would be elsewere, since it shouldn't be possible if configured properly.
If we're actually talking proxies: If you enable UDP-based protocols, it's very hard to avoid IP leaking. A surprising amount of clients just don't support proxying UDP at at all, or misbehave in various ways.
Word of advice: Set up the torrent client in a dedicated VM (or box) and set it up on kernel-level to route all its traffic through a separate VM(/box), which itself connects to the VPN (Wireguard,OVPN or what-have-you) and forwards traffic. It sounds complex but is robust and avoids a lot of potential pitfalls.
Reliably routing P2P UDP traffic with container networks is a fool's errand so I wouldn't recommend Docker networks (ofc fine to run the container with network=host tho)
This is concerning claim, but I checked it all out and have verified my IP is not being leaked (that is a neat site BTW, thanks for sharing).
I will say, I don’t have a ‘standard’ setup with qBittorrent and a VPN provider, so I’ll share some details in hopes that it will be useful to someone.
I use qBittorrent in headless mode with the web interface- so it’s running on a little server within docker. The docker compose has two services, one WireGuard (lscr.io/linuxserver/wireguard) the other qBittorrent (lscr.io/linuxserver/qbittorrent). The qBittorrent service has ‘network_mode: service:WireGuard’ so that it uses the WireGuard network. I’ve got WireGuard all setup with my VPN provider.
While all that should theoretically be all you need, I also configure qBittorrent to use my VPN’s SOCKS5 proxy. This acts as a great safeguard, if the VPN isn’t functioning, then the proxy auth will fail and will act as a kill switch to qbittorrent. Be sure to configure qBittorrent to use the proxy for everything (I can’t remember if this is default or not).
You shouldn't need any kind of "kill switch" for qBittorrent: normally when you set up a VPN (I use OpenVPN for reference), on Linux you get a new network device, usually called "tun0". In qBittorrent, you can specify the network device to use, rather than just letting it automatically select one. So set this to "tun0", and it'll only pass traffic over this virtual device; if something goes wrong with the VPN, qBittorrent will just be sending packets into the void.
I think this can be fixed by first understanding that a VPN is a proper network.
You do not have to rely on the qbittorrent client to do any proxying. Turn that setting off.
A wireguard VPN is literally a network that you can route traffic through. If you can somehow force qbittorrent to route all its traffic through a wireguard interface and not your wifi/eth interface, you wont need the proxy settings as your IP will be hidden by virtue of you using the wireguard network rather than your home network.
Note that this can still leak traffic like DNS requests via domain sockets that connect to a handler outside the namespace. The New Namespace Solution on that page should prevent that I think if you want to route all traffic through the vpn by default.
Transmission is also great for this. You can run it completely headless, or you can run the GUI locally and connect via web interface remotely. It's very flexible and has been great to work with.
Probably best there is, altho I have a nitpick: they dont allow remembering my choice to "Download first and last pieces first" and "Download in sequential order". Even after raising a PR request Ive been told that allowing users to select that would be harmful for torrent health. Jeez, dont assume you know my usecase, I can guarantee that even if 50% of users had this enabled, torrents would be just fine. They could even hide the option to remember these two settings somewhere deep, but no... if I want it, I am supposed to build from source. ..
Personally I've always found deluge to be slow, buggy, and prone to crashing. It also is much more simplistic. It's been a long time since I've used it so I can't remember offhand what features it's missing. I just remember it not being a power-user application.
It's fine, I guess. QBittorrent is just much more powerful and stable.
When using a VPN, will leak your IP address. Use https://ipleak.net/ to check. It'll show your VPN IP address, home ip address, and your IP address will leak your client information. Even if you bind it to the right bindings in the settings it'll still randomly do this.
When I saw that in the ipleak after seeding something to my private server I was in awe; that good software like this would allow something like that.
I think you mean proxy, not VPN? AFAIK qBittorrent doesn't natively do any kind of VPN stuff, so the issue would be elsewere, since it shouldn't be possible if configured properly.
If we're actually talking proxies: If you enable UDP-based protocols, it's very hard to avoid IP leaking. A surprising amount of clients just don't support proxying UDP at at all, or misbehave in various ways.
Word of advice: Set up the torrent client in a dedicated VM (or box) and set it up on kernel-level to route all its traffic through a separate VM(/box), which itself connects to the VPN (Wireguard,OVPN or what-have-you) and forwards traffic. It sounds complex but is robust and avoids a lot of potential pitfalls.
Reliably routing P2P UDP traffic with container networks is a fool's errand so I wouldn't recommend Docker networks (ofc fine to run the container with network=host tho)
This is concerning claim, but I checked it all out and have verified my IP is not being leaked (that is a neat site BTW, thanks for sharing).
I will say, I don’t have a ‘standard’ setup with qBittorrent and a VPN provider, so I’ll share some details in hopes that it will be useful to someone.
I use qBittorrent in headless mode with the web interface- so it’s running on a little server within docker. The docker compose has two services, one WireGuard (lscr.io/linuxserver/wireguard) the other qBittorrent (lscr.io/linuxserver/qbittorrent). The qBittorrent service has ‘network_mode: service:WireGuard’ so that it uses the WireGuard network. I’ve got WireGuard all setup with my VPN provider.
While all that should theoretically be all you need, I also configure qBittorrent to use my VPN’s SOCKS5 proxy. This acts as a great safeguard, if the VPN isn’t functioning, then the proxy auth will fail and will act as a kill switch to qbittorrent. Be sure to configure qBittorrent to use the proxy for everything (I can’t remember if this is default or not).
You shouldn't need any kind of "kill switch" for qBittorrent: normally when you set up a VPN (I use OpenVPN for reference), on Linux you get a new network device, usually called "tun0". In qBittorrent, you can specify the network device to use, rather than just letting it automatically select one. So set this to "tun0", and it'll only pass traffic over this virtual device; if something goes wrong with the VPN, qBittorrent will just be sending packets into the void.
I think this can be fixed by first understanding that a VPN is a proper network.
You do not have to rely on the qbittorrent client to do any proxying. Turn that setting off.
A wireguard VPN is literally a network that you can route traffic through. If you can somehow force qbittorrent to route all its traffic through a wireguard interface and not your wifi/eth interface, you wont need the proxy settings as your IP will be hidden by virtue of you using the wireguard network rather than your home network.
Assuming this is true, one way you could mitigate is to place it into a network namespace where the only available interface is the one you want your program to use. e.g. https://www.wireguard.com/netns/#ordinary-containerization
Note that this can still leak traffic like DNS requests via domain sockets that connect to a handler outside the namespace. The New Namespace Solution on that page should prevent that I think if you want to route all traffic through the vpn by default.
Also contains a headless server named qbittorrent-nox. I use it in my server.
qbittorrent + gluetun works like magic (if you’re running containers).
https://github.com/qdm12/gluetun
Transmission is also great for this. You can run it completely headless, or you can run the GUI locally and connect via web interface remotely. It's very flexible and has been great to work with.
Deluge was my go-to for this for years and years and years. More diversity in this ecosystem is good to see
I'm a fan of aria2c [1] in server mode paired with a lightweight WebUI [2].
Works really well on a small machine. Start aria2 as a service in systemd tied to a user with some basic isolation (or put it in a Docker container!)
[1] https://github.com/aria2/aria2 [2] https://github.com/mayswind/AriaNg
Probably best there is, altho I have a nitpick: they dont allow remembering my choice to "Download first and last pieces first" and "Download in sequential order". Even after raising a PR request Ive been told that allowing users to select that would be harmful for torrent health. Jeez, dont assume you know my usecase, I can guarantee that even if 50% of users had this enabled, torrents would be just fine. They could even hide the option to remember these two settings somewhere deep, but no... if I want it, I am supposed to build from source. ..
Have you ever considered that you may be wrong and this would actually be a bad feature?
But I'm sure you know more about the technical details of torrenting than the QBittorrent developers.
Even if I always seed 5x?
How is this better from indestructible Deluge?
Personally I've always found deluge to be slow, buggy, and prone to crashing. It also is much more simplistic. It's been a long time since I've used it so I can't remember offhand what features it's missing. I just remember it not being a power-user application.
It's fine, I guess. QBittorrent is just much more powerful and stable.
I've been using this for years since uTorrent went to shit. I can't recommend it enough.
out of the loop here, what happened to utorrent?
Monetization happened to utorrent.