Tor over VPN: who sees your IP, and who sees Tor use?

You connect the VPN client, wait for the tunnel, then open Tor Browser and let it build a circuit. That unremarkable sequence is what decides who sees what. In that order the Tor entry relay greets your VPN exit address, and your VPN provider greets a public guard relay. Do it the other way round and both observers change. Either order is worth walking through, because client settings quietly break the sequence people believed was in place, and the check that catches it is the same in both cases.

Start with the order, not the product

Two arrangements get called "VPN with Tor", and only the first is common. In Tor over VPN the tunnel is already up when Tor starts, so the tor process sends its guard connection into the tunnel like any other outbound traffic. In VPN over Tor, Tor comes up first and the VPN session itself travels through the circuit, arriving at the provider from a Tor exit.

What changes between them is which address sits at the far end of the outermost link. Every observer sees only the previous hop, never the whole path: the guard sees whoever connected to it, and the VPN server sees whoever connected to it. Tor does not carry your local tunnel address outward, and there is no field in the protocol where it could.

In both orders the destination website still sees a Tor exit, and neither order changes what that site learns from your login. The difference is confined to the two edges.

What the Tor entry relay sees

The entry, or guard, accepts an ordinary TCP connection on a relay port and begins a TLS handshake with the client. In a Tor-over-VPN setup the source of that connection is your VPN exit. In a Tor-first setup it is whatever address your machine used to reach the Tor network, normally your home connection.

That answers the IP half of the question, but only if the tunnel actually carried the connection. The Tor process reaches the guard with its own socket, and that socket is not governed by Tor Browser's proxy settings. The browser talks to the bundled tor process over SOCKS on 9150, and tor then opens its own connection using the kernel routing table. A Socks5Proxy line in torrc, or a client transport, changes that path. Nothing else does.

On Linux you can read the answer off the machine. Ask the kernel which interface it would use for an arbitrary public address, then look at the local address of the established connection:

ip route get 203.0.113.10
sudo ss -tnp | grep -i tor

If the route says dev wg0 or dev tun0, and the local address on the established connection is the tunnel address, Tor is inside the VPN. If the route names your physical interface, it is outside, whatever the client's own indicator claims.

What your VPN provider can see

The provider terminates your VPN session, so it sees the addresses you connect to. Guard relay addresses are published in the public consensus and their ports are well known, so matching one is a list lookup rather than deep packet inspection. A provider does not need to break Tor to know that a session is Tor.

What it does not see is the rest of the circuit. The middle relay and exit are chosen inside Tor, and the provider only handles the link to the guard. Page content stays inside TLS that terminates at the exit, and name resolution for Tor traffic happens at the exit too, so there is no DNS query at the provider to correlate with a destination.

Bridges with obfs4 change the lookup, not the topology. A bridge address is absent from the public relay list and the traffic is shaped to avoid looking like Tor, so an operator that only compares addresses will not flag it. The session still comes from your VPN client, and the provider still sees one endpoint, one volume and one timetable.

Capability is not a retention policy

An operator that can observe a connection has not promised to keep it. Logging is a separate decision, written down in a policy, limited by jurisdiction, and checkable only through evidence you already trust. A no-logs label does not change the network role described above.

Account identity usually matters more than the exit address. If you signed in with an email address, or paid by card, the provider can tie the session to you without logging a single destination. Rotating exit IPs does nothing about that.

Check coverage before you trust either answer

Most people who believe they run Tor over VPN are running part of it. Split tunneling that excludes Tor Browser, a kill switch that covers the browser but not the tor service, a startup unit that runs before the tunnel is up, and an IPv6 path around the tunnel are the usual four.

Reading the client's status screen tests none of them. The test that does: leave Tor Browser running, bring the tunnel down, and watch whether the guard connection survives on the physical interface.

The order I check in, stopping at the first failure:

• ip route get 203.0.113.10 returns the tunnel device.
• ss -tnp | grep -i tor shows the guard connection with a tunnel local address.
• ip -6 route has no default route outside the tunnel, or IPv6 is off in the client.
• Dropping the VPN ends or reroutes the tor connection instead of leaving it on the physical link.

Which order fits what you are defending

Both orders hide something and expose something, so the answer is a choice about the observer you care about.

Read it by column until a row matches what you are trying to prevent. If the worry is a local network or an ISP that records or blocks Tor, Tor over VPN handles it. If the worry is that the VPN operator learns your home address, VPN over Tor handles that, and pays for it by exposing Tor use to your own network and your home address to the guard.

Neither arrangement leaves both edges blind. Adding an observer does not remove one. The Tor Project's note on running a VPN with Tor makes the same point from the other direction: the tunnel changes who is trusted and which failure paths exist, so it is not an upgrade to add without deciding what you wanted hidden.

Decide the observer first, pick the order second, and verify with ip route get and ss rather than with the client's indicator. If the observer is someone who can compel the VPN provider itself, no ordering choice fixes that.