New Tor Circuit vs VPN Server Switch: What Actually Changes
A circuit change moves the Tor path; a server switch moves the tunnel endpoint. Which one changes the address a site sees depends on the order.
Changing a Tor circuit and switching a VPN server both feel like getting a new route, and they break in different places when you treat them as the same button. One asks the Tor client to build a different path for a site; the other asks the VPN client to connect to a different endpoint. Neither is a reset, and the address a website ends up seeing depends on which of the two sits closer to the destination. Here is how I decide which control to reach for, and what I check afterwards.
Two operations in two different layers
Tor is an overlay. Your client picks a guard relay, a middle relay and an exit relay, then carries TCP streams through that circuit; the destination sees the exit and nothing else. A circuit change is a decision made inside Tor about which relays carry a stream.
A VPN is a tunnel underneath. The client chooses an endpoint, wraps traffic in an outer layer, and whatever comes next sees the endpoint's address. A server switch is a decision about where the outer path terminates.
Because the layers are independent, one operation can be invisible at the far end of the connection. That asymmetry explains most of the confusion around these two controls.
What New Tor Circuit for this Site does
New Tor Circuit for this Site, in the site information panel, closes the streams Tor is carrying for that site and builds a new circuit for the next request. Tabs, cookies, logins and the rest of the session stay exactly where they were, which is the point: you keep the session and change the path.
That makes it the right tool for a narrow failure: an exit relay the destination blocks, a captcha loop that follows the exit, or one site stalling while every other site is fine. The circuit display in that same panel lists the three relays, so you can confirm that the exit really changed instead of assuming it.
Watch the guard. Tor keeps a small set of entry guards, and a circuit change normally reuses the same guard, so the first hop on the network does not move. New Identity is the larger reset, closing tabs and clearing browsing state before building a new circuit, and the identity controls are documented separately for a reason: it is a different operation with a different cost.
What a VPN server switch does
The client tears down the tunnel and connects to another endpoint. The next hop outside the tunnel, whether that is a Tor guard or the destination itself, sees a different source address. Connections inside the tunnel break and must be re-established, so pages can hang until they time out rather than reload cleanly.
Nothing above the tunnel is rewritten, but the teardown is not invisible. In a VPN-first setup the exit is still chosen by Tor, yet dropping the tunnel kills the TCP connections Tor holds to its guard, so Tor tears those circuits down and builds new ones, re-choosing an exit. The site can therefore see a different exit address after a switch, even though the switch itself never selected one. What the switch decides is the address the guard sees; the rebuilt circuit is what re-chooses the exit. If you switched servers only to change what a site sees while Tor is in front, you moved a layer the site never observes directly, and any change the site notices came from the rebuild rather than from the switch.
A switch also only affects the route the client's owns. A browser reusing an open connection can look stuck on the old path until it reconnects, and a cached DNS answer is the other usual holdout. Reload first, then judge.
Order decides what the destination sees
The two orderings answer different questions. With the VPN in front of Tor, the guard and the relays see the VPN endpoint while the destination sees the Tor exit. With Tor in front of the VPN, the destination sees the VPN endpoint, because the tunnel is the last thing the traffic passes through.
| Setup | Switch VPN server | Change Tor circuit |
|---|---|---|
| VPN, then Tor | Guard sees the new address; the rebuilt circuit re-chooses the exit, so the site may see a different exit, not necessarily the same one. | Site sees a new exit; the VPN endpoint is untouched. |
| Tor, then VPN | Site sees the new VPN address immediately. | Circuit is rebuilt, but the site still sees the VPN address. |
So an IP lookup reports what the destination saw, not the path that carried it. A service showing the exit in one setup and the VPN in the other is behaving correctly, not leaking.
What neither operation does
Neither one deletes an account's identity. A logged-in session is a cookie plus a server-side record, and changing a path touches neither. A stable browser profile, the same login and the same fingerprint survive both actions.
Neither one is evidence either. A website reports an address it observed during a request; it cannot report your relay path or whether your VPN dropped ten minutes earlier. If you need that timeline, write it down at the time, because it cannot be reconstructed from the far end afterwards.
Match the control to the symptom
Start from what failed, not from which button looks more thorough:
- One site blocks you, captchas loop, or a single site is slow: new circuit for that site.
- A VPN-only setup needs a different visible address: switch the server.
- You expected an exit but the site reports your VPN: check the order, Tor is behind the tunnel.
- Tabs closed and everything reset: you used New Identity, not a circuit change.
- The exit looks unchanged after a circuit change: relays can legitimately repeat, and the guard will not move at all.
Write down the action and the symptom it was meant to fix before you change anything else. Two switches in a row produce a comparison that cannot be interpreted, and repeating both when only one layer is misbehaving is how a five-minute check turns into an afternoon.