Why binding beats relying on a kill switch
A kill switch is reactive. Something has to notice the tunnel died and then block traffic, and between the death and the noticing there is a window. On an unstable connection that window recurs every time the tunnel renegotiates, and a torrent client is precisely the software that will use it, because it is always trying to talk to somebody.
Interface binding is structural. You tell qBittorrent that one specific adapter is the only one it may use. If that adapter disappears, there is nothing to fall back to — the client simply cannot send. No detection, no race, no window.
They are complementary rather than alternatives, and you should run both. The kill switch protects everything else on the machine; binding protects the one application most likely to exploit a gap.
Doing it, step by step
Connect the VPN first. The adapter has to exist before qBittorrent can list it.
Go to Tools → Options → Advanced. Scroll to the qBittorrent section and find "Network interface" - it sits below the storage and cache settings rather than at the top of the page. Change it from "Any interface" to your VPN adapter. WireGuard connections usually appear under the provider name or as "WireGuard Tunnel"; OpenVPN typically shows as a TAP or TUN adapter.
Below it is "Optional IP address to bind to". Leave it on "All addresses". Pinning one specific address breaks silently whenever the tunnel is reassigned a new one, and it does nothing to stop IPv6 escaping from anything else - handle IPv6 in the VPN client or the operating system, not here.
Apply, then verify. Disconnect the VPN with a torrent running. Transfers should stall immediately and the tracker status should show stalled or an error. If anything keeps downloading, the binding did not take.
- Tools → Options → Advanced → Network interface → select the VPN adapter
- Leave "Optional IP address to bind to" on All addresses, or pick IPv4 to exclude IPv6
- Test by disconnecting the VPN with an active transfer and confirming it stalls
The adapter-name problem, and how to survive it
Current qBittorrent stores the interface by name and refuses to listen when that adapter is missing, which fails closed - the behaviour you want. The fragile part is the separate bind-to-IP-address setting: pin one specific address and it goes stale every time the tunnel is assigned a new one, and the client stops working with no obvious cause. Much older builds did revert to Any interface, so on anything ancient, verify rather than assume.
Check the setting after any client update, and after any reboot where the VPN reconnected differently. If it reads "Any interface" again, it reverted while you were not looking.
The stronger version of this defence is a firewall rule blocking qBittorrent from sending on any interface other than the tunnel, enforced by the operating system rather than inside the application. It survives client updates and adapter churn, at the cost of being more work to set up.
Avoid
- Setting the binding while the VPN is disconnected — the adapter will not be listed
- Assuming it stays set; verify after updates and reboots
- Binding to the physical adapter by mistake, which achieves the exact opposite
Port forwarding, and why your speeds may still disappoint
With the client bound and the tunnel up you are protected, but possibly passive. Without an inbound port your client can only connect to peers that accept incoming connections; peers behind their own NAT cannot reach you. On a well-seeded torrent you will not notice. On anything sparse, you will.
Of the four providers we cover, Proton VPN includes port forwarding in the subscription. PureVPN and FastestVPN sell it as a paid add-on. NordVPN does not offer it at all, so a bound qBittorrent on NordVPN will always run passive.
How you set the port depends on the provider, and getting this backwards is the usual way people break it. Proton VPN hands out its forwarded port over NAT-PMP on a short lease that has to be renewed, so NAT-PMP must stay ON and there is no port for you to type in. Where a provider gives you a fixed port in its dashboard instead, put that in Options → Connection and turn UPnP/NAT-PMP off, so the client is not also trying to map a port through your own router.