Surfshark MultiHop, Explained: When Double VPN Actually Matters

Standard VPN use, the version most travelers actually need, routes your connection through one server and calls it done: your traffic is encrypted, your real location is masked, and that solves the two problems most people are actually worried about on public airport or hotel wifi. MultiHop routes that same connection through two servers instead of one, in sequence, which sounds like it should just be a slower version of the same thing. For most travel use cases, it is exactly that, unnecessary extra latency with no meaningful benefit. For a specific, narrower situation, it solves a real problem single-hop routing cannot.

What actually happens with two servers instead of one

With a single server, your traffic is encrypted and exits from wherever that server is located, but the server you connected to and the server that ultimately exits your traffic to the internet are the same machine. With Surfshark‘s MultiHop, your traffic passes through a second server before reaching its final destination, meaning even if one server in the chain were somehow compromised or logging traffic, it would only ever see either your original connection or your final exit point, never both together. This separation is the entire point of the feature, and it matters specifically when the threat model includes a compromised or coerced single server rather than a general concern about privacy on public wifi.

Who this genuinely solves a problem for

Journalists and researchers working in or reporting on environments with aggressive network surveillance are the clearest case where double hopping earns its added latency, since the separation of entry and exit points raises the bar for anyone trying to correlate your identity with your activity significantly higher than single-hop routing does. Someone accessing genuinely sensitive information while traveling through a country with known deep packet inspection or VPN blocking also benefits, since some MultiHop configurations route through obfuscated protocols that are harder to flag as VPN traffic in the first place.

Who does not need it

Checking email on hotel wifi, streaming a show while traveling, or general day-to-day browsing while abroad do not benefit meaningfully from double hopping. Single-hop encryption already handles the actual threats present in those situations, an untrusted local network operator or a fellow guest on the same wifi, and adding a second server mainly adds latency without adding protection against threats that were not present to begin with. Using MultiHop as a default for routine travel browsing is a bit like wearing a full harness to walk up a single flight of stairs: not dangerous, just disproportionate to the actual risk.

The speed cost is real and worth planning around

Routing through two servers instead of one adds meaningful latency, and video calls or anything requiring low-latency responsiveness will noticeably suffer compared to single-hop connections. The practical approach is switching MultiHop on specifically for the activity that needs it, then switching back to standard single-hop routing for everything else, rather than leaving it engaged as a default setting and wondering why every video call from a hotel room feels sluggish.

Battery impact is worth knowing about on mobile

Maintaining two encrypted tunnels simultaneously does draw more battery on a phone than a standard single-hop connection, noticeably so over several hours of continuous use. This is rarely a dealbreaker given how narrow the actual use case for MultiHop is, but it is worth toggling off once the specific task requiring it is finished, both for the speed benefit and to avoid an unexpectedly drained battery during a travel day where charging access is not guaranteed.

Setting it up without overthinking it

The feature is a toggle within the app rather than a separate product, selecting an entry and exit server pair from a preset list rather than requiring manual server chaining. The main decision that actually matters is choosing a server pair in countries with reasonably fast infrastructure between them, since a poorly matched pair, geographically distant with weak routing between them, will produce noticeably worse performance than a well-matched one even before accounting for the inherent double-hop latency cost.

How MultiHop compares to Tor, since the two get confused

Double-hop VPN routing and Tor’s onion routing solve overlapping but distinct problems, and conflating them leads to mismatched expectations. Tor routes traffic through typically three volunteer-run relays with a more decentralized trust model and generally weaker speed, built specifically for anonymity against a broad range of adversaries. MultiHop uses two servers operated by the same VPN provider, offering less decentralized trust, since you are trusting one company’s infrastructure rather than an independent volunteer network, but considerably better speed and a simpler setup. For most travelers whose actual concern is a specific, narrower threat rather than maximum anonymity against every possible adversary, MultiHop’s tradeoff of speed for a meaningful but not absolute increase in separation is the more practical choice.

The comparison also matters because the two are occasionally used together, and stacking them rarely produces the benefit people expect. Routing an already double-hopped connection through Tor adds latency that makes ordinary browsing genuinely unpleasant while improving a threat model that was already adequate for the concerns most travelers actually have. If your situation genuinely calls for Tor, use it directly rather than through a second layer. If it does not, the second layer was doing the work already.

The honest verdict

MultiHop is not a feature most travelers need to think about, and using it constantly out of general caution mostly just costs speed for no corresponding benefit. For the narrower case it was actually built for, an added layer of separation against a specific, elevated threat model, it does something single-hop VPN genuinely cannot, and that is worth knowing exists even if most trips never call for it.

Marko Jambrek

Licensed architect in Zagreb, 30 years of practice (sustainable design). Reviews and approves every article on this site before publication. Writes about AI tools through a lens of order and long-term value, tests before recommending.