Most people know Tor as “the anonymity browser.” Fewer know how it actually works — the three-hop onion routing that makes Tor different from a VPN, and that defines both its strengths and its limits.

This post walks through Tor’s internals, what each hop does, what the network protects against, and the practical implications for anyone building applications that interact with Tor traffic (whether to support it, allow it, or block it).

The Core Idea

A regular HTTP request looks like:

You → Server
(server sees your IP and your request)

A VPN inserts one hop:

You → VPN → Server
(server sees VPN IP; VPN sees your IP and request)

Tor inserts three:

You → Guard → Middle → Exit → Server

The trick is that each hop only knows the hop on either side of it — never the full picture. The guard knows you but not what you’re requesting; the exit knows the request but not who you are; the middle relay knows neither.

This is the fundamental anonymity property: no single point sees both you and the destination.

How the Layers Work

The “onion” part comes from how the data is encrypted. Before sending, your Tor client wraps your request in three layers of encryption:

Outermost layer encrypted with the guard’s key.
Middle layer encrypted with the middle relay’s key.
Innermost layer encrypted with the exit’s key.

When you send the packet:

The guard decrypts the outer layer. It now sees the middle relay’s address and an encrypted blob. It forwards to the middle.
The middle relay decrypts its layer. It sees the exit’s address and an encrypted blob. It forwards to the exit.
The exit decrypts the final layer. It sees the destination (e.g., example.com) and the actual request. It makes the connection and forwards the response back through the chain.

Each layer is peeled like an onion. Hence “onion routing.”

What Each Hop Does and Doesn’t See

Hop	Knows your IP?	Knows destination?	Sees request content?
Guard	Yes	No	No
Middle	No	No	No
Exit	No	Yes	Yes (if unencrypted)

The middle relay is the privacy buffer. Without it, the guard and exit could collude. With it, you’d need three relays to all be compromised by the same adversary — vastly less likely.

Circuit Lifetime

Tor doesn’t use a new path for every request. A circuit is established and reused for ~10 minutes before being rotated:

Guards rotate slowly (~2-3 months) to reduce the “first contact” exposure to new Tor entry points.
Middle and exit relays rotate every ~10 minutes so a single exit doesn’t see all your activity.

Different applications (different browser tabs, different identities) can be assigned to different circuits via Tor’s stream isolation features.

Tor vs VPN: The Real Difference

People often ask whether Tor is “just a VPN with extra steps.” It’s not. The differences:

Feature	VPN	Tor
Hops	1	3
Provider sees your traffic?	Yes	Only the exit, only if unencrypted
Single-point trust	Yes (trust the VPN)	No (no single point sees both ends)
Speed	Fast	Slow (3 hops, often weak ones)
Use case	Privacy from your ISP, geo-shifting	Anonymity from active adversaries

A VPN protects you from your ISP and the local network. Tor protects you from a more sophisticated adversary that might also be monitoring the VPN provider.

See proxy types explained for how Tor fits into the broader proxy landscape.

What Tor Doesn’t Protect Against

A common misunderstanding: Tor isn’t a magic anonymity shield. It protects specific things and leaves others exposed.

Application-level identity

If you log into Gmail over Tor, Google still knows it’s you (the credentials are tied to your account). Tor hides your network identity, not your application identity.

Browser fingerprinting

The Tor Browser is specifically engineered to resist fingerprinting (everyone gets the same User-Agent, the same screen size, etc.), but custom Tor clients or non-Tor-Browser usage still leaks the usual fingerprint signals.

Traffic analysis

A sufficiently powerful adversary (state-level, monitoring most of the internet) can correlate the timing of packets entering Tor with the timing of packets leaving Tor. This is called “global passive adversary” risk. Tor explicitly does not protect against this.

Exit node snooping

The exit node sees your unencrypted traffic (HTTPS protects content; HTTP doesn’t). If you log in over HTTP through Tor, the exit can see your password. Always use HTTPS over Tor.

DNS leaks

If your Tor client is misconfigured, DNS queries might bypass Tor and go directly to your ISP’s resolver — revealing what you’re browsing. Tor Browser handles this; ad-hoc Tor proxy setups often don’t.

Hidden Services (Onion Services)

Tor isn’t just for accessing the regular internet anonymously. It also supports onion services — sites that exist only inside the Tor network with .onion addresses.

An onion service:

Has no IP address visible to the wider internet.
Is reached via a rendezvous point inside Tor — both the user and the service connect outward to a meeting point.
Provides end-to-end encryption between the user and the service without trusting CAs.

The big names of the surface web (Facebook, BBC, DuckDuckGo, ProtonMail) all run onion service mirrors. They give users in censored regions a way to access the service without their connection being identifiable as “going to Facebook.”

For most application developers, you’ll never operate an onion service. But knowing they exist helps you understand why a *.onion URL doesn’t resolve via DNS.

Tor Exit Nodes and Geolocation

For the rest of us — people receiving Tor traffic on a regular server — the relevant fact is this: the client appears to come from the exit node’s IP.

If the exit node is in Germany, your geolocation API will show “Germany” for the user, even if the actual user is in Brazil. The geolocation is correct (the IP is German) but the user is somewhere else.

To detect Tor traffic, you have a few options:

Use the official Tor exit list (https://check.torproject.org/exit-addresses) and compare incoming IPs.
Use an IP intelligence API that classifies IPs and flags Tor exits explicitly. The Ip2Geo API returns ASN data inline; some Tor exits are on well-known hosting ASNs you can detect.
Watch for Cloudflare’s T1 country code — Cloudflare’s special code for Tor exits (their convention, not ISO).

Whether to block Tor depends on your use case. For fraud detection, Tor users have an elevated fraud signal — but for legitimate users in censored regions, blocking Tor blocks them from accessing your service at all. See blocking VPN and proxy users for the nuances.

Performance Reality

Tor is slow. The reasons:

Three hops means three RTTs added to every request.
Relays are volunteer-operated and vary wildly in bandwidth — your circuit is only as fast as its slowest hop.
Congestion control inside Tor is less mature than TCP at scale.
The network is contended — millions of users share thousands of relays.

Expect ~10x latency compared to direct browsing in 2026. For text browsing this is fine; for streaming video, painful.

Who Runs Tor Relays

The Tor network is volunteer-operated: about 7,000-9,000 active relays at any given moment, run by individuals, academic institutions, civil society organizations, and a small number of for-profit companies. There’s no central Tor company you can buy bandwidth from.

Guards and middles are easy to run (no legal exposure — you’re just forwarding encrypted data). Exits are harder — exit operators receive copyright complaints, abuse reports, and occasionally law enforcement attention. Most exit nodes are run by organizations specifically equipped to handle these (EFF-affiliated groups, universities with legal departments).

Is Tor Used for Crime?

Yes. So is the regular internet. The Tor Project publishes its own data:

A small fraction of Tor traffic goes to onion services (where most of the public discussion of “dark web markets” happens).
The majority of Tor usage is to access the regular web for privacy reasons — journalists, activists in censored regions, people who don’t want their ISP to know what they’re browsing, abuse survivors, normal people who prefer anonymity.

For application developers, the practical takeaway is: a meaningful fraction of your Tor traffic is legitimate. Defaulting to “block all Tor” loses real users.

Building Tor-Friendly Services

If you want to support Tor users:

Don’t block Tor exit IPs blanket-style. Use rate limiting and behavior signals instead.
Don’t require unnecessary identification. Real-name policies push Tor users away.
Offer an .onion service if your service might be censored anywhere.
Avoid CAPTCHAs that disproportionately target Tor traffic. Cloudflare’s “checking your browser” challenge famously frustrates Tor users — Cloudflare has been improving this but the friction is still there.

The BBC, Facebook, ProtonMail, DuckDuckGo, and many others run onion services for exactly this reason.

TL;DR

Tor routes through three relays so no single point sees both the user and the destination.
Each hop only knows its neighbors. Onion encryption layers ensure this.
The exit node sees your traffic (unencrypted) and your destination — use HTTPS.
Tor is not a VPN. It has stronger anonymity properties but is much slower.
For receiving Tor traffic, the user’s geolocation will be the exit node’s location.
Some Tor traffic is malicious; most isn’t. Detect and rate-limit rather than blanket-block.
Onion services are sites that exist only inside Tor — no public IP, end-to-end encrypted.

For most application code that doesn’t specifically care about Tor, the practical advice is: detect VPN/proxy/Tor traffic, add it to your fraud signal, and decide per-feature whether to allow or restrict. The Ip2Geo API returns ASN and network classification inline so you can make these decisions in real time.

How Tor Actually Works: The 3-Hop Onion Routing Explained