A practical Docker and WireGuard design that keeps qBittorrent on the VPN while Plex, storage and NAS management stay on stable routes.
Isolate qBittorrent behind the VPN
Use Gluetun or a selected provider WireGuard network for qBittorrent instead of routing the entire NAS through the commercial VPN. Bind qBittorrent to the intended interface where practical and test that traffic stops when the tunnel fails.
What qBittorrent VPN setup do you need?
Select the outcome you actually need. The right architecture changes when the goal is private remote access, outbound privacy, container isolation or Plex stability.
Need a NAS for qBittorrent and Docker? Current listings
Compare current NAS systems for download workloads, Docker, storage growth and media automation.
Prices and availability are pulled from Cloudzat’s existing Amazon catalogue and can change. As an Amazon Associate, Cloudzat earns from qualifying purchases.
Why qBittorrent is better isolated than the whole NAS
A qBittorrent workload is a good example of why NAS VPN routing should be selective. The torrent client may need a commercial VPN public IP, while Plex, SMB, backups, Tailscale and the NAS management interface usually need ordinary local or remote-access routes. Sending the entire NAS through a provider VPN can break Plex remote access, make local services harder to reach and turn a VPN outage into a storage outage. Isolating qBittorrent behind its own VPN gateway gives the privacy-sensitive workload the tunnel without changing the identity of the whole server.
On Docker-capable systems, Gluetun is one of the cleanest ways to create that boundary. qBittorrent shares Gluetun's network namespace, Gluetun owns the VPN connection and firewall, and the qBittorrent Web UI is published through the gateway on the trusted LAN. Unraid users can also use native VPN Manager with a provider WireGuard configuration. The objective in either design is the same: torrent traffic uses one controlled route and cannot fall back silently to the normal WAN.
Gluetun plus qBittorrent: the basic network model
With Docker Compose, qBittorrent can use `network_mode: "service:gluetun"` when both services are defined in the same project. In other management systems, the equivalent is sharing the Gluetun container network namespace. Once qBittorrent does this, it no longer owns its normal independent Docker network. DNS, the public IP and internet egress are controlled by Gluetun.
That changes how you publish the Web UI. The qBittorrent management port needs to be mapped on Gluetun because the gateway owns the shared network namespace. This is a local Docker port mapping, not VPN-provider port forwarding. Keep the Web UI restricted to the LAN or a private Tailscale network. There is no reason to expose the administration interface to the public internet just because torrent peer traffic is traveling through an encrypted provider tunnel.
Bind qBittorrent to the VPN interface as an extra safeguard
The qBittorrent project maintains guidance for binding the client to a specific network interface as a leak-prevention measure. In the application, the setting is under Tools, Options, Advanced and Network Interface. The exact interface visible inside a Gluetun-shared namespace can depend on the tunnel method and container environment, so verify the active interface before selecting it rather than copying a name from another user's screenshot.
Interface binding is defense in depth. The primary boundary should still be the VPN gateway firewall and Docker network design. Binding helps make the application's intent explicit and can prevent accidental use of a different interface in configurations where more than one path is visible. After binding, restart qBittorrent and confirm it still connects only when the VPN path is available.
Test the public IP from inside the qBittorrent path
Do not assume qBittorrent is protected because the Gluetun logs say “connected.” Verify the public IP from inside the same network namespace used by the torrent client. It should match the VPN provider rather than the home's ISP address. Check DNS behavior as well, because DNS queries can reveal a different path from application traffic if the stack is misconfigured.
The critical test is failure. Stop Gluetun or disable the provider WireGuard tunnel and confirm qBittorrent cannot reach the internet. It should not simply resume traffic through the NAS's ordinary WAN interface. Restart the VPN and verify recovery. Repeat this after major NAS, Docker or container-image updates because networking behavior can change across versions.
Surfshark works well for outbound qBittorrent traffic
Surfshark is directly supported by Gluetun with WireGuard and OpenVPN. That makes it a practical option when the main goal is to route qBittorrent's outbound connections through a commercial VPN without installing a provider desktop app on the NAS. WireGuard is generally the first protocol worth testing for efficient headless deployments, while OpenVPN can remain a compatibility fallback.
The important limitation is port forwarding. Surfshark does not provide normal VPN-side port forwarding. qBittorrent can still make outbound connections and download or upload through established peer sessions, but it will not receive a provider-assigned forwarded inbound port. If maximal peer reachability or seeding performance depends on a forwarded port, compare a provider that explicitly supports it rather than expecting Docker or Gluetun to create that capability.
Provider-side port forwarding can improve peer reachability
Torrent clients participate in a peer-to-peer network, and having a reachable inbound port can improve the set of peers that can initiate connections to the client. It is not the same requirement as opening the qBittorrent Web UI. The Web UI should remain private. The forwarded peer port exists on the VPN side and is supplied by the provider when supported.
Gluetun documents VPN server port forwarding separately and has provider-specific integrations for supported services such as Proton VPN and Private Internet Access. If you use one of those providers, the forwarded port may be dynamic and the application may need to be updated when it changes. Treat this as an advanced feature. For many users, a non-forwarded Surfshark or NordVPN configuration still provides satisfactory outbound torrenting without the extra automation.
Keep download storage mounts independent of the VPN
The qBittorrent container needs access to its configuration directory and download storage, but those filesystem mounts should not depend on the VPN network. Map NAS datasets or shares through normal Docker volume mounts and use permissions that give qBittorrent only the access it needs. A networking change should not require moving the media library or giving the container broad administrative access to the NAS filesystem.
If Sonarr, Radarr or another media application imports completed downloads, decide whether that application also needs the commercial VPN. Often it does not. The ARR application can communicate with qBittorrent on the local Docker or gateway network while using its own normal internet route for metadata APIs. Group containers behind the VPN only when they share a real privacy requirement.
Allow local Web UI access without weakening the kill switch
Gluetun's firewall can block private networks by default depending on configuration. Use its documented local-subnet allowance to permit the trusted LAN or specific management subnet. Do not disable the firewall globally just to make the qBittorrent Web UI appear. The goal is a narrow exception: LAN clients can reach the management port, while qBittorrent's internet traffic still has no path except the VPN.
If Tailscale is your remote administrative network, you can choose to expose the Web UI through a private host route rather than opening a public port. Keep Tailscale independent from Gluetun so a provider outage does not remove your ability to manage the NAS. Private administration and public torrent egress are separate traffic classes and should remain separate in the design.
Unraid VPN Manager is a strong alternative
Unraid's current VPN Manager can import a commercial provider WireGuard configuration and expose the tunnel as a custom Docker network. qBittorrent can use the relevant `wgX` network while Plex and other services remain on their normal networks. This avoids running Gluetun and can make port publishing feel more conventional on an Unraid-only server.
Gluetun remains attractive when you want a portable Compose stack, provider-specific integrations or dynamic port-forwarding support for a compatible provider. Choose one approach and understand its failure behavior instead of layering both on the same qBittorrent container. The simplest network that meets the requirement is usually the most reliable one.
Avoid routing Plex and media playback through qBittorrent's VPN
Once completed downloads are added to Plex, the media server no longer needs to share qBittorrent's privacy route. Plex remote access can be damaged by a host-wide commercial VPN because the public IP and return path change. Keep Plex on the normal WAN for ordinary public remote access or use Tailscale for private remote streaming to your own devices.
This separation also prevents the VPN provider's speed or availability from limiting local media playback. The qBittorrent tunnel can reconnect, change regions or go offline without affecting the media server. A NAS is most resilient when optional download infrastructure does not control core storage and playback services.
Performance and disk behavior
Torrenting can create many concurrent connections and random writes, especially when several large downloads are active. The VPN tunnel is only one part of performance. Watch NAS CPU, memory, disk latency and filesystem behavior. SSD cache can help with heavy download workloads on some platforms, while completed media may eventually move to large HDD arrays. Keep free space and filesystem health in view; a fast VPN cannot compensate for a saturated storage pool.
WireGuard overhead is generally modest on modern x86 hardware, but very low-end NAS CPUs can still become a bottleneck when torrenting, encryption, media indexing and other containers run simultaneously. If you are replacing hardware, size the system for the full stack rather than qBittorrent alone. The live Amazon NAS listings above surface current enclosure options for users building a combined storage and Docker server.
A leak-proof deployment checklist
Start with Gluetun or the native provider WireGuard tunnel and verify the VPN public IP. Attach qBittorrent, map its Web UI only on the trusted LAN, and bind the client to the intended network interface when practical. Confirm torrent traffic uses the VPN and DNS does not leave through an unexpected resolver. Then stop the tunnel and verify qBittorrent cannot reach peers or trackers.
Restart the NAS and repeat the test. Confirm Tailscale or local administration still works with the provider VPN down. Confirm Plex is unaffected. If you use provider-side port forwarding, verify the current forwarded port and application setting after reconnects. A good qBittorrent VPN setup is not merely one that hides the IP during a successful session; it is one whose routes remain safe during failures and upgrades.
Sources and methodology
Cloudzat checks current vendor and platform documentation before publishing networking guidance. VPN clients, NAS operating systems, container images and remote-access behavior can change, so verify the current vendor instructions before modifying a production server.
Research snapshot: August 24, 2026. Recheck current platform, VPN and container documentation before changing a production network.