A provider-aware NAS guide to routing only selected Docker applications through a commercial VPN while keeping Plex, storage and remote access stable.
Route the application, not the whole NAS
For most NAS Docker stacks, put only privacy-sensitive containers behind Gluetun or a selected WireGuard network. Keep Plex, SMB, backups and Tailscale on their normal paths so a provider VPN outage cannot take the whole server offline.
Which container VPN architecture fits your NAS?
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 Docker? Live Amazon NAS listings
Compare current NAS enclosures with the CPU, RAM, bays and container flexibility needed for Docker-heavy workloads.
Prices and availability are pulled from Cloudzat’s existing Amazon catalogue and can change. As an Amazon Associate, Cloudzat earns from qualifying purchases.
Why container-level VPN routing is usually better on a NAS
A NAS often runs services with completely different networking needs. A downloader may benefit from a commercial VPN, while Plex needs predictable remote access, SMB must stay on the local LAN, Tailscale must preserve private management access, and backup jobs may need the normal ISP path. Routing the entire NAS through one provider VPN forces every service to inherit the same tunnel, firewall and failure mode. Container-level routing is more precise because only the application that actually needs a different public IP uses the VPN.
Docker makes this practical. You can run a VPN gateway container such as Gluetun and attach selected application containers to its network namespace. The VPN gateway owns the tunnel, DNS policy and kill-switch behavior. Plex, NAS administration and unrelated containers remain on their normal networks. This design is easier to troubleshoot and safer operationally because a VPN-provider outage can stop the protected application without taking storage and management services offline.
Gluetun is the common gateway pattern
Gluetun is a popular Docker VPN client because it supports many commercial VPN providers and can use OpenVPN or WireGuard depending on the provider. In a Compose stack, an application can use `network_mode: "service:gluetun"` to share Gluetun's network namespace. A container created separately can use the equivalent `network_mode: "container:gluetun"` pattern. The important idea is that the application no longer owns its own independent network interface; its internet traffic leaves through the VPN gateway container.
This has a useful security property. If Gluetun cannot establish the tunnel, the attached application does not simply fall back to the host's ordinary WAN route. The firewall and shared namespace keep the privacy-sensitive service dependent on the VPN path. That is much cleaner than relying only on an application checkbox or hoping a host route remains correct after a reboot.
Publish application ports on the VPN gateway
When a container shares Gluetun's network namespace, ports that need to be reachable from the LAN must be published on the Gluetun container rather than on the attached application. This is a common source of confusion. The application may be healthy and listening internally, but its Web UI appears unreachable because the host port was mapped on the wrong service.
For example, if qBittorrent runs behind Gluetun, expose the qBittorrent Web UI port on Gluetun. Keep the mapping limited to the LAN interface where possible and do not confuse a Docker host-port mapping with VPN-provider port forwarding. Docker port mapping makes a service reachable from the host/LAN. Provider-side port forwarding determines whether unsolicited traffic from the public internet can enter through the VPN tunnel. Those are separate layers.
Preserve LAN access deliberately
A VPN gateway normally includes firewall rules to prevent leaks. Those rules can also block access to NAS subnets unless local networks are explicitly allowed. Gluetun documents `FIREWALL_OUTBOUND_SUBNETS` for allowing traffic to selected private networks. Configure only the subnets the container needs rather than broadly disabling firewall protection.
Check for route overlap as well. A WireGuard VPN tunnel can use an address range that conflicts with the home LAN or another overlay network. If the routes overlap, traffic can follow the wrong interface even when every setting looks reasonable. Choose non-overlapping private networks for Docker, Tailscale, VLANs and VPN interfaces. A predictable IP plan makes container routing far easier to maintain than adding exception after exception later.
Surfshark is a strong Docker option when port forwarding is not required
Surfshark is directly supported by Gluetun and can be configured with either OpenVPN or WireGuard. WireGuard is generally attractive for lower overhead and simpler modern cryptography, while OpenVPN remains a useful compatibility fallback. For a downloader, scraper or other outbound-only container, Surfshark is straightforward because the application only needs to establish connections through the provider tunnel.
The important limitation is inbound port forwarding. Surfshark does not provide normal VPN-side port forwarding, so it is not the right recommendation when the application requires a provider-assigned inbound port. That does not prevent ordinary web browsing, downloading or most outbound client behavior. It simply means the provider should be selected based on the real feature requirement rather than the assumption that every VPN offers equivalent networking capabilities.
WireGuard versus OpenVPN inside the container stack
WireGuard and OpenVPN can both work well for Docker VPN routing. WireGuard usually has a smaller codebase and low overhead, while OpenVPN has broad compatibility and many mature provider configurations. The best choice is the method the provider supports reliably in Gluetun and the one your host environment can maintain without fragile workarounds.
Do not judge only by a synthetic speed test. On a NAS, the practical questions are whether the tunnel survives reconnects, whether DNS stays inside the intended path, whether the protected container stops safely when the VPN fails, and whether local management ports remain reachable. A slightly faster tunnel is not useful if it breaks after every NAS reboot or loses LAN reachability.
Unraid has a native alternative to Gluetun
Unraid includes VPN Manager and can import commercial provider WireGuard configurations. Current Unraid documentation describes a container-routing workflow where Docker containers can use a custom `wgX` network corresponding to the VPN tunnel. This can be simpler than Gluetun when the goal is just to route selected Unraid containers through a provider WireGuard connection.
Gluetun remains attractive when you want the same Docker architecture across Unraid, Synology, a Linux server or another container host, or when you want its provider integration and firewall controls. There is no universal winner. Native VPN Manager is host-integrated and easy for Unraid-specific deployments; Gluetun is portable and container-centric. Choose based on how much infrastructure you want the host versus the Docker stack to own.
Keep Plex and NAS management outside the provider tunnel
Plex, DSM, QTS, TrueNAS and Unraid administration usually do not benefit from a commercial VPN. Putting them behind one can break remote access because the server's replies leave through the provider instead of the ISP router. Keep those services on the ordinary route or use Tailscale for private inbound administration. The commercial VPN should be an application policy, not the identity of the entire NAS.
This separation also improves reliability. If the provider has an outage, your storage shares, media server and management interfaces remain available. If the VPN container is misconfigured, only the attached applications are affected. Good homelab architecture minimizes the blast radius of optional services, and a privacy VPN is optional infrastructure for most NAS workloads.
DNS leak testing and public-IP verification
After attaching a container to a VPN, verify the result from inside that container. Check the public IP address and compare it with the host's public IP. They should differ when the VPN is active. Check DNS resolution as well so provider-routed traffic is not accidentally sending DNS queries through an unexpected resolver. Unraid's documentation explicitly recommends testing both the public IP and DNS behavior for commercial VPN tunnels.
Then stop the VPN gateway and repeat the test. The protected application should lose internet connectivity rather than fall back to the normal WAN. This failure test is more important than the initial successful connection because it proves the privacy boundary actually exists. A VPN configuration is not complete until you know how it behaves when the tunnel fails.
qBittorrent and other download clients need an extra leak-control layer
For qBittorrent, binding the application to the VPN network interface adds another defense against accidental traffic leakage. The qBittorrent project documents this through Tools, Options, Advanced and Network Interface. In a Gluetun network-namespace design, the container is already constrained by the gateway, but explicit interface binding can still help make intent clear in setups where multiple interfaces are visible.
Do not rely on one control alone when privacy matters. Use the VPN gateway's firewall, isolate the application network, verify the public IP, and bind the client when the platform makes that practical. At the same time, keep management Web UIs exposed only to trusted LAN or Tailscale networks. Privacy for outbound peer traffic should not lead to careless exposure of administrative interfaces.
NAS hardware considerations for Docker VPN workloads
VPN encryption is rarely the largest resource consumer on a modern NAS, but Docker-heavy systems benefit from CPU and memory headroom. qBittorrent, indexers, media managers, Plex, databases and photo applications can all compete for resources. A newer x86 NAS with sufficient RAM is often easier to manage than an entry-level appliance when you intend to run several persistent containers.
Container flexibility is also part of the buying decision. Synology, QNAP and UGREEN provide different Docker experiences and hardware tiers. Unraid and TrueNAS deployments may use custom hardware instead. The live Amazon NAS listings above surface current enclosure options for users who are combining storage and container services, but do not replace workload planning. Choose bays, CPU, memory and network ports around the entire server role, not just the VPN tunnel.
A production-ready validation sequence
Build the container stack with the VPN gateway first and confirm the tunnel connects. Attach one application and verify its public IP and DNS. Publish only the necessary LAN management port on the gateway. Confirm local access from a trusted device. Then stop the VPN and verify the application cannot reach the internet. Restart the stack and confirm the intended startup order survives a reboot.
Finally, test the services that should remain outside the VPN. Plex should still reach remote clients through its intended path, Tailscale should still provide private NAS access, and backup jobs should use the correct route. Document the container relationships and local subnets. A VPN architecture is successful when each workload has one clear path and the failure of one tunnel does not create surprising behavior elsewhere on the NAS.
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.