A VPN routes selected traffic through a tunnel, a proxy handles traffic from configured applications, and Tor routes supported traffic through multiple relays. Each changes the trust and routing model. None makes every application anonymous merely by changing the address a website sees.
Choose the mechanism for the task
| Mechanism | Typical scope | Trust question |
|---|---|---|
| VPN | Routes defined by the device or VPN policy | What can the tunnel operator observe or retain? |
| Proxy | Applications explicitly configured to use it | Which requests pass through the proxy, and is transport protected? |
| Tor Browser | Browser traffic through Tor's relay design | How do destination security and account identity affect the session? |
A workplace VPN may intentionally route only internal networks. A browser proxy does not automatically cover a game, updater, or terminal command. A VPN provider's “connected” indicator says the tunnel is up, not that every possible path follows the same policy.
Compare the observed connection
- Record the public address before connecting.
- Connect the intended tool and check the address again.
- Compare the browser with a terminal or relevant application.
- Inspect IPv4, IPv6, DNS settings, and split-tunnel routes where supported.
For example, a browser shows a proxy exit while curl https://thisismyip.com/ip shows the ordinary ISP address. That can be expected if curl is not configured to use the browser's proxy. Determine the intended scope before calling it a leak.
Understand the remaining observations
HTTPS still matters through a VPN or Tor. The destination can see the requests it receives, and logging into an account identifies that account regardless of the exit address. Cookies and application identifiers also affect what a service can associate with the session.
Tor distributes routing across relays and has a different threat model from a single ordinary proxy. Adding a VPN to Tor can change that model and introduce another operator; it is not an automatic privacy upgrade. Follow the Tor Project's guidance rather than improvising a chain from marketing claims.
Evaluate reliability alongside privacy
Check authentication, software updates, tunnel-drop behavior, permitted routes, and whether DNS or IPv6 follows your chosen policy. For remote work, ensure internal resources resolve and route correctly. For household troubleshooting, repeat a failing transfer with and without the tunnel to identify added latency or MTU issues.
Choose a supported configuration for the actual requirement: access to a private network, transport protection on an untrusted access network, application proxying, or Tor browsing. A public-IP check is one useful observation in that assessment; it is not a full security audit.
Put it into practice
References & further reading
Protocol standards and official documentation supporting this guide. Device menus and provider policies vary; use the documentation for your equipment when applying a change.