A focused setup guide for Surfshark WireGuard on Unraid, from key generation and config import to Docker routing, DNS checks and safe recovery.
Use Surfshark WireGuard when you want Unraid-native VPN routing
The current Unraid VPN Manager can import a commercial WireGuard configuration and expose it as a network for Docker containers. Surfshark supplies the required key pair and downloadable location configuration from its Manual setup area. That combination gives Unraid owners a clean native option: one tunnel can exist on the server while only the containers that need Surfshark are assigned to it. The main work is not installing WireGuard. It is understanding the route, DNS behavior and how the protected container should behave if the tunnel goes down.
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 WireGuard is the natural Surfshark protocol for Unraid
Unraid integrates WireGuard directly into VPN Manager and supports a connection type specifically intended for commercial VPN tunneled access. That makes Surfshark WireGuard a cleaner fit than trying to install a desktop VPN application on the server. The operating system owns the tunnel, Docker can see it as a custom network, and you can decide which containers use it. This aligns with the way Unraid is designed: storage, applications and networking can be separated instead of forcing one global desktop-style VPN switch.
Surfshark also maintains a current manual WireGuard workflow. The account dashboard creates or registers a key pair, then lets you choose a server location and download a configuration. That file is portable enough for Linux, routers and Unraid-style imports. The result is a native VPN path with fewer moving parts than a full VPN app and less application coupling than running the tunnel inside each individual container.
Create the Surfshark WireGuard key pair correctly
Log in to Surfshark, open VPN, Manual setup, select WireGuard and choose whether you already have a key pair. If you generate a new pair, copy the private key immediately and store it in a secure password manager or secrets store. Surfshark explicitly notes that you will not be able to simply display the generated key again later. Treat it with the same care as a password because anyone with the private key can impersonate that WireGuard client configuration.
After the key pair is registered, choose a Surfshark location and download the WireGuard configuration. The location should be selected for the workload, not just because it appears first in a list. A nearby endpoint usually provides the best latency and is the easiest place to establish a baseline. If the application requires a specific country, test that region after the local configuration works. Keep the file name descriptive because Unraid can host multiple WireGuard tunnels and vague names become confusing quickly.
Understand the fields before you import the file
A Surfshark WireGuard configuration contains interface and peer values such as a private key, tunnel address, server public key, endpoint and allowed IP ranges. Unraid can import these values, but you should still understand what they mean. The endpoint is the Surfshark server your client contacts. The allowed IP range determines which destination traffic should use that peer. A full commercial VPN profile typically routes internet traffic through the tunnel, while local networks should remain reachable through the normal server interfaces.
Do not manually rewrite values simply because another guide shows different addresses. WireGuard tunnel addresses and server keys are provider-specific and can change. Use the configuration generated for your account and location. The most useful manual edit is usually the local tunnel name inside Unraid, not the cryptographic or endpoint values. If you later rotate a key or change regions, import the fresh provider file and retest rather than carrying old values forward indefinitely.
Import the Surfshark profile in VPN Manager
Open Settings, VPN Manager, choose Import Config, and select the Surfshark WireGuard file. Unraid creates a tunnel and assigns a wg interface number. For commercial provider use, the relevant peer type is VPN tunneled access for Docker when you intend to protect containers. Apply the configuration, check the generated values, then activate the tunnel. If the interface does not establish connectivity, stop there and verify the Surfshark key pair and downloaded file before adding custom routes.
Write down the actual wg interface name. A server with an existing inbound WireGuard setup may create the commercial tunnel as wg1 or wg2 rather than wg0. This name becomes the Docker network identifier. If you later delete or reorder tunnels, confirm the network names again before assuming a container is still attached to the expected exit path.
Attach a Docker container to the WireGuard network
Edit a simple test container and set Network Type to Custom: wgX, replacing X with the imported Surfshark tunnel number. Apply the container change and start it. From inside that container, request a public IP or use a browser container to open an IP-check service. The visible address should correspond to Surfshark, not the household connection. Then run a DNS leak test from the same container network path. If the IP is correct but DNS still uses an unexpected resolver, fix DNS before moving production workloads.
This native route is ideal when an application can operate normally on the wg network without needing unusual port publishing or cross-container networking. A downloader, scraper or API worker can often be moved cleanly. If the application needs to share a network namespace with several companion services, or you want a stronger container-level kill switch, Gluetun may be easier. Do not add complexity until the simpler native Unraid route fails a real requirement.
Handle DNS deliberately
DNS is one of the most common reasons a tunnel appears connected while an application still cannot resolve names. Unraid documentation says that imported commercial profiles do not automatically dictate system DNS for the host in system-wide mode, and its Docker testing guidance recommends explicitly setting a resolver when needed. For a container, verify which DNS server is actually being used rather than assuming the provider profile controls everything.
The practical rule is simple: public IP and DNS should be tested separately. If a container can reach an IP address but not a hostname, the WireGuard handshake may be healthy while DNS is wrong. If both fail, inspect the route and tunnel first. Keep your server management DNS stable and avoid changing global resolvers just to fix one container if a container-specific setting will solve the problem.
Choose between Docker-only and system-wide WireGuard routing
Docker-only routing is the safer default for a multi-purpose Unraid server. It protects the application that needs Surfshark while leaving the management plane, update checks, Plex and other services on their established routes. System-wide routing is appropriate when the whole host has a clear outbound privacy requirement. Current Unraid guidance notes that only one system-wide WireGuard tunnel can be active at a time, so that design also affects how you plan multiple providers or locations.
If you are tempted to use system-wide routing because it feels easier, list the services that would inherit it. If any of them rely on direct inbound reachability, local discovery, licensing endpoints or stable source IP behavior, the global route may create more work than the per-container option. Unraid makes selective WireGuard routing easy enough that broad tunneling should be a conscious decision.
Test failure behavior before trusting the tunnel
Privacy-sensitive workloads need a predictable failure mode. Stop the Surfshark tunnel and see whether the protected container loses internet, stops entirely, or falls back to another route. The result depends on how the network is configured. Unraid native wg routing is different from Gluetun, which is purpose-built around a VPN gateway container and its own firewall. Neither design should be assumed safe until you test the exact container.
Also test a reboot. Confirm the WireGuard tunnel returns, the Docker network is recreated, and the protected application does not start in an unintended state before the VPN path is ready. Unraid release notes have improved WireGuard network recreation over time, but your server can still have plugin, container or custom-network dependencies. A controlled restart test is part of deployment, not optional maintenance.
Keep inbound WireGuard and Surfshark WireGuard separate
Many Unraid owners already use WireGuard for remote access, so it is easy to assume a Surfshark WireGuard tunnel is just another peer in the same design. The roles are different. An inbound Unraid tunnel accepts your trusted device and gives it access to the server or LAN. The Surfshark tunnel is an outbound client connection from Unraid to a commercial provider. They can coexist, but route priorities and subnets must not overlap.
If a remote session breaks after you activate Surfshark, disable the commercial tunnel and inspect the routes. Do not expose the WebGUI publicly to compensate. Current Unraid security guidance prefers Tailscale or a VPN tunnel for remote management rather than direct WAN exposure. Keep the remote-access path stable and send only the intended outbound workloads through Surfshark.
Troubleshoot handshakes, DNS and container connectivity
No handshake usually points toward the key, endpoint, time, firewall or upstream UDP path. Start by downloading a fresh Surfshark configuration and confirming the registered key pair. A handshake with no useful traffic points more toward allowed IPs, routing or DNS. A working internet route with broken LAN dependencies points toward container network design or firewall rules. These are different problems and should not be attacked with the same fix.
If a complex Docker stack requires many exposed ports and local service calls, the native wgX path can become awkward. That is the point where Gluetun may be a better abstraction because connected containers deliberately share its network stack and published ports can be managed in one place. Use the simplest design that passes your routing, leak and recovery tests.
WireGuard security and maintenance habits
Protect the Surfshark private key, keep a record of the server location and local tunnel name, and rotate configurations when you intentionally regenerate credentials. Avoid posting screenshots that reveal keys or complete configuration files. When troubleshooting in public forums, redact private keys, account-specific addresses and tokens. A VPN configuration is a credential, not just a network preference.
Recheck the setup after major Unraid or Surfshark changes. Unraid networking continues to evolve, and Surfshark can update endpoints or manual setup workflows. A short quarterly test of public IP, DNS, tunnel restart and container access is more valuable than assuming a configuration that worked a year ago still behaves exactly the same.
Surfshark WireGuard on Unraid: Docker VPN Setup: questions
Can Unraid import a Surfshark WireGuard config?
Yes. Unraid VPN Manager supports imported commercial WireGuard configurations and can make the tunnel available to Docker containers.
Where do I get the Surfshark WireGuard private key?
Generate or register a key pair in Surfshark VPN > Manual setup > WireGuard and store the private key securely.
What does Custom: wgX mean in Unraid?
It is the Docker network associated with a WireGuard tunnel. Containers assigned to it can route traffic through that tunnel.
Can I run Surfshark WireGuard and Tailscale together?
Yes, but keep their roles and routes separate. Surfshark is outbound commercial VPN traffic, while Tailscale is private remote networking.
Why does my Surfshark WireGuard tunnel connect but Docker has no internet?
Check the container network selection, DNS, tunnel route and the current Surfshark configuration. A handshake alone does not prove name resolution or Docker routing works.
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.