A double VPN is a configuration that routes your internet traffic through two VPN servers in sequence, encrypting it twice, so that no single server in the chain has simultaneous access to both your real IP address and your destination. The first server receives your encrypted traffic, strips its own encryption layer, and forwards the still-encrypted remainder to the second server. The second server strips the inner layer and sends your traffic to its destination. The destination sees only the second server’s IP address; your ISP sees only the first server’s IP address.
The visibility split looks clean on paper, but how much protection a double VPN delivers depends on two questions most guides skip: which encryption architecture the provider uses, and whether the same company controls both servers.
TL;DR
- A double VPN routes your traffic through two VPN servers in sequence, so that no single server can simultaneously see both your real IP address and your destination. Server 1 knows your source, not your destination. Server 2 knows your destination, not your source.
- Two distinct architectures exist. In nested double VPN, both encryption layers are applied on your device before any data leaves: the entry server never holds your plaintext, and even a forensic memory acquisition of Server 1 yields nothing readable. In cascade double VPN, Server 1 decrypts your traffic before re-encrypting and forwarding it, briefly holding your plaintext in memory. Most providers do not disclose which architecture they use.
- Single-provider double VPN distributes visibility, not trust. The same company controls both servers: a single subpoena, breach, or rogue employee gives an adversary both ends simultaneously. Trust distribution requires two separate providers, each owning one server independently.
- A double VPN does not hide that you are using a VPN. Both hops still produce identifiable VPN traffic signatures, and a network that actively blocks VPNs will block a double VPN at the first hop. Obfuscation solves that problem; double VPN does not.
- The performance cost is geographically driven. Two servers on the same continent add modest latency and a double VPN remains usable for most tasks. A cross-continental chain adds 200 to 350ms or more and should be treated as a tool for text-based browsing only, not streaming, gaming, or video calls.
- Most users do not need it. The use case is specific: journalists, activists, and anyone who needs to ensure that no single legal demand or server compromise can link their identity to their destination. For everyday privacy, a standard VPN is sufficient; double VPN adds latency and often cost for no benefit.
What is a double VPN?
A double VPN (also called a multi-hop VPN, double-hop VPN, or multihop) routes traffic through two VPN servers in sequence and applies a separate encryption layer at each stage. The first server (the entry node) decrypts one layer and forwards the remainder to the second server, the exit node. The exit node decrypts the final layer and sends the traffic to its destination.
The feature appears under several names: Double VPN (NordVPN), MultiHop (Surfshark), multi-hop, and double-hop all refer to the same underlying two-server architecture. ProtonVPN’s Secure Core is a named implementation of this architecture with physical-security properties at the first hop.
A double VPN is not a distinct protocol. It is a routing and encryption configuration that sits on top of whatever protocol runs underneath: WireGuard, OpenVPN, or any other. The underlying protocol continues to operate normally; what changes is how many servers handle the traffic and how many encryption layers are applied. For how a single-hop VPN creates its encrypted connection, see what a VPN tunnel is.
How a double VPN works
Two distinct implementations exist, and they are not equivalent.
Nested double VPN
In a nested double VPN, both encryption layers are applied on the client device before any data leaves it.
- The client encrypts the payload with Server 2’s key. This becomes the inner layer. Server 2 is the only party that can decrypt it.
- The client encrypts the already-encrypted result with Server 1’s key. This becomes the outer layer.
- The doubly-encrypted packet travels to Server 1. Server 1 decrypts its own outer layer and is left with an encrypted payload it cannot read; the inner layer remains intact.
- Server 1 forwards the still-encrypted inner packet to Server 2.
- Server 2 decrypts the inner layer and forwards the plaintext to the destination.
At no point does the entry server (Server 1) see your plaintext traffic. Even if Server 1’s memory is forensically acquired (its RAM imaged or its processes inspected), the packet it holds destined for Server 2 is fully encrypted. Server 1 holds only the key for the outer layer.
Mullvad’s WireGuard multi-hop uses this architecture, implementing a WireGuard session tunnelled inside another WireGuard session. The entry server sees the user’s source IP and the exit server address; it cannot read the traffic. The exit server sees the traffic but only the entry server’s IP. For the ciphers used at each layer, see VPN encryption explained.
Cascade double VPN
In a cascade double VPN, the client applies one encryption layer. The distinction from nested is one step: Server 1 decrypts before forwarding.
- The client encrypts the payload with one key and sends it to Server 1.
- Server 1 decrypts the packet and holds the decrypted traffic in volatile memory.
- Server 1 re-encrypts the plaintext with a new key and forwards it to Server 2.
- Server 2 decrypts and forwards the plaintext to the destination.
In a cascade implementation, Server 1 holds your VPN-decrypted traffic in volatile memory during the window between decryption and re-encryption. For HTTPS connections (the majority of modern web traffic), that traffic remains TLS-encrypted at the application layer, so what is exposed is chiefly connection metadata (such as the destination domain and traffic volume) and any non-HTTPS traffic; page contents protected by TLS are not readable. In a cloud or VPS environment, anyone with hypervisor-level access to the physical host (the data centre operator, a cloud provider, or an adversary with such access) could, in principle, read the VM’s memory and observe the plaintext during that window. Hypervisor operators have read-access to guest VM memory as a fundamental property of virtualised infrastructure; this has been confirmed in peer-reviewed research on VM introspection and identified by VPN providers as a reason to use bare-metal servers rather than cloud-hosted VPS instances. The concern does not apply to bare-metal or directly colocated servers, which have no hypervisor layer between the server hardware and the operating system.
The second hop provides IP-address separation regardless of architecture, but in cascade mode it does not provide a second layer of content protection.
Cascade architecture reduces client-side CPU overhead. Applying both encryption layers on the device requires two full encrypt operations; cascade moves one of those operations to Server 1, reducing device-side processing load. This partly explains its prevalence in commercial implementations despite the architectural weakness at Server 1.
NordVPN’s own Double VPN feature page describes the traffic flow in cascade-style terms: the client encrypts once, Server 1 decrypts and re-encrypts, Server 2 decrypts and forwards. NordVPN simultaneously markets the feature as “encrypting your traffic twice,” which implies nested architecture. NordVPN does not use the terms nested or cascade and does not resolve the tension between its documented flow and its marketing claim.
Nested vs. cascade: a direct comparison
| Nested | Cascade | |
|---|---|---|
| Where encryption layers are applied | Both at the client device, before transmission | First at client; second at Server 1 |
| Does Server 1 hold plaintext? | No; Server 1 decrypts only the outer layer | Yes, briefly, in volatile memory |
| Client CPU overhead | Higher: two full encrypt operations locally | Lower: one encrypt operation locally |
| Server 1 CPU overhead | Lower | Higher: decrypt plus re-encrypt |
| Vulnerable to hypervisor memory read? | No; inner layer is encrypted before leaving the device | Yes, in cloud and VPS environments |
| If Server 1 is compromised or coerced | Traffic remains encrypted | Traffic is exposed |
| Confirmed real-world example | Mullvad WireGuard multi-hop | NordVPN documented flow (cascade-style) |
What a double VPN actually protects against
Trust distribution: what each server knows
The core benefit of a double VPN is the separation of what each server can observe.
Server 1 knows your real IP address, that you are connected to a VPN, and that your traffic is going to Server 2. It does not know your destination or, in a nested implementation, the content of your traffic.
Server 2 knows Server 1’s IP address, your destination, and the content of your traffic. For HTTPS connections, that content remains TLS-encrypted at the application layer and is not readable by Server 2; what is exposed is connection metadata such as the destination domain and traffic volume. It does not know your real IP address.
An adversary who gains access to only one server cannot reconstruct the full picture. A legal demand served on Server 2 yields the destination and content but not the requester’s identity. A legal demand served on Server 1 yields the requester’s IP address but not the destination.
The same-provider trust problem
Single-provider double VPN distributes visibility across two servers. It does not distribute trust. If one company operates both servers, that company holds the full picture. A single subpoena, a breach of the provider’s infrastructure, a rogue employee, or a logging failure gives an adversary both ends simultaneously. For how logging policies govern what a provider can produce under legal demand, see what a no-log VPN is.
Trust distribution requires VPN-over-VPN with two separate providers. Two independent companies, potentially in different legal jurisdictions, each hold only half the picture. No single warrant, breach, or provider decision can expose both ends simultaneously.
Three approaches exist for implementing VPN-over-VPN:
- Router plus app. One VPN is configured at the router level (Provider A); a different provider’s client runs on the device (Provider B). Traffic layers cleanly through both. This is the most reliable approach and avoids the routing conflicts that arise when two full-tunnel clients compete for the same network interface.
- Virtual machine. Provider A’s VPN runs on the host OS; Provider B’s client runs inside a VM. Each client operates in an independent network context with no routing conflict.
- Two clients simultaneously on the same device. Both full-tunnel VPN clients compete to own the device’s default route. On Windows, the client with the lower routing priority wins; on macOS, the first-added wins. Typically one tunnel becomes non-functional. Split-tunnel or policy-based routing can allow coexistence but requires deliberate configuration and is not the consumer default. iOS and Android permit only one active VPN tunnel at a time, making this approach impractical on mobile without a router in the chain.
Two separate providers means two subscriptions, more complex configuration, and typically higher performance cost than a built-in double VPN feature. For most users, single-provider double VPN with a reputable provider in a privacy-favourable jurisdiction is a practical approximation. For users facing realistic provider-level legal demands across jurisdictions, two separate providers is the only architecturally sound approach.
Traffic correlation: what double VPN does and doesn’t prevent
A double VPN separates the observable entry and exit points of your connection. Your ISP sees traffic leaving your device to Server 1 but not the destination. An observer at the destination sees traffic arriving from Server 2 but not your real IP. An adversary who can monitor only one of those points cannot correlate the two.
A global passive adversary (a state-level actor capable of monitoring large portions of internet traffic simultaneously) can still perform end-to-end timing correlation by matching the traffic pattern entering Server 1 with the pattern exiting Server 2. This is the same end-to-end confirmation attack documented in Tor research. Johnson et al., “Users Get Routed: Traffic Correlation on Tor by Realistic Adversaries” (ACM CCS 2013) demonstrates that users are more susceptible to correlation-based deanonymisation by realistic AS/IXP-level adversaries than prior models assumed. A double VPN is weaker than Tor on this axis: Tor uses three relays with independent operators, randomised path selection, and a large anonymity set. A double VPN has fixed pre-paired routes, two hops, and no path diversity.
Mullvad has developed DAITA (Defense against AI-guided Traffic Analysis) to address the statistical traffic-analysis limitation that double VPN alone does not solve. DAITA is designed to defeat website fingerprinting: machine-learning classifiers that identify the sites a user visits by analysing the statistical shape of their traffic, even after content is encrypted. It operates at the traffic-pattern level rather than the routing level, and can be used in combination with Mullvad’s multi-hop.
Against any realistic adversary below global-passive capability (ISP-level surveillance, single-jurisdiction legal demands, opportunistic monitoring), a double VPN raises the cost of attribution.
What a double VPN does not do
It does not hide that you are using a VPN
Both hops of a double VPN produce identifiable VPN traffic signatures. The traffic entering Server 1 from your device is standard VPN traffic: WireGuard or OpenVPN packets with the characteristic handshake, packet structure, and timing patterns that deep packet inspection systems are designed to classify. A network that actively blocks VPN connections blocks a double VPN at the first hop.
Some sources suggest double VPN helps bypass censorship in China, Iran, or Russia. It does not. Double VPN addresses attribution: reducing what any single server or observer can link your identity to. Obfuscation addresses availability: making VPN traffic undetectable to networks that actively filter it. Enabling double VPN on a network that blocks VPN traffic at the first hop provides no benefit. See what an obfuscated VPN is.
It does not strengthen your encryption
AES-256-GCM and ChaCha20-Poly1305 (the ciphers any current VPN uses) have no known practical vulnerabilities. Adding a second layer of the same-strength encryption does not change a user’s exposure to cryptographic attacks. The value of a double VPN is entirely in trust distribution and correlation resistance, not cipher strength. Enabling double VPN for “stronger encryption” addresses a problem that does not exist, at the cost of performance overhead.
Double VPN, VPN-over-VPN, Tor-over-VPN, and obfuscation
| Feature | Problem it solves | Hides VPN use from DPI? | Distributes trust? |
|---|---|---|---|
| Double VPN / multi-hop | Reduces what any single server can attribute | No | Partially; fully only with two separate providers |
| Obfuscation | Allows connection on DPI-blocking networks | Yes | No |
| Tor-over-VPN | Strong anonymity via three independent relays | No; Tor traffic is itself identifiable | Yes |
| VPN-over-VPN (two providers) | Two-party trust distribution | No | Yes |
Obfuscation disguises the outer traffic signature of a VPN connection so that DPI systems cannot classify it. Double VPN does not alter that signature. The two features can be enabled simultaneously (obfuscation handles detectability, double VPN handles attribution) but they solve independent problems.
Tor routes traffic through three relays operated by independent volunteers, providing a stronger anonymity model than single-provider double VPN. Tor traffic is itself identifiable and blocked in many environments, and throughput is lower than any VPN configuration. For a comparison, see the Tor vs VPN comparison.
VPN-over-VPN with two separate providers (sometimes called VPN chaining) is the only architecture that provides trust distribution across two independent legal entities. Each provider holds only one end of the chain. For most users, a built-in double VPN feature from one provider is sufficient. For users whose threat model includes provider-level legal compulsion, two separate providers is the required architecture. The router-plus-app configuration is the most reliable implementation; running two simultaneous full-tunnel clients on the same device creates routing conflicts, and mobile operating systems allow only one active VPN tunnel at a time.
The performance cost
A double VPN is slower than a standard VPN. Five factors determine how much.
Geographic routing. This is the dominant factor. The second hop adds the round-trip time between Server 1 and Server 2 plus both servers’ processing time, on top of the base single-hop latency. Two servers on the same continent (Netherlands entry to Germany exit, for example) typically add 20 to 50ms of additional latency and the connection remains usable for most tasks including video calls and light streaming. A cross-continental chain (North Africa to the Netherlands to Japan) adds 200 to 350ms or more on top of the base. That configuration is unsuitable for real-time applications; it is a tool for text-based communication and low-bandwidth browsing only. This is why performance estimates across articles range from “slightly slower” to dramatically slower: both characterisations can be accurate for different geographic configurations.
Double encryption overhead. Two encrypt and decrypt operations instead of one. The CPU cost is measurable on lower-end mobile hardware. On modern desktop hardware it is rarely the bottleneck. On mobile, the additional processing increases battery consumption. For VPN encryption overhead and battery life, see does a VPN drain your battery.
MTU fragmentation in nested tunnels. Managed commercial implementations (Mullvad, ProtonVPN) handle MTU adjustment automatically; what follows matters if you are configuring a multi-provider setup manually. Standard Ethernet has a maximum transmission unit of 1500 bytes. Each WireGuard encapsulation layer subtracts approximately 80 bytes of header overhead: IP header, UDP header, WireGuard framing, and cryptographic metadata. A nested WireGuard-in-WireGuard configuration applies this subtraction twice: 1500 minus 80 minus 80 gives 1340 bytes as the IPv6-safe inner interface MTU, a figure confirmed by networking engineers. In IPv4-only configurations, the figure is 1360 bytes. If the inner interface MTU is not adjusted downward, packets exceed the physical limit and fragment at the network layer, causing throughput degradation and, in some configurations, breaking the connection entirely.
TCP meltdown in OpenVPN-based cascade setups. Nesting two TCP-based sessions (OpenVPN over TCP inside another OpenVPN over TCP session) creates a retransmission conflict known as TCP meltdown. When a packet is lost on the outer link, both the inner and outer TCP stacks independently detect the loss and each attempts retransmission. The compounding loop inflates buffer queues and can collapse the connection under load. The problem is documented by Olaf Titz (2001), confirmed in peer-reviewed work by Honda et al. (2005), and addressed directly in OpenVPN’s TCP meltdown FAQ. The engineering rule for nested tunnels is to use UDP-based encapsulation at every layer. WireGuard uses UDP and has no built-in retransmission layer, so the meltdown loop cannot occur, which is one reason Mullvad’s WireGuard-in-WireGuard multi-hop avoids this problem.
Server pool congestion. Double VPN server pools are smaller than general server pools. Fewer servers offer this feature, which means higher per-server load during peak periods. Peak-time connections may see additional degradation unrelated to routing geometry or encryption overhead.
Do you actually need it?
Most users do not need a double VPN. A single VPN with a verified no-log policy, a working kill switch, and confirmed DNS leak protection covers the threat model of virtually every everyday user. The right question is not “is double VPN better?” but “does my situation include a realistic adversary who can compromise or legally compel a single VPN provider?”
Everyday users. Browsing, streaming, public Wi-Fi protection, ISP tracking prevention. A standard single-hop VPN is sufficient. Double VPN adds latency, complexity, and often the cost of a second subscription for no benefit.
Users trying to bypass VPN-blocking DPI. Networks in China, Iran, Russia, and similar environments actively detect and block VPN traffic. Double VPN is the wrong tool: both hops produce identifiable VPN traffic and the connection is blocked at the first hop. Obfuscation is the correct tool for this situation.
Journalists, activists, and whistleblowers under realistic government surveillance. The threat model involves an adversary capable of serving legal demands on a VPN provider or compromising a single server. Double VPN with a reputable provider in a privacy-favourable jurisdiction raises the cost of attribution. VPN-over-VPN with two separate providers in different jurisdictions is the stronger architecture for the highest-risk tier of this group.
High-risk users handling sensitive sources. Double VPN is a starting point, not a sufficient solution. Tor provides stronger anonymity for communications. Operational security at the application, device, and behavioural level matters more than VPN architecture at this threat level.
Streaming degrades under the latency overhead, gaming is unusable on cross-continental chains, and everyday browsing carries unnecessary CPU and battery cost with no benefit.
| Situation | Recommendation |
|---|---|
| VPN works normally, everyday use | Standard VPN; double VPN adds no benefit |
| VPN blocked at work, hotel, or university | OpenVPN TCP 443 first; obfuscation if that fails |
| Travel to a censorship-active country | Obfuscation, not double VPN |
| Journalist or activist under surveillance | Double VPN; VPN-over-VPN with two providers for the highest tier |
| Sensitive-source communications | Tor; double VPN is a starting point, not a ceiling |
| ISP throttling VPN traffic | Obfuscation; double VPN does not prevent DPI traffic classification |
| Gaming or streaming | Standard VPN; double VPN overhead is a net loss |
How major VPN providers implement it
ProtonVPN: Secure Core
Secure Core is architecturally distinct from any other mainstream double VPN implementation. ProtonVPN physically owns and colocates its Secure Core first-hop hardware in Switzerland, Iceland, and Sweden using its own IP address space, registered through a Local Internet Registry that Proton operates. Physical access to these servers requires a warrant served in the relevant jurisdiction and cannot be accomplished by approaching the data centre operator.
Physical-security specifics confirmed from Proton’s own documentation: the Sweden infrastructure is housed in an underground data centre; the Iceland servers are located on a former military base. Both facilities operate with full-disk encryption.
Because Secure Core first-hop servers are bare-metal colocated hardware, there is no hypervisor layer between the server and the host facility. The hypervisor-level memory exposure that affects cascade implementations running on cloud-hosted VPS servers does not apply here.
Entry nodes are Switzerland, Iceland, and Sweden (the confirmed complete set as of 2026). Exit servers are Proton’s standard fleet across 90-plus countries. The physical-security differentiation applies to the first hop; at the software and logging level, Proton’s no-log policy applies equally to Secure Core and standard servers.
Secure Core is available on paid ProtonVPN plans.
NordVPN: Double VPN
NordVPN’s own feature page describes the Double VPN traffic flow in cascade-style terms: the client encrypts once, Server 1 decrypts and re-encrypts, Server 2 decrypts and forwards. NordVPN simultaneously markets the feature as “encrypting your traffic twice,” implying nested architecture. NordVPN does not use the terms nested or cascade and does not resolve the tension between its documented flow and its marketing claim.
NordVPN does not publish an official Double VPN server count. Third-party sources report approximately ten server-pair locations; the unit (locations, countries, or discrete pairs) varies across those sources and is not confirmable from NordVPN’s own properties.
Double VPN is available as a dedicated server category in the NordVPN app and operates on the OpenVPN protocol (TCP or UDP); NordVPN’s documentation directs users connected via NordLynx to switch to OpenVPN to access Double VPN servers.
Surfshark: MultiHop and Dynamic MultiHop
Surfshark offers both preset server pairs and Dynamic MultiHop. Dynamic MultiHop allows custom pair selection from 100-plus server locations for both entry and exit; it is not restricted to preset combinations. Selection operates at the location level rather than the individual server level. The feature is available on all Surfshark plans.
Mullvad: multi-hop and DAITA
Mullvad’s multi-hop is native WireGuard-in-WireGuard: nested architecture, with both encryption layers applied on the device before sending. Mullvad retired OpenVPN on 15 January 2026 (desktop client pulled December 2025), leaving the application WireGuard-only. The entry server sees the user’s source IP and exit server address; it cannot read the traffic. The exit server sees the traffic but only the entry server’s IP.
Mullvad has developed DAITA (Defense against AI-guided Traffic Analysis) in collaboration with Karlstad University, using the open-source Maybenot framework, a Karlstad University-led project (lead researcher: Tobias Pulls) that Mullvad helps fund. DAITA is designed to defeat website fingerprinting: machine-learning classifiers that identify the sites a user visits by analysing the statistical shape of their traffic, even after content is encrypted. It operates through three mechanisms (Mullvad’s own terms in parentheses):
- All packets are padded to a constant size, removing the packet-size variation that classifiers exploit (“Constant packet sizes”).
- Dummy packets are unpredictably injected to mask routine traffic signals to and from the device (“Random background traffic”).
- Cover traffic is sent in both directions between the client and VPN server to distort the recognisable pattern of a website visit (“Data pattern distortion”).
DAITA v2 shipped on 28 March 2025. It uses approximately half the dummy packets of the original version while maintaining the same level of protection, and assigns a randomly selected dynamic configuration per connection; the tunnel’s statistical signature varies between sessions. Tobias Pulls’ 2024 evaluation of the first DAITA servers measured approximately 2 to 4 MiB of extra data and 1 to 3 seconds of added delay per website visit on desktop; DAITA v2 reduces that bandwidth overhead by roughly half.
Both can be enabled together in the Mullvad app. Multi-hop separates identity from destination at the routing level; DAITA disrupts the statistical traffic patterns a classifier could use to link them back. DAITA server coverage has expanded since v2 launched; check Mullvad’s current server list before relying on it at a specific location.
Mullvad accounts use randomly generated account numbers with no email address or personal information required. The service accepts cash and cryptocurrency payments.
IVPN: multi-hop
IVPN multi-hop has been available on all plans since the 8 May 2026 plan restructure, having previously been restricted to the Pro plan. The implementation supports two hops only: a toggle between single-hop and two-hop connections. Three-hop or four-hop configurations are not available. IVPN accounts use randomly generated account numbers; the service accepts cryptocurrency and cash payments.
Provider comparison
| Provider | Feature name | Architecture | First-hop distinction | Plans |
|---|---|---|---|---|
| ProtonVPN | Secure Core | Not publicly specified (Proton markets double encryption; nested vs. cascade not formally documented) | Proton-owned bare-metal hardware, own LIR IP space, underground data centre (Sweden) and former military base (Iceland); no hypervisor layer | Paid |
| NordVPN | Double VPN | Cascade-style (documented flow); marketing implies nested; NordVPN does not resolve the ambiguity | Standard colocation | Paid |
| Surfshark | MultiHop / Dynamic MultiHop | Not publicly specified | Standard infrastructure | All plans |
| Mullvad | Multi-hop | Nested (WireGuard-in-WireGuard, confirmed); DAITA available as statistical-analysis supplement | Standard infrastructure | All plans |
| IVPN | Multi-hop | Not publicly specified | Standard infrastructure | All plans (from May 2026) |
How to enable a double VPN
ProtonVPN: Secure Core
- Open the ProtonVPN app. In the server list tab bar, click Secure Core.
Clicking the Secure Core tab in the server list filters all destinations to Secure Core options. Each exit country can be expanded to reveal the available entry nodes via Iceland, via Sweden, or via Switzerland. - Select an exit country from the list and expand it. Each country shows the available Secure Core entry nodes as sub-options via Iceland, via Sweden, or via Switzerland. Select your preferred entry node.
Expanding an exit country reveals the available Secure Core entry nodes. Each sub-option routes the first hop through Proton’s hardened infrastructure in Iceland, Sweden, or Switzerland before exiting at the chosen destination country. - Connect. The header confirms both hops: the exit country and the Secure Core entry node are displayed simultaneously. The teal dot in the server list marks the active connection.
Once connected, the header confirms both hops simultaneously: the exit country (Belgium) and the Secure Core entry node (via Switzerland). The teal dot in the server list marks the active entry node.
NordVPN
In the app sidebar, navigate to Specialty Servers, then Double VPN. Select a server pair from the list and connect. The feature is available on paid plans.
Surfshark
In the main server list, scroll to the MultiHop section. For preset pairs, select from the list. For Dynamic MultiHop, use the custom pair selector to choose entry and exit locations independently.
Mullvad
On desktop: go to Settings, then Advanced, then VPN/WireGuard settings. Enable multihop using the toggle, return to the main screen, and click Switch location to select Entry and Exit servers separately. To enable DAITA alongside multi-hop, toggle it on from the same settings area; no server-selection change is required.
On iOS: Settings, then VPN settings, then Enable multihop.
IVPN
In the IVPN client settings, toggle multi-hop on and select entry and exit server locations from the list. The feature is available on all plans.
Frequently asked questions
What is a double VPN?
A double VPN is a configuration that routes your internet traffic through two VPN servers in sequence. The first server knows your real IP address but not your destination. The second server knows the destination but not your real IP address. Neither server has simultaneous visibility of both ends. Your ISP sees traffic to Server 1; the destination sees traffic from Server 2.
How does a double VPN work?
Your traffic is encrypted and sent to Server 1, which decrypts one layer and forwards the remainder to Server 2. Server 2 decrypts the final layer and sends your traffic to its destination. Two distinct architectures exist. In nested double VPN, both encryption layers are applied at your device before any data leaves; Server 1 never holds your plaintext. In cascade double VPN, Server 1 decrypts before re-encrypting and forwarding, briefly holding your plaintext in memory.
What is the difference between nested and cascade double VPN?
In nested double VPN, both encryption layers are applied on your device before transmission; Server 1 decrypts only the outer layer and cannot access the inner payload. In cascade double VPN, the client applies one layer and Server 1 decrypts before re-encrypting and forwarding, leaving your traffic briefly readable in Server 1’s memory. In cloud or VPS environments this exposure extends to anyone with hypervisor-level access to the host. Nested architecture eliminates this risk.
What is the difference between a double VPN and a multi-hop VPN?
No functional difference. Both terms refer to the same two-server sequential architecture. Multi-hop is the more precise term; double VPN is a marketing label popularised by NordVPN and now used generically across the industry.
Does a double VPN make you anonymous?
No. A double VPN reduces attribution risk: it makes it harder for any single party to link your identity to your destination. It does not provide anonymity. Your VPN provider still knows you are connected. The destination receives requests from Server 2’s IP address. Tracking at the account, cookie, or browser-fingerprint layer is unaffected.
Can I be traced or de-anonymised using a double VPN?
Yes, under certain conditions. A double VPN raises the cost of attribution (no single server holds both your identity and your destination simultaneously) but it does not eliminate traceability. A global passive adversary with simultaneous visibility at the entry and exit points can still perform timing correlation to link the two sessions. Your VPN provider, if it retains logs, knows you are connected regardless of how many hops follow. Tracking at the account, browser-fingerprint, or application layer is unaffected by the number of VPN hops.
Does a double VPN help bypass censorship or deep packet inspection?
No. Both hops produce identifiable VPN traffic signatures. A network that actively blocks VPNs blocks a double VPN at the first hop. Double VPN addresses attribution, not detectability. Obfuscation is the correct tool for networks that use deep packet inspection to detect and block VPN connections.
Is a double VPN slower than a regular VPN?
Yes. The magnitude depends primarily on server geography. Two servers on the same continent typically add 20 to 50ms of additional latency and the connection remains usable for most tasks. A cross-continental chain can add 200 to 350ms or more, making it unsuitable for streaming, gaming, or video calls. Double encryption overhead and potential MTU fragmentation in nested configurations add further cost.
What is the difference between a double VPN and Tor-over-VPN?
Tor uses three relays run by independent volunteers, giving it a stronger anonymity model than any single-provider double VPN. Its traffic is identifiable and actively blocked in many environments, and speeds are far lower than any VPN. Double VPN is faster but provides weaker anonymity and weaker resistance to traffic correlation by sophisticated adversaries. They address overlapping but distinct threat models.
What is the difference between a double VPN and VPN-over-VPN?
VPN-over-VPN uses two separate providers, each controlling one server independently. Built-in double VPN features use one company controlling both servers. VPN-over-VPN is the only architecture that distributes trust across two independent legal entities. With a single provider, trust is not split regardless of how many servers are in the chain.
Does a double VPN mean running two VPN apps at once?
No. A double VPN built into a provider’s app is a single client that routes your traffic through two of that provider’s servers internally. You install one app, enable one toggle, and the provider handles the two-hop routing. Running two separate VPN clients simultaneously (one from each of two independent providers) is VPN-over-VPN, which distributes trust across two companies rather than just splitting visibility within one. Built-in double VPN is simpler to use; VPN-over-VPN is the only architecture that prevents a single legal demand from exposing both ends of the chain.
What is ProtonVPN Secure Core and how is it different from standard double VPN?
ProtonVPN physically owns and colocates its Secure Core first-hop servers in Switzerland, Iceland, and Sweden; physical access requires a warrant served in the relevant jurisdiction, not a request to the data centre operator. Because these are bare-metal servers with no hypervisor layer, the memory-exposure risk that affects cascade implementations on cloud-hosted VPS hardware does not apply at the first hop. Standard double VPN implementations use leased cloud or colocation infrastructure with no comparable first-hop protection.
Do you need a double VPN for everyday use?
No. A standard VPN covers the threat model of virtually every everyday user. Double VPN is warranted only when the threat model includes an adversary capable of legally compelling or physically compromising a VPN provider.
Which VPN providers offer a double VPN feature?
ProtonVPN (Secure Core, paid plans), NordVPN (Double VPN, paid plans), Surfshark (MultiHop and Dynamic MultiHop, all plans), Mullvad (multi-hop, all plans), and IVPN (multi-hop, all plans from May 2026).
What is Mullvad DAITA and how does it relate to multi-hop?
DAITA (Defense against AI-guided Traffic Analysis) is a Mullvad feature developed in collaboration with Karlstad University. It is designed to defeat website fingerprinting: machine-learning classifiers that identify visited sites by analysing the statistical shape of traffic, even after content is encrypted. Multi-hop separates identity from destination at the routing level; DAITA disrupts the traffic patterns a classifier could use to link them back. Both can be enabled together in the Mullvad app. DAITA is specific to Mullvad and is not available in other providers’ multi-hop implementations.