You connect to a VPN first, then use Tor inside it. Your ISP sees only the VPN, and Tor sees the VPN IP as the client.

Pros

• Hides Tor usage from ISP or a restrictive local network.
• Adds a layer between you and the entry guard.

Cons

• VPN provider sees your real IP and the fact you are using Tor.
• If the VPN logs or is compromised, it becomes a correlation point.
• You still rely on Tor exits for destination access.

Best for

• Networks where Tor is blocked.
• Situations where you want to avoid local surveillance of Tor usage.

VPN over Tor#

You connect to Tor first, then tunnel a VPN through it. The VPN sees the Tor exit IP instead of your real IP. The destination sees the VPN egress IP.

Pros

• Destination sees a VPN IP, not a Tor exit (useful when sites block Tor).
• VPN does not learn your real IP.

Cons

• Most VPNs require UDP (WireGuard). Tor does not carry UDP.
• You must use a TCP VPN profile (OpenVPN TCP), which is slower and more fragile.
• The VPN can still log your traffic and correlate sessions.

Best for

• Accessing services that block Tor exits.
• Cases where you prefer a VPN IP at the destination.

How the communication path changes#

Adding a VPN changes who can observe the edges of your traffic and where correlation is possible.

Why this conflicts with Tor's philosophy#

Tor is built on distributed trust. A VPN collapses that model back into centralized trust.

• Tor: no single observer should see both identity and destination.
• VPN: one provider can see the full session metadata.

So adding a VPN directly undermines Tor's core design goal.

How tracking risk increases#

Using a VPN can increase tracking risk in several ways:

• Stable identity anchor: VPN accounts are tied to payment, email, and device fingerprints.
• Session correlation: a VPN can correlate login times with Tor entry usage.
• Single choke point: a provider can log or be compelled to log connection metadata.
• Exit correlation: if the VPN and Tor exit are observed together, timing links become easier.
• IP reputation linkage: VPN exit IPs are often flagged, which changes your observable pattern.

Decision matrix (practical)#

Reality check: theory vs practice#

Tor is a protocol. Anonymity in the real world is mostly about behavior: what browser you use, what accounts you log into, what you download, how you isolate sessions, and whether your network setup leaks.

In practice, many users fail "Tor best practices" (often without realizing it). When that happens, the deanonymization path is usually the endpoint or surrounding metadata, not Tor's cryptography breaking.

Another practical consideration: in some environments, using Tor at all can be a high-signal event. Even if an ISP cannot see your destination, it can often see that you're using Tor (connections to known guards/bridges). In some jurisdictions and organizations, Tor traffic is treated as suspicious, which can put you into a smaller bucket for throttling, blocking, or targeted scrutiny. And against well-resourced adversaries, timing/correlation attacks are more realistic than the simplified "three hops = anonymous" story.

A pragmatic compromise: Tor over a reputable VPN#

If your primary risk is local visibility ("my ISP/network seeing Tor") and you cannot reliably maintain strict Tor opsec, Tor over VPN can be a practical compromise:

• Your ISP sees a VPN tunnel rather than Tor traffic.
• The Tor guard sees the VPN egress IP rather than your home IP.
• You trade that for extra trust in the VPN provider.

This is not the theoretical "best anonymity" setup. It's a pragmatic trade: you reduce ISP visibility and Tor-blocking friction, at the cost of adding a VPN provider you must trust.

Why a VPN kill switch matters (and why disconnects are risky)#

If you choose Tor over VPN, make sure the VPN has a real kill switch (block all traffic if the tunnel drops).

When the VPN disconnects unexpectedly:

• Your ISP can immediately see Tor usage again (the very thing you were trying to hide).
• Your Tor client can reconnect to the guard over your normal network (not the VPN), changing what the entry side can observe.
• In the worst case, you may reconnect to the same guard set without the VPN, revealing your real IP to an entry that previously only saw your VPN egress IP (a link you were trying to avoid).
• Any non-Tor traffic on your machine may fail open and go out over your real IP (apps, updaters, DNS, telemetry).
• Depending on your setup, some tools can silently fall back to a direct connection if the proxy/tunnel disappears.

A kill switch prevents "oops, I'm online without the tunnel" moments by failing closed until the VPN reconnects.

Operational safety checklist#

• Use end-to-end HTTPS regardless of setup. Tor exit nodes can see plaintext otherwise.
• Disable WebRTC and watch for DNS leaks if you are not using Tor Browser.
• Avoid mixing identities across circuits (logins, cookies, browser profiles).
• Use bridges before VPN if the only issue is network blocking.
• Treat VPN logs as a real risk. Pick a provider with strong public audits and transparency, but assume logs can exist.

So, is it safe?#

It is safe only relative to your threat model.

• If your goal is to hide Tor usage from a local network, Tor over VPN helps.
• If your goal is to avoid Tor exit blocking, VPN over Tor helps.
• If your goal is maximum anonymity, Tor only is safer because it minimizes trust and correlation points.

Next up#

Part 3: How to Use Tor Safely. /posts/tor-protocol-part-3