Skip to content

Nested + Parallel

This is the power configuration. Run multiple chains in parallel, where each chain passes through multiple VPN providers. You get the split-knowledge privacy benefits of nesting AND the throughput benefits of load balancing.

No single provider sees both your real IP and your traffic destinations. Traffic spreads across multiple paths for near line-speed performance.

|-> VPN #1a -> VPN #2a -|
Wirebump -> ISP -> -> Internet
|-> VPN #1b -> VPN #2b -|

Two parallel chains, each with two hops. Four total tunnels. Traffic load-balanced across both chains using ECMP routing.

What each provider sees:

ProviderKnowledge
VPN #1a and #1bYour real IP, but only see connections to VPN #2 servers
VPN #2a and #2bAll your traffic and DNS, but only see VPN #1’s IP

Neither entry nor exit provider has the complete picture. And because traffic splits across multiple paths, you get aggregate bandwidth from all tunnels.

The numbers in the circuit builder represent fanout at each layer.

Circuit path calculator showing parallel circuit math

Example: 2 x 1 x 1 = 2 means:

  • 2 servers at Layer 0 (entry)
  • Each L0 connects to 1 server at Layer 1
  • Each L1 connects to 1 server at Layer 2 (if present)
  • Result: 2 independent chains running in parallel

Each chain is a complete nested path through your VPN providers. Traffic distributes across all chains.

2x2 parallel multi-hop circuit topology

This diagram shows a 2x2 configuration:

  • Bottom: Your Wirebump device
  • Layer 0: Two Mullvad VPN servers (entry layer) with PQ encryption
  • Layer 1: Two Proton VPN servers (exit layer)
  • Top: Internet

Traffic enters through either L0 server, passes through the corresponding L1 server, and exits to the internet. The x2 indicator shows traffic is load-balanced across both paths.

The balanced choice for privacy and performance.

  • 2 servers at Layer 0 (entry)
  • 2 servers at Layer 1 (exit)
  • Each L0 connects to one L1
  • 2 independent 2-hop chains running in parallel

Privacy: Split knowledge between entry and exit providers. Performance: Double the throughput of a single chain.

2x3 (6 tunnels, 2 chains with 3 exits each)

Section titled “2x3 (6 tunnels, 2 chains with 3 exits each)”

Maximum throughput with nested privacy.

  • 2 servers at Layer 0
  • Each L0 fans out to 3 servers at Layer 1
  • 6 total exit points

Privacy: Same split knowledge as 2x2. Performance: Higher aggregate bandwidth from more exit tunnels.

For additional separation:

Wirebump -> L0 (entry) -> L1 (middle) -> L2 (exit) -> Internet

Example: 2 x 2 x 2 creates 2 independent 3-hop chains with 8 total tunnels. This mirrors Tor’s guard/relay/exit model but with commercial VPN providers you choose.

No single entity learns both who you are and what you do online.

Your entry provider sees your real IP but cannot see your traffic destinations. Your exit provider sees your traffic but cannot see your real IP. Even if one provider is compromised, they only have half the picture.

For a deeper explanation of the privacy model, see Split Knowledge.

Commercial VPN servers have bandwidth caps per user. By spreading traffic across multiple servers in parallel, you aggregate bandwidth and approach your connection’s actual capacity.

A 2-tunnel parallel setup can push roughly 2x the throughput of a single tunnel. A 4-tunnel setup can push roughly 4x. Real-world results depend on your ISP speed and the VPN servers you select.

Mix vendors across layers for additional trust separation:

LayerProviderWhat They See
Entry (L0)Mullvad VPNYour IP, connection to Proton VPN servers
Exit (L1)Proton VPNYour traffic, Mullvad VPN’s IP

Even if both providers kept logs (they claim not to), they would need to collude and correlate their separate datasets to reconstruct your activity. Different jurisdictions, different companies, different data.

Use different providers at different layers. This maximizes trust separation. Put Mullvad VPN at entry (post-quantum protection for your IP) and Proton VPN at exit, or vice versa.

Start with 2x2. It is the sweet spot for most users. Good privacy, good performance, stays within typical device limits.

Match locations. Placing entry and exit servers in nearby cities minimizes latency. A New York entry to New York exit adds less overhead than New York to Tokyo.

Test before committing. Deploy a circuit and run speed tests. If throughput is lower than expected, try different servers or adjust your topology.


Mullvad and Mullvad VPN are trademarks of Mullvad VPN AB. Proton VPN is a registered trademark of Proton AG.