VPN Before Tor: What the Order Actually Changes

Connecting the VPN first produces a specific chain: device, VPN endpoint, Tor entry, Tor circuit, destination. Your local network sees one encrypted connection to the VPN, and the Tor entry node sees the VPN exit as the immediate source instead of your provider address. The VPN operator, in turn, sees connections toward Tor entry infrastructure and can infer Tor use from the destinations. Each observer loses something and gains something, which is why the ordering is a trade rather than an upgrade.

Nothing in that chain changes what the website learns from your account, cookies or typed details.

What the Order Changes

The local network and the ISP lose direct visibility of your Tor traffic, because the first hop is now an encrypted tunnel to a provider. The Tor entry guard loses your home address and sees the VPN exit. The VPN provider gains the metadata that your ISP used to hold: which addresses you contact, at what times, and how much data moves.

Past the entry guard the circuit behaves as before. Relays still separate the roles of entry, middle and exit, and the VPN does not see the final content any more than your ISP did.

Confirm the Path That Is Actually Used

Split tunnelling is the usual reason the intended chain is not the real one. If Tor Browser is excluded from the tunnel, or a second profile routes differently, the entry guard sees the provider address again while the interface still looks connected. Check the route and the observed exit rather than the icon.

ip route get 1.1.1.1
ss -tunp | grep -E 'tor|9150|9050'
curl --socks5-hostname 127.0.0.1:9150 https://check.torproject.org/api/ip
resolvectl status | grep -A3 'DNS Servers'

The SOCKS request through port 9150 is answered by Tor Browser's own client, so a reply of IsTor true confirms the browser's circuit, not that every other application uses it. Resolver output is worth recording because DNS can leave by a path the tunnel does not cover. Keep both outputs with a timestamp. They are the baseline for the next comparison.

Compare with a direct request from a normal terminal: if that also reports Tor, something else is redirecting traffic and the chain is not what the design assumed.

Watch What Happens When the Tunnel Drops

A client that silently falls back to the local interface changes the source the entry guard sees, and the user is usually unaware because the page still loads. That is the failure worth testing, not the happy path. Disconnect the tunnel deliberately and watch whether Tor traffic stops or continues unprotected.

nft list ruleset | grep -i -E 'vpn|tun|drop'
iptables -S | grep -i tun
ip link show | grep -E 'tun|wg'

Firewall rules that block outbound traffic outside the tunnel are the only reliable fallback control, and they must cover both the browser's SOCKS client and any other application you care about. A browser extension is not a device VPN and does not affect other programs or external viewers.

Decide Whether the Extra Layer Earns Its Trust

The Tor Project advises against stacking a VPN underneath Tor unless you can evaluate the setup yourself. Their stated reason is the added dependency: another party, another account and another failure mode. If the goal is to keep your ISP from seeing that you use Tor, the VPN addresses that specific observer. If the goal is stronger anonymity against a global observer, the VPN does not supply it.

The reverse ordering exists too, and the names are not interchangeable: Tor over VPN and VPN over Tor describe different trust relationships and different failure behaviour. Read the comparison before mixing them.

Write down which observer you are trying to move, then verify that the real path matches the design, then verify the failure behaviour. If those three answers do not justify the extra account and configuration, the documented Tor Browser setup has fewer parts to get wrong.