What Is a Tor Proxy? Onion Routing Explained

A Tor proxy is the SOCKS5 interface that the Tor client process exposes on your own machine so ordinary software can route traffic through the Tor network. The tor daemon listens on port 9050 by default. Tor Browser bundles its own client and listens on 9150 instead, so both can run side by side without a port clash.

Point a program's proxy setting at socks5h://127.0.0.1:9050 and it works. Nothing else about the program changes. That interface is the whole reason people say "Tor proxy" when the accurate phrase is "the SOCKS port of a local Tor client attached to the Tor network."

The distinction matters. A normal proxy is one machine you have to trust. Tor is a system explicitly designed so no single machine has to be trusted. It grew out of onion routing research at the US Naval Research Laboratory in the mid-1990s, shipped as the Tor software in 2002, and has been maintained since 2006 by The Tor Project, a US nonprofit. Its purpose is anonymity and censorship resistance for people whose safety depends on it: journalists protecting sources, users behind national firewalls, researchers measuring censorship, whistleblowers submitting documents through SecureDrop. It is not, and was never meant to be, data collection infrastructure.

With a commercial proxy, your request goes to one server and that server makes the outbound request. One machine sees both your IP and your destination. If it keeps logs, or gets seized, the link between you and what you fetched is sitting right there in one place.

Tor splits that knowledge across three independent relays. Your Tor client downloads a signed network consensus, a directory listing every relay with its keys, addresses, measured bandwidth, and flags, regenerated by the directory authorities every hour. The client then picks three relays from it and builds an encrypted tunnel through them. The consensus normally lists several thousand relays. Only a fraction of those, typically one to two thousand, permit exit traffic. Live counts are published at metrics.torproject.org.

Because relay selection happens locally, against a directory the client verified using the authorities' signing keys, there is no central server assigning you a route and no operator who could hand over "the mapping." No such mapping exists in one place. That's the design goal, and it's the thing a single-hop proxy structurally cannot provide. Manually stacking proxies with proxy chaining imitates the topology but not the key handling that makes it work.

A circuit is built one hop at a time, and this incremental construction is what produces the layered encryption the "onion" name refers to.

1. The client opens a TLS connection to a guard (entry) relay and runs an ntor key exchange with it using a CREATE2 cell. Client and guard now share a key.
2. The client sends an EXTEND2 cell through that encrypted link, telling the guard to connect to a chosen middle relay. A second key exchange runs, this time with the middle relay, tunnelled through the guard. The guard forwards the handshake but never learns the resulting key.
3. The client repeats the trick once more to add the exit relay. Three hops, three separate keys, every one of them negotiated by the client.

Data then travels in fixed-size 514-byte cells wrapped in three layers of encryption. The guard peels the outermost layer, the middle relay peels the next, the exit peels the last and finds an ordinary TCP request to send onward. Each relay knows only who handed it a cell and who it passes the cell to.

Tor circuit: three hops, three encryption layers

[You] --TLS + 3 layers--> [Guard] --2 layers--> [Middle] --1 layer--> [Exit] --plain TCP--> [site]
  |                          |                     |                    |
  knows everything           your IP,              guard + exit,        destination,
                             not destination       neither end          not your IP

Guards are deliberately sticky. Your client keeps the same guard for months rather than picking a fresh entry relay per circuit, because a client that constantly reshuffles its entry point will eventually pick a hostile one and expose its real IP. The consensus parameter governing guard lifetime has been on the order of 120 days. Middle and exit relays, by contrast, change constantly.

This is the table worth memorising, because nearly every misconception about Tor comes from getting one cell of it wrong.

Two consequences follow. First, no single relay links you to what you fetched, which is exactly the property a one-hop proxy cannot offer. Second, an adversary able to watch both your connection to the guard and the exit's connection to the site can still correlate traffic timing and volume. Tor's own threat model says so plainly: it does not defend against a global passive adversary observing both ends. That candour is a feature of the project's documentation, not a gap in it.

If the exit-side terminology is new, our explainer on what an exit node is in a proxy network covers the general concept, which applies to any multi-hop system.

Tor's encryption is hop by hop, not end to end to the website. The exit relay strips the last onion layer and is then holding your actual request. If that request is plain HTTP, the exit sees the URL, the headers, the cookies, the POST body, the credentials. All of it.

Whoever runs the exit chose to run it, and anyone can run one. In 2007 the Swedish researcher Dan Egerstad operated five exit relays, passively captured unencrypted traffic passing through them, and published login credentials for roughly 100 embassy and government email accounts. Those users were not compromised by Tor. They were compromised by sending plaintext credentials across the internet, something Tor never claimed to fix.

The mitigation is the same one that protects you on hotel Wi-Fi. Use TLS. With HTTPS, the exit relay sees the destination hostname via SNI and the TCP endpoint, but the request path, headers, and body stay encrypted between your machine and the site's server. Tor Browser ships with HTTPS-Only mode enabled for exactly this reason.

Say it precisely: Tor anonymises who you are, not what you send. Confidentiality of the content is TLS's job, and Tor deliberately does not try to do TLS's job for you.

Tor does not keep one circuit forever. A few torrc options control the default rhythm.

A minimal config that shortens the rotation window:

# /etc/tor/torrc
SocksPort 9050
ControlPort 9051
CookieAuthentication 1
MaxCircuitDirtiness 60

Two things people consistently get wrong here. Lowering MaxCircuitDirtiness does not rotate an in-flight connection; a long download stays on the circuit it started on. And it does not guarantee a new exit IP, because relay selection is weighted by measured bandwidth and the set of high-capacity exits is small enough that you will draw the same ones repeatedly. Dropping the value to a few seconds mostly burns relay CPU on circuit construction, which is why the Tor Project advises against aggressive tuning.

The genuinely useful control is not the timer, it's stream isolation. IsolateSOCKSAuth is enabled by default on every SocksPort, meaning Tor treats each distinct SOCKS username and password pair as a separate identity and gives each one its own circuit.

That's a real feature, not a hack. Tor Browser uses the same mechanism to isolate circuits per first-party domain, so your session on one site cannot be trivially linked to your session on another through a shared exit.

# Two SOCKS identities, two circuits, two different exit IPs
curl --socks5-hostname alice:pw1@127.0.0.1:9050 https://check.torproject.org/api/ip
curl --socks5-hostname bob:pw2@127.0.0.1:9050   https://check.torproject.org/api/ip

The credentials are arbitrary. Tor never authenticates them, it only uses them as an isolation key. If the pattern looks familiar, it's because commercial rotating proxies borrowed the same interface: the username field carries session state. The difference is that Tor gives you isolation between circuits, not control over which country or which IP you land on.

Tor exposes an authenticated control protocol, by default on port 9051. Sending the NEWNYM signal tells the client to stop using existing dirty circuits for new streams and to clear cached state such as DNS results.

# pip install stem
from stem import Signal
from stem.control import Controller

with Controller.from_port(port=9051) as ctl:
    ctl.authenticate()          # cookie auth, per CookieAuthentication 1
    ctl.signal(Signal.NEWNYM)   # request a fresh identity

Or without a library, straight over the control protocol:

printf 'AUTHENTICATE ""\r\nSIGNAL NEWNYM\r\nQUIT\r\n' | nc 127.0.0.1 9051

Three limits trip people up, all of them documented rather than hidden:

• NEWNYM is rate limited. Tor enforces a minimum spacing between honoured signals, historically ten seconds in the source. Firing it in a tight loop achieves nothing after the first one.
• It does not tear down live connections. Streams already attached to a circuit keep running on it.
• It does not promise a different exit IP. New circuit, yes. A different exit relay, usually. A specific IP of your choosing, never.

Scripts that call NEWNYM between every request are treating an anonymity mechanism as a rotation API. Wrong abstraction, and the cost lands on volunteer-run relays.

An address ending in .onion is not a website sitting behind Tor. It's a service that exists only inside Tor, and reaching it involves no exit relay at all.

A v3 onion address is 56 base32 characters plus .onion, and those characters are a literal encoding of the service's ed25519 public key, a checksum, and a version byte. The name is the key, so the address authenticates the service by itself. No certificate authority participates. Version 2 addresses, the old 16-character ones, were removed from the software in the 0.4.6 series in 2021 and no longer resolve.

The connection is made through a rendezvous:

1. The service builds circuits to a few introduction points and publishes a signed descriptor to a distributed hash ring of directory relays.
2. The client fetches that descriptor, picks a rendezvous point, and builds a circuit to it.
3. The client passes the rendezvous details to the service via an introduction point.
4. The service builds its own circuit to the rendezvous point, and the two circuits are joined.

The result is roughly six hops, with each side anonymous to the other and traffic that never leaves the Tor network. Nobody sniffs an exit relay because there is not one. The connection is end-to-end encrypted and end-to-end authenticated by construction, which is why a number of mainstream sites publish onion mirrors and advertise them with the Onion-Location header.

The onion-service side also carries the network's newest defences. Tor 0.4.8, released in 2023, added a client puzzle mechanism so a service under a flood can demand proof of work before allocating resources, plus Conflux, which splits a stream across two circuits to raise throughput. For the wider architectural family this belongs to, see our write-up on P2P proxy networks.

The single most common configuration bug is resolving DNS locally. socks5 makes the client resolve the hostname itself and send an IP to the proxy. socks5h sends the hostname to the proxy and lets Tor resolve it. Use the h variant every time.

# pip install requests[socks]
import requests

proxies = {
    "http":  "socks5h://127.0.0.1:9050",
    "https": "socks5h://127.0.0.1:9050",
}

r = requests.get("https://check.torproject.org/api/ip", proxies=proxies, timeout=60)
print(r.json())   # {"IsTor": true, "IP": "<exit relay IP>"}

Get this wrong and two things break at once. Your normal resolver sees every hostname you visit, which leaks the browsing pattern Tor was supposed to hide, and .onion addresses fail outright with Name or service not known, because no public DNS server can resolve them.

# Correct: hostname resolved by Tor
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip

# Wrong: your OS resolver sees the hostname first
curl --socks5 127.0.0.1:9050 https://check.torproject.org/api/ip

Tor also offers DNSPort for a local DNS listener and TransPort for transparent redirection of a whole system's TCP through iptables or pf. Arti, the Rust reimplementation of the Tor client, reached 1.0 in September 2022 and exposes the same SOCKS interface, so client code does not change.

Tor works for scraping in the narrow sense that requests come back. It's still the wrong choice, for four reasons that have nothing to do with Tor being bad at its job.

The exit set is published on purpose. The Tor Project distributes an authoritative list of exit IPs at check.torproject.org/torbulkexitlist, and the full relay consensus is public by design, because transparency is a security property of the network. Every CDN, WAF, and anti-bot vendor subscribes to that list. Blocking Tor is a cron job that downloads a text file. No amount of header tuning or IP reputation work rehabilitates an address that appears on a published roster of exit relays.

The pool is tiny and shared. One to two thousand exit IPs serve millions of daily users. Any given exit carries traffic from thousands of unrelated people at once, so its rate-limit standing on a large site is already spent before your first request arrives. That is the opposite of what a scraping pool needs.

Latency is structural. Three encrypted hops, chosen without regard to geography, mean a request may cross oceans twice to reach a server two cities away. Round trips in the hundreds of milliseconds to over a second are normal, and throughput is capped by whichever relay in the circuit is slowest. The Tor Project publishes ongoing performance measurements at metrics.torproject.org. None of this is a defect. It's the price of the anonymity guarantee, paid by everyone on the network.

Bandwidth is donated, and exit operators absorb the consequences. Relays are run by volunteers and small nonprofits on their own money. Exit operators in particular field abuse complaints, law-enforcement inquiries, and hosting cancellations for traffic they never saw. Pushing bulk commercial crawling through that pipeline consumes capacity funded for people who have no alternative, and it speeds up the blocklisting of the very exits those people rely on. A price-monitoring job has other options. A journalist in a censored country does not.

Here is the comparison that actually settles the decision:

For data collection, a datacenter proxy pool gives you what Tor deliberately withholds: predictable latency, geo selection, real concurrency, and IPs that are not on a public roster. If you would rather not run a proxy layer at all, SparkProxy's Scraping API handles routing, rendering, and retries behind one endpoint:

curl -H "X-API-Key: YOUR_API_KEY" \
  "https://scrape.sparkproxy.io/api/v1?url=https://example.com&render_js=true"

import requests

r = requests.post(
    "https://scrape.sparkproxy.io/api/v1",
    headers={"X-API-Key": "YOUR_API_KEY", "Content-Type": "application/json"},
    json={
        "url": "https://example.com",
        "render_js": True,
        "format": "json",
        "stealth": True,
    },
    timeout=120,
)
print(r.status_code, r.json())

Full parameter reference lives at https://www.sparkproxy.io/docs/scraping-api/.

Use Tor for what it was built for. Use paid infrastructure for commercial work. Those two statements are not in tension, and treating them as if they were is how an important public network ends up degraded for the people who need it. If you are weighing privacy tooling more broadly, our proxy vs VPN comparison covers where each layer sits.