SSD Nodes Learn 🎉 VPS from $4.99/mo
Guides Matt ConnorBy Matt Connor · Updated 2026-08-12

Tor vs a VPN: which do you need?

Tor and a VPN answer different questions. See exactly who learns what at every hop, and why a VPS rented in your name is not an anonymity tool.

Tor vs a VPN: which one you actually need

Tor and a VPN both send your traffic through machines that are not yours, and they answer different questions. A VPN (virtual private network) moves your trust from your internet provider to one company, which then sees your real address and every destination you visit. Tor spreads that trust across three relays run by different people, so no single relay knows both who you are and where you are going. Pick by naming the party you are hiding from.

If that party is the network you are sitting on, a VPN is the right tool. If that party is the website itself, or anyone who can compel the records of one company, Tor is the right tool. The rest of this guide is the detail behind those two sentences.

Follow one request through both designs

Take one ordinary request: your browser opens https://news.example.com. TLS (transport layer security) protects the page content either way, so nobody in the middle reads the article. The interesting part is the metadata: who learns your IP address, who learns the destination, and who can join those two facts together. A privacy tool is a machine for pulling that pair apart. A VPN moves the pair to a different holder. Tor splits it.

What each party sees when you use a VPN

Your client encrypts every packet and sends it to one endpoint. From that endpoint onward it is ordinary traffic again.

  • Your ISP (internet service provider) sees encrypted packets between your line and one VPN server address. It sees volume and timing. It does not see the destination hostname, as long as DNS (domain name system) queries also go through the tunnel.
  • The VPN operator sees your real IP address on one side and every destination address on the other, with times and sizes. Both halves of the pair land on the same machine.
  • The destination sees the VPN's exit address, plus every identifying detail your browser sends.

A VPN therefore does not create anonymity. It relocates the observer, from your ISP to your VPN provider. That is a real gain when the local network is the problem, or when your ISP filters or resells what it sees. It is no gain at all against the site you are visiting, because your traffic still arrives as one stream from one company that knows exactly who you are and holds your payment record.

The "no logs" claim is the entire product, and it is the one part you cannot check from your side. You can verify the tunnel is up. You can verify DNS is not leaking. You cannot verify what the operator writes to disk. That is the trade you accept: one company, chosen by you, holding the complete picture.

Check the leak that quietly undoes the tunnel:

resolvectl status
curl -s https://ifconfig.me; echo

The address printed by ifconfig.me should be the VPN exit. The DNS servers listed for the link carrying your default route should be the tunnel's resolver. If they still list your local router at 192.168.1.1, your name lookups are leaving over the local link in cleartext, because the route to that router is on-link and more specific than the tunnel's default route. Your traffic is private and your list of sites is not. DNS queries escaping a WireGuard tunnel walks through the fix.

What each party sees when you use Tor

Tor builds a circuit of three relays chosen from a signed list, the consensus, published by a small set of directory authorities. Your client wraps the data in layers, one per relay. Each relay removes one layer, learns only the next hop, and passes the rest along. Those layers are why nobody in the path holds both facts.

  • Your ISP sees encrypted traffic to one guard relay. Relay addresses are public, so your ISP can tell that you use Tor. It cannot tell what you reach.
  • The guard relay sees your real IP address. It cannot see the destination, because the part of the message naming the site is still encrypted for the relays after it.
  • The middle relay sees a guard on one side and an exit on the other. It sees neither you nor the destination. It exists so the guard and the exit never speak directly.
  • The exit relay sees the destination and the traffic as it leaves the network. It sees the middle relay's address, not yours. With HTTPS it learns the hostname and the connection metadata, not the page.
  • The destination sees the exit relay's address, which appears on public exit lists, plus whatever your browser hands over.

Linking you to the site takes the guard and the exit at the same time. That is the design in one sentence. It is also why your client keeps the same guard for months rather than picking a fresh one on every start: rotating the entry constantly would give a hostile relay repeated chances to become your guard.

Circuits are not permanent. New connections move to a fresh circuit roughly every ten minutes, while a stream that is already open stays on the circuit it started on. A long download and a tab you open fifteen minutes later usually leave from different exits.

How the three hops get built without any relay learning the others

The client does not hand the list of relays to the guard. It negotiates keys with the guard first, then sends a request through the guard asking it to extend the circuit to the middle relay, then sends a further request through that hop to extend to the exit. Each relay is told only about the neighbour it must talk to next, and each hop has its own key that the other hops never see. This is why the middle relay cannot learn the exit's role by inspection, and why a relay that logs everything it handles still logs one fragment.

Install it and prove the path:

sudo apt update && sudo apt install -y tor
systemctl status tor@default
journalctl -u tor@default -n 20
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip

The log should reach Bootstrapped 100% (done): Done. The curl should print {"IsTor":true,"IP":"..."} with an address you do not recognise, which is your current exit. If IsTor is false, the request never went through the proxy. Ubuntu's packaged Tor can lag behind the current release; the Tor Project publishes its own apt repository if you need to track upstream.

One trap sits inside that command. --socks5 makes curl resolve the hostname itself and then send the resulting address through the proxy, so your normal resolver learns every name you visit. --socks5-hostname sends the name to Tor and lets the exit resolve it. Same tunnel, completely different leak. Tor Browser and torsocks get this right. Hand-configured tools often do not.

Tor carries TCP streams only. It cannot carry UDP, so ping 1.1.1.1 never travels through it, and a UDP based VPN protocol cannot run inside it. Any program that ignores its proxy setting simply uses your normal route with your normal address, and nothing warns you. That is why system-wide Tor is done with a transparent proxy on a separate box rather than an environment variable.

Where the trust actually goes

A VPN concentrates trust. One company holds your identity, your billing record and your full traffic pattern, and your protection is its promise not to keep the logs. While that promise holds, the design is clean, fast and easy to reason about. When it fails, through a subpoena, a breach or a lie, it fails completely and for all of your traffic at once.

Tor distributes trust. Three parties who mostly do not know each other each hold a fragment, and a fragment alone is worth little. Nobody has to be honest for the design to work. Enough of them have to be independent. You pay for that with speed, with TCP only, and with a network where some relays are certainly run by people who would like to watch you. Tor's answer to a hostile relay is that one relay is never enough.

When a VPN is the right tool

  • You do not trust the local network: hotel, airport, conference hall, a landlord's router. The operator sees an encrypted tunnel and nothing more.
  • You want to reach your own machines, or leave from a fixed address that you control.
  • You need speed and UDP: video calls, games, large transfers, backups.
  • You want a stable address that sites do not challenge. Tor exits are blocked or CAPTCHA'd across much of the web.

That list is the case for running your own VPN on a VPS rather than buying a subscription, and a WireGuard server you set up yourself gives you a tunnel whose logging policy is a config file you own. If you want the same tunnel with device-to-device key management on top, the difference between plain WireGuard and Tailscale is the comparison to read. Each of these is excellent at the job in this list. None of them does the job in the next one.

When Tor is the right tool

  • Your adversary includes the destination site, or anyone able to demand records from a single company.
  • You are reading or publishing something that would harm you if it were traced back to your line.
  • You want an onion service: traffic that never leaves the network, no exit relay involved, and a server whose address stays hidden.
  • You can live with slow pages, CAPTCHAs and the occasional 403 Forbidden.

Use Tor Browser, not your daily browser pointed at port 9050. The browser is half of the protection, and the section after next explains why.

Why a VPS you rented is worse than a commercial VPN for anonymity

This is the case people get backwards. A VPS you rented is a lease with your name on it. The signup email, the card, the invoices and the support tickets all sit in one company's database next to that IP address. Nobody has to break anything to connect the address to you. It is already written down, kept for ordinary accounting reasons, and available to anyone who can ask the provider a question with legal weight behind it.

The second problem is the crowd. A commercial VPN's exit address is shared by many customers at the same moment, so that address alone does not point at one person. Your VPS address is yours alone. Every request leaving it is you, today and next month, and the address does not rotate, so a destination can build a profile across months with no cookies at all.

None of that makes a self-hosted VPN a bad thing. It is very good at encrypting your traffic on a network you do not control, and at reaching your own services from anywhere. It is simply not an anonymity tool, and using it as one is the mistake. For a plain account of what your provider can and cannot see on the machine itself, read how safe VPS hosting really is.

What neither Tor nor a VPN fixes

  • Browser fingerprinting. Your user agent, screen size, timezone, installed fonts, language and canvas rendering combine into a value that is often unique, and it follows you across every IP address you use. Tor Browser fights this by making its users look identical to each other and by resizing the window in fixed steps. Your normal browser behind a SOCKS proxy keeps its fingerprint and its cookies.
  • Logging in. The moment you sign in to an account that knows your name, the network layer stops mattering. One login from home and one over Tor to the same account ties both sessions together.
  • Anything the endpoint records anyway: what you typed, what you bought, what you searched for.
  • End-to-end correlation. Someone who watches your line and the exit at once can line up timing and packet volume and match the two ends. Tor states plainly that it does not defend against an adversary that can see both sides.

Can you use Tor and a VPN together?

Tor over VPN means the VPN connects first and Tor runs inside it. Your ISP then sees only the VPN, and the guard relay sees the VPN's address instead of yours. You have also put a company that holds your name and card in front of a system designed to avoid exactly that. It is worth doing in one situation: when using Tor at all is dangerous on your line and you have no better option.

VPN over Tor, where traffic leaves the Tor network and then enters a VPN account, is harder to set up and usually worse. That account has your payment record attached, so you have pinned a stable identity to traffic that was anonymous a moment earlier.

If the goal is only to hide Tor use from your ISP, the supported answer is a bridge: an entry point that is not in the public consensus, combined with a pluggable transport such as obfs4 or Snowflake that makes the traffic hard to classify. Tor Browser ships with both, and no third company needs your name.

FAQ

Is Tor just a free VPN?

No. A VPN sends your traffic through one server run by one company that sees your real address and every destination, so it swaps your ISP for a provider you chose. Tor sends it through three relays run by different people, where the guard sees you but not the site and the exit sees the site but not you. Tor is also TCP only, noticeably slower, and blocked or challenged by many websites, so it is not a drop-in replacement for a VPN's everyday uses.

Can my ISP tell that I am using Tor?

By default, yes. Relay addresses are published in the public consensus, so your provider can see you connecting to a known guard relay. It cannot see which sites you reach. To hide the use itself, Tor Browser offers bridges with a pluggable transport such as obfs4 or Snowflake, which connect through an entry point that is not on the public list. A VPN in front of Tor also hides it from your ISP, and hands that same fact to the VPN operator instead.

Does running a VPN on my own VPS make me anonymous?

No. The server is rented in your name with your card, so the provider's billing records already link that address to you, and a request to the provider is all it takes to read them. The address is also used by you alone, so everything leaving it belongs to one person and stays linkable for as long as you keep the server. A self-hosted VPN is a strong privacy tool against the local network and a weak anonymity tool against anyone who can question your provider.

Why do websites block me or show CAPTCHAs when I use Tor?

Because exit relay addresses are public and shared by very many people, so abuse coming from any one of those users attaches to the address you are borrowing. Content delivery networks score those addresses badly and answer with a challenge, a 403 Forbidden, or a signup form that refuses to submit. Nothing on your side removes this. A new circuit gives you a different exit, which sometimes has a better reputation.

If I use a VPN, do I still leak my DNS queries?

You can, and it is common. With a full tunnel and no resolver set for the tunnel interface, your client keeps the resolver it learned from the local network, and the route to that resolver is on-link, so it beats the tunnel's default route. Your queries then leave in cleartext while everything else is encrypted. Run resolvectl status and confirm the DNS server listed for the link carrying your default route is the tunnel's resolver, not your local router.