Opening a Second Browser Does Not Create a Second VPN Route

Two browsers, two windows, one on the work account and one on a personal account, and the assumption is that they now take different paths. They do not. Profile separation keeps cookies apart, while the routing decision happens below the browser and knows nothing about which profile asked. A second path needs a rule that selects one, and there are only a few places that rule can live.

State Separation Is Not Path Separation

A browser profile isolates storage: cookies, history, extensions and sometimes credentials. That isolation is enforced inside one process tree and has no say over which interface carries a packet.

Private windows go further in appearance and no further in routing. Everything the browser sends still leaves through the operating system's chosen path unless something between the socket and the network changes it. Confusing storage isolation with network isolation produces expectations that no browser vendor promised and no test can satisfy.

What Actually Selects a Route

Four things can select a different path: a per-app VPN rule that matches the executable or package, a proxy configured inside the browser or the system, a network namespace or container, and a second physical device. Each one changes something real, and each has a cost.

A per-app rule is the usual answer on mobile platforms, where the VPN service receives a package list. On a desktop it depends on the client, and a rule that matches the executable covers every profile that executable opens. If two profiles genuinely need different paths, they usually need two processes with different identities rather than two tabs. That is why a shared browser installation can never be the boundary in a per-profile design.

App-Level Proxies Add Another Intermediary

A browser proxy setting does create a separate path, and it also creates a separate trust relationship with whoever runs the proxy. That is a legitimate arrangement for one profile, and it is not equivalent to device-wide coverage.

Choose the proxy deliberately: a SOCKS listener on the same host, an authenticated proxy inside the tunnel, or a remote service. Mixing a proxy with a full-tunnel VPN produces nested paths where the failure modes multiply.

Verify Each Browser's Real Request

Send the same request from each browser and compare the observed egress address, rather than comparing the settings pages. A configured proxy that silently fails to connect is a very common way to end up back on the default path.

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --proxy socks5h://127.0.0.1:1080 https://api.ipify.org
dig +short example.com

Then repeat the request with the proxy forced, and with the tunnel down, to see which layer actually carries traffic. Record the DNS answer as well, because a browser with its own encrypted resolver can bypass the system path entirely and still display the page you expected.

Write the intended mapping down as two lines: which process uses which path, and who owns each. Keep account identities in view too, since two paths do not stop the same login from being presented to both destinations. Re-test after the next browser update, because a proxy setting is easy to lose and hard to notice.