Tor Browser Covers One App, Not Your Whole Device
The browser routes its own connections through Tor and nothing else. Check which process owns a connection before assuming the rest of the machine follows.
Tor Browser sends its own connections through a local proxy and routes them into the Tor network, and it does not move the rest of the machine. A mail client, a sync daemon and a second browser keep whatever settings they had, which is why a clean result in one window can coexist with direct connections behind it. Four checks separate what is covered from what only looks covered. Start with the one that names a process.
What the browser actually proxies
Inside the browser, traffic goes to a local SOCKS listener that Tor Browser starts for itself, and the browser is configured to use it. The circuit selection, the identity isolation and the fingerprinting protections all live in that pairing. A file saved to disk carries none of it, and opening that file in an external viewer starts a new program with its own network behaviour.
That is also why the familiar public-address page proves so little. It reports the exit used by the browser that loaded it and cannot observe another application at all. Treat the result as evidence about one program, not as a statement about the device.
Which process owns each connection
List the sockets and the processes behind them. Look for anything that is not the browser talking to a local listener:
ss -tunp
ss -tunp | grep -E 'tor|firefox'Anything with a public destination is a connection that bypassed the circuit. If you find one, identify the program before changing anything else, because the fix differs for each client:
curl --socks5-hostname 127.0.0.1:9150 https://check.torproject.org/api/ipThe -hostname form matters because it asks the proxy to resolve the name. Resolving locally and handing the proxy an address discloses the destination even when the connection itself is proxied.
Whether the protocol is carried at all
Tor relays carry TCP streams. Applications built around UDP, such as some voice and game clients, do not behave over the network the way a web page does, and forcing them through a proxy usually fails rather than protecting them.
| Coverage model | What it covers | What it leaves alone |
|---|---|---|
| Tor Browser | Its own browsing and downloads | Every other application |
| Proxy setting in one app | That app, if it honours the proxy | Its DNS behaviour and other programs |
| System VPN | Traffic routed through the tunnel | Browser fingerprint and identity |
| Whole-device routing | The operating system's traffic | Application-level identity signals |
If the app you care about depends on UDP, a browser setting is not the answer, and neither is a proxy variable that the app ignores. The requirement becomes a different design with different failure modes.
The coverage you actually chose
A system VPN is broader in scope than a browser and narrower in purpose. It can carry several applications when the routes and the platform support are configured for that, but it does not provide fingerprinting resistance, and a VPN exit is not an anonymity network.
Full-device coverage is a system design rather than an installer. It routes the operating system's traffic instead of one process, and it brings its own operational limits that a browser download does not.
Decide which question you are answering: which app is protected, or whether every packet is. The first is a browser setting and the second is a routing policy. Confusing them is how a machine ends up with one protected window and five unprotected processes. Write the answer down before installing anything else.