How to Bind qBittorrent to a VPN Interface on macOS

I opened qBittorrent on a Mac mini, set Network Interface to utun4, restarted, and then spent an afternoon watching a torrent sit on retrieving metadata while the VPN still showed a healthy connection. The setting was not wrong in principle; the name was stale. macOS assigns utun numbers as services start, so the utun4 that had been correct the week before pointed at a tunnel that no longer existed, and the client was binding its sockets to a device with no route. The sequence below is what I use now: read the interface from the running tunnel, select it in the client, restart the session, and then prove the bind with a transfer and a deliberate disconnect.

Open Advanced and find the interface field

In the qBittorrent window, open Preferences with Cmd+, and go to the Advanced page. Network Interface is the field that matters: it lists the system's interface names and defaults to Any Interface, which means the operating system picks a route for each socket the client opens. The project's options reference documents the field and that default, and it is the same setting on every platform even though the names inside it are not.

Two details trip people up here. The list shows device names such as en0, en1 and utun0 through utun9, never the VPN provider's product name, so you need the mapping before you can choose anything sensible. And the selection is applied when the BitTorrent session starts, not at the moment you press OK, so a change that looks saved may still be running on the old bind.

Quit the application properly with Cmd+Q and confirm the process is gone before you reopen it. Closing the window only hides it, and a hidden client keeps its session, its listening port and its old interface.

pgrep -fl qbittorrent

Find the interface your VPN actually owns

Connect the VPN first, through the provider's own client, and then read the system's view instead of the client's menu. The commands below list every interface with its addresses, show which ones the system treats as active, and print the routing table; you are looking for the utun device that carries the private range your provider hands out.

ifconfig -a | grep -A4 '^utun'
scutil --nwi
netstat -rn -f inet | head -n 5

Three readings tell you which device is the tunnel. The utun entry needs an inet address that belongs to the VPN's pool. scutil --nwi shows which interfaces the system considers active and which one is primary. netstat -rn shows where the default route points, and if that route still points at en0 while a utun has an address, the tunnel is not carrying all traffic, which changes what the bind will do later.

When two tunnels can exist at once, for example a work profile and a personal one, both utun devices are present and only one of them is useful. Byte counters settle the question: note the counters, load a page or start a small transfer, and see which one moved.

netstat -ib | grep utun

Do not treat the number as stable, either. A reconnect can hand the same tunnel a different utun name, and an iCloud or Continuity service can hold utun0 long before your VPN connects.

Match the bind to the tunnel's scope

The field binds a device, and that is all it does. If the VPN is a full tunnel that routes 0.0.0.0/0 into the utun, binding to that device sends every peer connection and tracker request through the VPN. If the VPN is a split tunnel that only routes a few subnets, binding to the utun sends peer traffic to a device with no route for those peers, and transfers stop instead of leaking. Both outcomes are safer than Any Interface, but only one of them keeps the client working. Nothing outside the client changes: browsers and other apps keep their own routes, so a requirement covering every application needs enforcement from the VPN side.

Read the situation before you select anything:

Address family matters as well. A provider that assigns only IPv4 leaves the bound interface with no IPv6 address, so IPv6 peers fail rather than slipping out over Wi-Fi. Separately, binding sockets does not pin name resolution: tracker hostnames are resolved through the macOS resolver, which follows the system's DNS configuration rather than the selected device.

Three ways a correct-looking selection fails

The first failure is not restarting. The field shows utun4, the preferences look configured, and a test transfer still leaves over Wi-Fi because the running session kept the old bind. Quit fully, confirm with pgrep, reopen, and start the transfer again.

The second is the stale name after a reconnect. Once the bound device disappears, peer connections fail and the client tends to report tracker errors rather than a clean interface-gone message, which reads like a dead torrent. Re-read ifconfig, reselect the new name, and restart.

The third is assuming the bind fails closed. Selecting an interface asks the system to attach sockets to a device name; what happens when that name is missing or recycled is not something the settings screen guarantees. The disconnect test in the next section is the only evidence that counts.

Verify with a real transfer and a disconnect

Use a transfer you are allowed to run, such as a Linux distribution image, and start it with the VPN connected. Watch the per-interface counters before and after, and compare them with the VPN client's own data counter; both should climb together while the peer list fills.

netstat -ib | grep utun
pgrep -fl qbittorrent

Then disconnect the VPN from its own interface and watch the transfer. Peers should drop away, and new connections should fail shortly after the tunnel goes down. If throughput continues, the bind is not in effect and you are back at the restart step, not at the firewall.

Reconnect and check the selected name again, because the tunnel may come back under a different utun. A short note recording the tunnel type, the interface name, and the expected behaviour when the VPN drops saves the next session: this setting is per machine and per provider, and it survives neither a client upgrade nor a change of VPN app.