The basic idea
Normal VPN: your device β VPN server β destination.
Double VPN: your device β VPN server A β VPN server B β destination.
Your traffic gets encrypted twice (once for the journey to server A, again for the journey from A to B). Server A sees who you are (your real IP) but doesn't know your final destination. Server B sees your destination but doesn't know who you are.
The point isn't "more encryption" β it's that no single server sees both ends of the connection. Trust is split.
What it actually does
Distributes trust
If you trust the VPN provider entirely, double VPN gives you little. But if you're concerned that:
- The VPN provider could be compelled (subpoena, NSL, government pressure) to identify users.
- The VPN provider could be compromised or run maliciously.
- The VPN provider's server could be seized or monitored by authorities.
Then routing through two servers (especially in different jurisdictions) limits the damage. The first hop knows your identity but not your destination. The second hop knows your destination but not your identity. Neither alone can identify your activity.
Adds jurisdictional friction
If hop 1 is in one country and hop 2 is in another, legal process to identify a user requires cooperation from both jurisdictions. This is genuinely hard for most actors and impossible for some.
What it doesn't do
Doesn't add cryptographic strength
Each hop is already encrypted with AES-256 or ChaCha20. Doubling that doesn't make encryption stronger β both ciphers are already mathematically unbreakable in any practical sense.
Doesn't prevent endpoint surveillance
If your device is compromised (malware, keylogger), double VPN doesn't help β attackers see your traffic before it ever reaches a VPN.
Doesn't prevent destination-side identification
If you log into Google through a double VPN, Google still knows it's you (account identity is independent of network identity).
Doesn't make you anonymous
For real anonymity you want Tor, which uses three independent hops where each only knows its neighbors. A two-hop VPN where both hops are operated by the same provider is meaningfully weaker than Tor's three-hop design.
Performance trade-offs
Each extra hop adds:
- Latency: roughly the round-trip time from hop 1 to hop 2.
- Throughput reduction: typically 20-40% per added hop.
- Connection time: the initial handshake takes longer.
Typical double VPN connection: 30-50% slower than single-hop, 50-100ms additional latency. Fine for browsing, noticeable for streaming, painful for gaming.
When double VPN is actually useful
- Higher-threat use cases. Journalists sourcing in environments where the source could be harmed by identification. Activists in jurisdictions with adversarial governments. Researchers handling data that could endanger informants.
- Cross-jurisdictional separation. When the legal regime of one country covers the first hop and another country covers the second.
- Defense in depth for sensitive operations. Penetration testers, security researchers, threat intelligence analysts β anyone whose work involves interacting with infrastructure they don't want traceable to them.
When double VPN is overkill
- Routine privacy. If you just don't want your ISP to see what you're doing, single-hop VPN handles that fully.
- Public WiFi protection. Single-hop is sufficient for protecting against local network attackers.
- General-purpose use. Email, browsing, social media β the performance penalty isn't worth the marginal improvement.
Providers that offer multi-hop
If you genuinely need this feature:
- Mullvad β supports custom multi-hop configurations using their WireGuard endpoints.
- NordVPN β "Double VPN" servers available, fixed pairs.
- ProtonVPN β "Secure Core" servers route through hardened first hops in Switzerland, Sweden, Iceland.
- Surfshark β "MultiHop" servers, also fixed pairs.
- IVPN β flexible multi-hop with user-chosen endpoints.
All paid services. The infrastructure cost of multi-hop doesn't fit ad-supported pricing models β which is one reason we don't offer it.
The DIY approach
Technically you can build your own multi-hop by chaining two separate VPN services. The first VPN runs on your device; the second VPN runs in a virtual machine that you connect to via the first VPN. Hop 1 (your device's VPN) sees your real IP. Hop 2 (the VM's VPN) sees the VPN-issued IP from hop 1.
Effort is high; benefit is real if your threat model warrants it. Most users won't bother.
Our position
We don't offer double VPN. Our product is "fast, free privacy for normal users on hostile networks." Multi-hop serves a different population β high-threat users who can tolerate (or even need) the performance penalty for the additional trust distribution. Those users are better served by paid providers built around that use case.
If you need this feature, the providers above are legitimate. We're not the right tool for that job.