A practical guide to putting the right Unraid containers behind Surfshark while keeping the WebGUI, Plex, storage and unrelated services on normal routes.
Protect the container, not the entire server
For most Unraid users, the best Surfshark design is selective Docker routing. Unraid can import a Surfshark WireGuard profile and expose it as a custom wgX network, while Gluetun can act as a dedicated VPN gateway for containers that share its network stack. Both approaches keep the Unraid host itself outside the commercial VPN unless you intentionally change that. The decision comes down to how much network isolation, shared routing, local service access and port mapping the application stack needs.
What are you trying to protect?
Choose the routing goal first. The best Surfshark architecture changes depending on whether the VPN belongs to one container, an application group, the whole server or remote access.
Why Docker-level VPN routing is better than a blanket Unraid tunnel
An Unraid server often runs a mixture of applications with very different networking needs. A downloader may benefit from Surfshark, while Plex depends on stable local and remote reachability, Home Assistant talks to LAN devices, databases should stay private, and the Unraid WebGUI should remain easy to reach. Sending every one of those services through a commercial VPN creates unnecessary coupling. Docker-level routing lets you apply the privacy policy only where it belongs.
Unraid is unusually good at this because imported WireGuard tunnels can become Docker networks. You do not need to install a Surfshark app inside each container. Instead, the container joins the VPN-backed network. The alternative is Gluetun, which runs as a VPN gateway container and lets other containers share its network stack. Both patterns are more precise than changing the entire host default route.
Choose native wgX routing or Gluetun
Use the native wgX network when the application is simple and does not need a complicated set of shared ports or local service routes. Import the Surfshark WireGuard configuration into Unraid VPN Manager, activate it, and assign the container to Custom: wgX. The operating system manages the tunnel, which means fewer containers and fewer environment variables. This is often the best first attempt for a standalone downloader or web tool.
Use Gluetun when several containers should share exactly the same VPN path, when you want a dedicated VPN firewall boundary, or when a Compose-style application stack is easier to manage as one network namespace. Gluetun has native Surfshark provider support for both OpenVPN and WireGuard. The tradeoff is that ports and LAN access must be configured around the Gluetun container because the dependent applications no longer own separate network stacks.
Native method: import Surfshark and expose Custom: wgX
Generate a Surfshark WireGuard key pair and download a server configuration from the Surfshark manual setup area. In Unraid, import it under Settings > VPN Manager and activate the tunnel. The resulting wg interface becomes available to Docker. Edit the target container, change Network Type to Custom: wgX, apply the change, and start the container. Do not copy the wg number from a guide because your server may already have other WireGuard tunnels.
Test with one container first. If the public IP is Surfshark and DNS is clean, you have a working selective route. If the application also needs local APIs, databases or media folders, test those dependencies before moving the rest of the stack. Native wg routing is simple precisely because it does not automatically understand how your applications communicate with one another.
Gluetun method: use one VPN gateway container
Gluetun runs the Surfshark VPN connection inside a dedicated container and exposes that network stack to other containers. The current Gluetun provider documentation supports Surfshark directly. For WireGuard, the important values include VPN_SERVICE_PROVIDER=surfshark, VPN_TYPE=wireguard, the Surfshark WireGuard private key and the WireGuard interface address taken from the downloaded Surfshark configuration. For OpenVPN, Gluetun instead uses the Surfshark manual OpenVPN username and password.
On Unraid, this is useful for application groups such as a downloader plus helper tools. The application containers do not each establish their own VPN. They borrow Gluetun network connectivity. That gives you one place to change the Surfshark country, one place to inspect VPN logs, and one firewall boundary. It also means Gluetun becomes a dependency, so health checks and restart behavior matter.
Plan LAN access before the stack goes behind the VPN
A protected container may still need to talk to services on your home network. A downloader might need an indexer, Sonarr or Radarr may need to reach a downloader, and an automation tool may call a local API. When a container moves behind a VPN gateway, that local path can stop working even though internet access is fine. This is not evidence that Surfshark is broken. It means the routing policy is doing exactly what you told it to do.
With Gluetun, FIREWALL_OUTBOUND_SUBNETS can allow access to explicit LAN subnets. The current Gluetun documentation warns that the configured outbound subnet must not overlap the VPN tunnel address range. Use the narrowest subnet that solves the dependency and test it. With native wgX routing, the exact route behavior depends on the imported tunnel and Unraid networking. In either case, document which local destinations the protected application needs.
Ports belong to the network owner
Port publishing changes when containers share a Gluetun network stack. Gluetun documentation says that a port for a connected container should be published on the Gluetun container because Gluetun owns the network namespace. In a Compose file, another service in the same stack can use network_mode: service:gluetun. For an external container, Docker can attach it to the Gluetun container network namespace. The application still listens on its normal internal port, but the host-facing mapping belongs to Gluetun.
This is one of the biggest conceptual differences from Unraid native wgX. With a normal custom network, the application container keeps its own port mappings. With Gluetun, shared networking centralizes them. If you forget this, the container can be healthy while its WebUI appears unreachable. Treat ports as part of the VPN gateway design, not an afterthought.
Keep Plex and server management outside the VPN unless necessary
Plex is a common example of a service that does not need to inherit the downloader VPN. Remote access, discovery and account services can become more complicated when the media server itself exits through a commercial VPN, and Surfshark does not provide normal VPN port forwarding. Keep Plex on its established route unless your specific use case requires otherwise. The same principle applies to the Unraid WebGUI and infrastructure services such as DNS, monitoring and backup coordination.
Selective routing is valuable because it lets a media automation stack use Surfshark where needed without changing the network identity of the whole server. The downloader can use the VPN while Plex reads the completed files from storage over the local system. This separation is easier to troubleshoot and reduces the number of services affected by a Surfshark outage or server change.
Test for DNS leaks and unintended WAN fallback
A public IP check proves only that one request exited through Surfshark. Run a DNS leak test from the protected container and confirm the resolver path is acceptable. Then stop the VPN tunnel or Gluetun container and observe the application. A privacy-sensitive service should not quietly reconnect through the normal WAN if your policy assumes the VPN is mandatory. Gluetun is built around a VPN gateway and firewall model, while native wgX behavior should be tested on your exact Unraid configuration.
Also test after a Docker restart and a full Unraid reboot. Container start order, tunnel recreation and saved Docker network settings can expose failures that never appear during the initial setup. A reliable design survives maintenance, not just a five-minute browser test.
Storage performance still matters for VPN-routed Docker apps
A high-speed Surfshark tunnel can make a weak Unraid cache design more obvious. Downloaders may create incomplete files, verification data and extracted copies before Mover sends final content to the array. If appdata and temporary downloads share a small cache device, the pool can fill even when the VPN itself is performing well. Size the cache for the largest realistic working set and protect important appdata with appropriate redundancy and backup.
Container-heavy systems also need RAM headroom. The VPN gateway is not usually the biggest memory user, but the applications around it can be. Media automation, databases, indexers and photo services often matter more. Treat Docker VPN design as part of the overall Unraid workload plan rather than a standalone networking trick.
Troubleshoot from the outside in
Start with the Surfshark tunnel itself. Can the VPN gateway reach the internet and show the expected public IP? Next, can the application container reach the internet through that gateway? Then test DNS. Finally test the local services it depends on. This order keeps you from changing firewall rules when the real problem is a bad Surfshark key or from regenerating VPN credentials when the real problem is an unpublished WebUI port.
If native wgX becomes difficult because several containers need to share networking, move the stack to Gluetun rather than stacking workarounds on top of the native route. If Gluetun becomes too complex for one simple application, move that application back to a direct wgX network. The right architecture is the one that minimizes special cases.
The best Surfshark Docker pattern for Unraid
For one or two simple applications, start with Unraid native WireGuard and Custom: wgX. It is integrated, easy to inspect and avoids an extra gateway container. For a tightly coupled application group or a stack that benefits from a shared kill-switch-style network boundary, use Gluetun. Keep the Unraid host, remote access and unrelated services outside the commercial VPN unless you have a specific reason to change them.
That design gives Cloudzat readers a clear rule: protect the workload, not the whole box. Surfshark provides the commercial exit, Unraid provides the native selective network, and Gluetun is available when the application architecture needs stronger container-level control.
Surfshark Docker on Unraid: Route Containers Through VPN: questions
How do I route one Unraid Docker container through Surfshark?
Import a Surfshark WireGuard configuration in VPN Manager and assign the container to the resulting Custom: wgX network.
Is Gluetun better than Unraid WireGuard for Surfshark?
Not always. Native wgX is simpler for a standalone container. Gluetun is better when several containers should share one VPN gateway and firewall.
Can Plex stay outside Surfshark while qBittorrent uses it?
Yes. Selective Docker routing is designed for exactly that separation.
Why can my VPN container reach the internet but not Sonarr or Radarr?
The protected container may need an explicit route or firewall allowance to the LAN subnet where the other service lives.
Does Surfshark provide port forwarding for Docker apps?
No. Surfshark does not provide normal VPN port forwarding, so inbound service publishing must use another architecture.
Primary references used for this guide
Cloudzat checks current Surfshark, Unraid and Gluetun documentation before recommending a VPN route. Provider endpoints, Unraid networking and container images can change, so verify current vendor instructions before modifying a production server.
Research snapshot: August 24, 2026. Recheck current Surfshark, Unraid and Gluetun documentation before changing a production VPN, firewall or Docker network.