Is Tor going through the VPN? What split tunneling changes

Here is the belief worth testing: a connected badge means Tor's traffic went through the VPN first. The inference fails more often than it should, and it fails quietly. A split-tunnel matcher can leave the Tor process outside the tunnel while the device stays connected, and both observations remain true at once. The icon reports an interface; the path your packets took is a separate question. Answer it from the routing and the matcher, not from the badge.

What a connected badge proves, and what it does not

A connected VPN means an interface is up and a tunnel to the peer exists. Tor's entry connection is a different flow, created by a different process, and whether it enters that tunnel depends on the matcher and the routing table applied to it. Exclude the process and the VPN still connects, Tor still builds a circuit, and your intended ordering did not happen. The two observations answer different questions, which is why neither one alone settles the ordering.

That gap is not a bug in either tool. It is what an exclusion rule is for, and the rule was probably written for a reason someone still remembers.

Which matcher the client applies to a connection

What decides the path is the matcher the client applies to each connection: a process name, a destination prefix or a route entry, depending on the client. A shortcut on the desktop matches none of them, because it is a launcher, not a policy unit. Read the client's rule set and name the unit it actually tests before you reason about Tor. If the client matches by destination, the question becomes which prefixes sit inside the tunnel rather than which program is running.

A destination-based rule that carries only private office prefixes is a common shape, and it leaves ordinary Tor entry connections direct by design. That is the policy working as configured, and it is not the VPN-before-Tor ordering no matter how healthy the badge looks. Write the matcher and the excluded prefixes on the same line of your notes, because that pair is the rule.

What happens to Tor when the tunnel drops

Now take the tunnel away and watch what Tor does, because a policy that only holds while the network is healthy is not the policy you described. The client might refuse direct traffic while it is down, silently allow it, or reconnect and reapply the rule a moment later. A manual disconnect and a crash are different events, and the crash is the one nobody rehearsed. Test with harmless traffic and record which of the three outcomes you actually observed.

Read the client's documented behaviour as well, but treat the documentation as a hypothesis until your test agrees with it. Vendors describe the default; your profile decides the exception.

Why the exit address cannot answer the entry question

A site reached through Tor reports the exit relay's address, which tells you where the circuit emerged and nothing about how the first hop left your device. People quote that address as proof of VPN-first ordering, and it cannot carry that weight. The entry question is local: which interface carried the connection to the first relay, and which source address the VPN peer would have seen. Answer it with a route lookup or a packet capture on the device, not with a website.

Two different paths can produce the same exit country, so a matching result proves even less than it appears to. Compare interfaces, not geography.

Applications that never inherited the browser's settings

A document viewer, a sync client and a package manager each make their own connections, and none of them inherits the browser's proxy settings. Each one follows the client's matcher, its own configuration or the system proxy, and the combination is rarely written down. That is how an exception list grows: one application at a time, each addition reasonable, until nobody can say what the list covers. Keep a short diagram per application instead, naming the matcher, the route and the failure behaviour.

If the extra VPN layer serves no purpose you can state, dropping the layer is easier to verify than maintaining a long list of exceptions. The Tor Project's note on VPNs approaches the same ordering question from the other direction. Fewer moving parts means fewer assumptions to re-test after the next client update.