Starting a Second VPN Replaces the First One's State

Two clients, two connected icons, and a belief that traffic now passes through both. Compare that belief with what each platform actually permits. A phone usually has exactly one slot for a VPN service; a desktop can run several clients that fight over the same routes and resolver. The difference between those two situations explains most reports of a VPN dropping when another starts.

The icons describe processes, not a chain.

One Slot on a Phone, Several Claimants on a Desktop

On Android the platform offers a VPN service model with a single active VPN per user profile, so starting a second one stops the first. That is the system enforcing its own rule, not a bug in either client. On a desktop, several clients can remain running simultaneously, and they then compete over the routing table, policy rules, resolver configuration and virtual interfaces. Both outcomes are the platform working as designed.

Neither outcome produces a nested tunnel by itself. A chain requires one tunnel to carry the other's encrypted packets, which is an architecture rather than a coincidence of ordering.

What the Second Client Overwrites

The second client typically installs a default route, adds its own rules and pushes its own resolver. The first may survive as a process with no traffic, or keep a route that no longer wins. Domain-specific routes are the usual casualty, which is why some destinations keep working while others fail. The visible symptom is a disconnect, and the actual state is a partial replacement.

An exit-IP check will not reveal this. It reports one address for one destination and says nothing about which routes were overwritten or which resolver now answers. To see the damage, read the routing table and the resolver state.

Nesting Is a Design, Not an Order of Clicks

If nesting is the intent, document each endpoint's outer path, its failure policy and the MTU consequences. Decide what happens when the outer tunnel drops while the inner one still believes it is connected. Starting clients in a lucky order is not a configuration, because the next update or reconnect reorders them. A nested arrangement needs the same care as any other topology.

When one connection is for work and another is personal, lean on whatever isolation or managed arrangement the platform supports. Tearing out the corporate controls is not a separation strategy.

Verify With the Application, Not the Icon

Exercise the applications that actually matter, from every context you intend to use, and include resolver behaviour and reconnects in the test. A final exit address cannot identify every overwritten route, and a green icon cannot identify any of them. Record the connection owner and the combination that is actually supported.

If a product explicitly does not support coexistence with another, a random route or permission change will not produce a maintainable deployment. It will produce one that works until the next update.

Write down which client owns the default route, which resolver answers, and what happens when each one stops.