Short answer: a multihop VPN sends a covered connection through an entry VPN server and then a separate exit VPN server before it reaches the website. It can make it harder for an observer at one hop to link your home IP with the final destination, if the route and threat model support that separation. It does not make you anonymous, erase trust in the VPN operator, or guarantee faster or safer browsing.
Use two hops only when you can name the observer or risk the extra hop is meant to address. For ordinary privacy from the local network or ISP, a well-configured single VPN connection may already address that goal. Multiple hops usually add distance and complexity. Provider features, server availability, and app controls change; check the current documentation for your device before enabling one. This guide describes routing tradeoffs, not a provider ranking.
What the two hops do
- Your device connects to the entry server. Your ISP or local Wi-Fi can see a connection to that first VPN server, plus timing and traffic volume. The entry operator can receive your source IP and see the next VPN hop, depending on the service's design.
- The entry server forwards the connection inside a second tunnel. In a supported multihop design, the traffic remains protected between the VPN endpoints. The entry server is not the server that makes the final internet connection.
- The exit server connects to the destination. The website sees the exit server's public IP. The exit side handles onward traffic; HTTPS still protects page contents between your browser and the site, while unencrypted traffic has less protection after it leaves the tunnel.
The exact information available at each point depends on the implementation, encryption, operator access, and any logging or monitoring. “Two locations” does not by itself mean two independent companies or independent trust domains. If both hops belong to one provider, that provider controls both ends of the route. A separate-provider chain has its own setup and routing risks and should not be assumed to work like a built-in multihop feature.
Decide whether the extra hop fits your situation
| Your situation | A second hop may be relevant when… | Check before enabling it |
|---|---|---|
| You mainly want to reduce what public Wi-Fi or your ISP sees | A functioning single-hop VPN already hides the covered traffic's destinations and contents from that local network, though it can see the VPN connection and metadata. | Confirm the VPN actually covers the apps and traffic you care about. See what a VPN can and cannot hide. |
| You are concerned about monitoring at one VPN exit or data-center path | A provider's multihop feature may separate the source IP from the exit connection across entry and exit servers. | Read the provider's architecture and threat description. Two hops do not rule out timing correlation, operator-wide access, or other monitoring across the route. |
| You need a particular exit location | A feature may let you select an entry region and a different exit region, or may select the entry automatically. | Verify which location websites will see and whether the exact pair is supported. A location change does not guarantee access to a site or satisfy its terms. |
| You need low delay, stable calls, or predictable throughput | Only if your measurements show the extra route works for your connection and task. | Test latency and the apps you rely on. Added routing commonly raises latency and can reduce speed; congestion and peering can make results vary. |
Before you switch it on
- Write down the observer you are concerned about and what information you want to keep separate. A VPN is not a fix for a compromised device, a signed-in account, cookies, or identifying details you submit.
- Check whether the app has a built-in multihop mode. Use its own connection display to confirm the entry and exit locations; do not infer two-hop routing from a country label alone.
- Check which devices, protocols, and server pairs support the feature. Settings can be platform-specific, and some combinations may fail to connect.
- Compare one-hop and multihop behavior for the task you care about, such as a call or file transfer. Treat speed tests as measurements of your route at that time, not a general provider ranking.
- Keep a simple way back to the previous setting. If the feature interrupts work, disconnect or return to the known configuration and consult the provider's current support instructions.
If you want to check the public IP a browser request presents, the site's IP address tool makes an external lookup request. That observes this browser's route at that moment; it does not verify every app or prove that all device traffic uses both hops.
Provider examples are implementation-specific
Mullvad documents an app setting for choosing an entry and exit location and says multihop can affect speed and latency. Its current app behavior and supported modes vary by platform, so follow its up-to-date app guide. Proton describes Secure Core as routing through a Secure Core server before a second VPN server, and its support guidance notes the latency cost. These are descriptions of those providers' features, not independent verification of every security or privacy claim.
For the larger trust question, see the checklist for evaluating a VPN's logging claims and the visibility guide. A second hop changes the route; it does not remove the need to evaluate who operates the service and what the provider says it collects.
Common questions
Is double VPN always more secure than one VPN server?
No universal guarantee follows from the hop count. A properly designed multihop route may reduce what an observer at one endpoint can link, but it adds another server and route and still depends on the operator, configuration, and threat model.
Will multihop slow down my VPN?
It can add latency and reduce speed because traffic takes an additional routed leg. The result depends on the locations, networks, server load, and your connection; test the route you intend to use.
Can the first VPN server see the websites I visit?
In a built-in multihop design, the entry server forwards traffic toward the exit server rather than making the final website connection. What each operator can observe depends on implementation and monitoring. HTTPS continues to protect page contents in transit, but it does not hide all metadata.
Does using two VPN providers mean neither can connect my IP to my browsing?
It may divide some visibility between providers when the chain is correctly configured, but setup errors, traffic outside the chain, correlation, and provider practices matter. A manually chained setup is not interchangeable with a provider's built-in multihop feature.
Sources
- Mullvad: Multihop with WireGuard — setup, entry/exit routing, and stated latency and speed tradeoffs (last updated 2024-04-17; accessed 2026-11-03).
- Mullvad: Using the Mullvad VPN app — current app feature behavior and platform-specific notes (accessed 2026-11-03).
- Proton VPN: Secure Core — provider description of routing through Secure Core and a second VPN server (accessed 2026-11-03).
- Proton VPN Support: Understanding and increasing VPN connection speeds — provider's stated latency and performance tradeoff for Secure Core (accessed 2026-11-03).
- EFF Surveillance Self-Defense: What should I know about encryption? — VPNs shift trust to the provider; HTTPS protects content in transit (accessed 2026-11-03).
Impact — TODO: apply/approval and configure referral URL — referral link not configured.
PartnerStack — TODO: apply/approval and configure referral URL — referral link not configured.
CJ Affiliate — TODO: apply/approval and configure referral URL — referral link not configured.