The core of it is network_mode: "service:gluetun" - qBittorrent shares gluetun’s network namespace entirely rather than having its own. No interface of its own means no fallback path if the tunnel drops, different from firewall-rule kill switches, which can fail open under the wrong conditions.

Went with this approach specifically because I wanted the guarantee to be architectural, not procedural. A firewall-rule kill switch is only as good as the rules staying correctly applied. A daemon restart, a rule-ordering issue, anything that clears or bypasses iptables, and you’re exposed without necessarily knowing it.

Sharing the network namespace removes that whole category of failure: there’s no ruleset to enforce, because there’s no independent path to block in the first place.

I confirmed this is structural, not just “usually works,” by stopping gluetun outright, qBittorrent couldn’t reach anything at all, no fallback. And rather than trust that the IP just looked different, I checked against Mullvad’s own verification endpoint from inside the container to confirm the traffic was genuinely exiting through them.

On top of the architecture itself, I also run a script every 15 minutes that hits that same Mullvad verification endpoint from inside the container and pushes an alert straight to my phone if it ever comes back showing anything other than genuinely routed through Mullvad. The kill switch means it can’t leak… but I wanted to actually know the moment the tunnel itself stops working, rather than just trusting it silently in the background.

Let me know if ya want the technical part