Choose the right Docker routing boundary so only the containers that need NordVPN use the commercial VPN path.
Cloudzat may earn a commission from qualifying NordVPN and Amazon purchases. Recommendations are based on the networking problem described, not on commission rate.
How do you route Docker containers through NordVPN on Unraid?
Use the narrowest routing layer that matches the workload. Gluetun is easy to audit for one or several containers, while VPN Manager can provide a platform-managed commercial tunnel.
Do not put every Docker application behind NordVPN just because they share storage. Plex, dashboards and local automation can keep normal networking while privacy-sensitive apps use the VPN.
NordVPN Docker routing patterns on Unraid
| Pattern | Best use | Routing owner | Main risk |
|---|---|---|---|
| Gluetun namespace | One or several apps | Gluetun | Port/LAN rules move to gateway |
| VPN Manager | Central tunnel | Unraid | Provider config must be compatible |
| VPN inside app | One self-contained app | Application | Duplicated config |
| Router policy | Whole server/VLAN | Router/firewall | Less per-container control |
Choose the Docker routing boundary
Select the workload pattern you want.
How this NordVPN architecture should be designed
NordVPN Docker routing on Unraid works best when the network job is defined before the software is configured. On Unraid Docker, decide whether the requirement is outbound privacy, private remote access, or a routed connection between trusted devices. Those jobs can all be described as VPN use, but they create different routing tables, firewall rules and failure modes. Unraid can own a commercial tunnel through VPN Manager, while Gluetun can own a smaller Docker-only group.
The recommended boundary on this page is per-workload Docker routing through Gluetun or an assigned commercial tunnel. That keeps the policy close to the traffic that actually needs it instead of changing unrelated services. Storage mounts and network routes are separate: a downloader and Plex can share the same media files while using different network paths. A narrow boundary is easier to test because the protected path and the ordinary path can be compared on the same server.
Document the intended route in plain language before making changes. If an administrator cannot explain which packets should use NordVPN and which should remain local, the design is too ambiguous to troubleshoot safely.
NordVPN authentication and credentials
Authentication should be solved before routing. For NordVPN manual OpenVPN clients such as Gluetun, use service credentials from NordVPN manual setup. A tunnel that cannot authenticate will produce downstream symptoms that look like DNS, firewall or Docker problems even though no protected route has been established.
Store credentials or tokens in protected settings rather than screenshots, public Compose files or forum posts. If the provider credentials are regenerated, update every dependent client at the same time and restart the network layer before changing the application itself.
After authentication succeeds, inspect the current client logs and verify the selected NordVPN endpoint or Meshnet identity. Successful login and correct traffic flow are separate checks.
Choose the narrowest routing scope
Storage mounts and network routes are separate: a downloader and Plex can share the same media files while using different network paths. This is especially important on Unraid Docker, where one machine may host storage, media, backups, dashboards and several containers. A broad default route can make all of those services depend on a VPN change made for only one workload.
Preserve the APIs and web UIs that must remain reachable from Sonarr, Radarr, browsers or other LAN services. Private subnets should remain deliberately reachable where the application requires them. Do not fix a local-routing mistake by exposing a service publicly or disabling the firewall wholesale.
Use a short source, destination and purpose list for every exception. That makes the policy auditable and prevents a later upgrade from quietly changing the path.
Example container traffic policy
| Traffic | NordVPN? | Reason |
|---|---|---|
| Downloader → internet | Yes | Commercial egress |
| Sonarr → downloader API | No | Local dependency |
| Plex → remote client | Usually no | Inbound-sensitive |
| SMB → workstation | No | Local storage |
Keep inbound and local services on deliberate routes
Use private remote-access tooling for inbound administration rather than making Docker’s commercial VPN route solve that job. Inbound-sensitive services such as NAS administration, Plex, reverse proxies and file shares should use a route designed for inbound reachability rather than accidentally inheriting a commercial exit path.
Avoid blanket host-wide tunneling when only one or two Docker workloads need commercial VPN egress. A service can appear healthy on the LAN while remote clients fail because the return traffic leaves through a different interface. Keep management interfaces private and use a dedicated private-access technology when the requirement is administration from outside the home.
When a public inbound service is genuinely required, treat it as a separate security decision with explicit firewall, authentication and update controls.
Platform-specific deployment details
The platform details matter. Unraid can own a commercial tunnel through VPN Manager, while Gluetun can own a smaller Docker-only group. Follow current vendor guidance for Unraid Docker instead of assuming a configuration written for a generic Linux host applies unchanged. Appliance operating systems, Docker hosts and router platforms expose different supported integration points.
Prefer the supported layer that survives upgrades. A configuration that requires modifying a protected base operating system may work today but create maintenance debt during the next platform update. External routing or a supported container can be safer than an unsupported package hack.
Before production use, record the software version, network mode and any platform-specific permissions so the setup can be reproduced after a migration.
Verify routing, DNS and failure behavior
Run exit-IP and DNS checks inside every protected container and also test an unprotected container to prove the split policy. Test from inside the exact namespace or remote client that is supposed to use the route. A browser on the host proves nothing when only one Docker container is protected, and a successful LAN test proves nothing about a remote Meshnet path.
Check the expected public IP or private destination, DNS resolution, local dependencies and failure behavior. If the design is supposed to fail closed, deliberately interrupt the VPN in a controlled test and confirm the protected application cannot bypass the policy.
Re-test after major platform upgrades, container image changes, credential rotations or router changes. Network policy is only trustworthy when its behavior is verified, not when a status icon is green.
Performance and throughput considerations
Keep local cache, array and NAS traffic on the LAN and benchmark the VPN only on the internet-facing workload. Measure the workload that matters instead of relying on a generic VPN speed claim. Internet VPN traffic is bounded by WAN throughput and endpoint conditions, while remote NAS access is often bounded by the home upload connection.
Keep high-bandwidth local traffic local whenever possible. SMB, NFS, database traffic and media reads between devices on the same LAN gain nothing from travelling to a remote VPN endpoint. Separating those flows also reduces CPU and latency overhead.
When performance changes, compare the protected path with an ordinary path at the same time. That helps distinguish the VPN, ISP, storage device, transcoder and remote service as possible bottlenecks.
Security boundaries and maintenance
Avoid blanket host-wide tunneling when only one or two Docker workloads need commercial VPN egress. A private tunnel reduces exposure but does not replace application authentication, MFA, backups, snapshots or operating-system updates. Treat linked devices and VPN credentials as part of the security boundary.
Remove stale peers, rotate compromised credentials and avoid granting broader LAN access than the use case needs. For NAS administration, use a dedicated administrator account only when necessary and keep routine file access on lower-privilege accounts.
Good remote networking should make the attack surface smaller, not simply move the same exposed service to a different address.
Deployment checklist
Before finishing the NordVPN Docker routing on Unraid deployment, confirm the routing goal, authentication, local-network exceptions and recovery path. Run exit-IP and DNS checks inside every protected container and also test an unprotected container to prove the split policy.
Record which service owns the route, which applications depend on it, and what should happen when the VPN or overlay is unavailable. This is the information that makes a home-server configuration maintainable six months later.
The final design should be simple to state: per-workload Docker routing through Gluetun or an assigned commercial tunnel handles the intended traffic, while unrelated Unraid Docker services stay on routes appropriate to their jobs.
Frequently asked questions
Can one Unraid container use NordVPN while others do not?
Yes. Selective routing is a core advantage of a container gateway or assigned tunnel.
Can Plex share storage with a protected downloader?
Yes. Storage mounts and network namespaces are independent.
Does Gluetun change the Unraid host route?
No by default.
Why can Sonarr no longer reach the downloader?
Check LAN exceptions and port ownership on the VPN gateway.
Should Plex use the same NordVPN route?
Usually no.
How do I prove the split routing works?
Test protected and unprotected containers separately.
Research references and methodology
Cloudzat separates vendor-documented capabilities from deployment advice. VPN clients, container images, NAS operating systems, routing behavior and offer terms change over time, so verify the current vendor instructions before changing a production server or exposing a service.
Last meaningfully reviewed: August 25, 2026.