What Each Tor Relay Hop Can See
A visibility matrix for Tor's guard, middle and exit: who sees your IP, who sees the destination, who runs relays, and how bad nodes get removed.
Onion routing only helps if you are precise about who sees what. A three-hop circuit is not a black box. The guard sees you. The exit sees the destination (for clearnet traffic). The middle sees neither. That split is the whole design, and most confusion about Tor comes from treating every hop as equivalent. How cells are layered is explained in onion routing; this page is the visibility chart and the operational reality behind it.
Visibility matrix
| Observer | Sees your IP? | Sees destination? | Sees page content? |
|---|---|---|---|
| Your ISP | Yes (guard or bridge IP) | No | No |
| Entry guard / bridge | Yes | No | No |
| Middle relay | No | No | No |
| Exit relay | No | Yes (clearnet) | Yes, if the site is HTTP |
| Destination site | Guard/exit as source, not you | Yes — it is the destination | Yes |
| Onion service | No (six-hop rendezvous) | It is the destination | Yes |
Two footnotes matter. HTTPS on the exit means the exit sees the hostname (via SNI, unless encrypted Client Hello is in play) and the fact of a connection, not the request body. An onion service never uses an exit; both sides meet inside the network. Tor vs VPN is the usual comparison if you are trying to hide an IP from a single website — a VPN operator sees both ends; a Tor exit sees the destination and not you.
Who runs the relays
Relays are volunteer machines. Universities, nonprofits, privacy-minded ISPs and individuals all show up in the consensus. There is no Tor Project-owned backbone that carries user traffic. The Project publishes software, directory authorities sign the consensus, and the bandwidth comes from other people.
That is a strength and a liability. A university relay is often well provisioned and professionally run. A home operator on a residential connection may disappear, get a copyright complaint, or misconfigure logging. Exit operators take the most heat: the rest of the internet sees their IP as the source of whatever users do. Abuse mail, DMCA notices and occasional police visits are the reason so few people run exits compared with guards and middles.
Tor Project metrics for late October 2026 showed roughly 9,200 relays and about 2,400 bridges. Those counts move week to week. Capacity is not evenly spread: a small number of high-bandwidth relays carry a large share of traffic, which is why a single overloaded guard can make a whole session feel broken. If the circuit crawls, read why Tor is slow before blaming "the network" in the abstract.
Why the guard stays put
Tor does not pick a new entry on every circuit. The client holds a small set of persistent guards and uses one of them for weeks to months. The reason is statistical. If every circuit picked a fresh random entry, a well-resourced attacker who runs many relays would eventually be your entry on some circuits and your exit on others, and could confirm the pair. A stable guard means that risk is concentrated: either your guard is honest, or you have a long-term problem — not a new lottery every hour.
The guard still sees your real IP and the times you come online. That is enough for a malicious guard to build a usage profile. It is not enough, on its own, to read destinations. Combining a malicious guard with a malicious exit, or with other network vantage points, is a traffic-confirmation problem, not a simple "the hop is evil" story.
If the public guard list is blocked where you are, a bridge takes the guard's place. Same visibility: the bridge sees you, not the site.
Exit nodes and the legal heat
The exit is the only hop that talks to the ordinary internet. It decrypts the outermost layer and makes the TCP connection. Operators are asked to publish an exit policy (many refuse BitTorrent, many refuse mail) and to run a notice page so that complainants can see they have reached a transit node.
That does not stop the complaints. Law enforcement sometimes seizes an exit because its IP appeared in a log. Most of those cases collapse once the operator explains the architecture, but the cost in time and hardware is real. The Tor Project's relay documentation is explicit: do not run an exit from your home connection, and do not run one in a jurisdiction where you cannot afford a lawyer.
Users should assume the exit is hostile. Use HTTPS. Do not send passwords or session cookies over HTTP through Tor. Do not treat an exit IP as "your" anonymous identity — it is shared with thousands of other people and it changes.
How bad relays get found and removed
Directory authorities can vote a relay off the consensus. Reasons include: publishing a bad exit that tampers with traffic, running Sybil clusters that try to occupy both ends of circuits, lying about bandwidth, or getting caught in a confirmation attack. The 2014 "relay early" traffic-confirmation incident, which the Tor Project documented in a security advisory, is the textbook case of researchers (and, later, alleged law-enforcement use of similar methods) injecting relays to correlate users.
Detection is imperfect. A quiet, correctly configured malicious guard that only logs IPs and timestamps may never trip an automated alarm. That is one reason Tails or Whonix still matter: they constrain what a hostile first hop can combine with local leaks. It is also why the Project tells operators not to run more than a small fraction of network capacity from one entity.
What this means in practice
Treat the guard as someone who knows you use Tor and when. Treat the exit as someone who can see (or tamper with) any unencrypted clearnet session. Treat the middle as a buffer that exists so those two never meet. Do not run your own guard "for speed." Do not add extra hops in torrc — longer paths are slower and the anonymity gain is not what blog posts claim. Download the browser from the official site, install it cleanly, and leave circuit construction to the client.
Frequently Asked Questions
Can a middle relay identify me?
Not from the cells it forwards. It sees a previous hop and a next hop, both Tor relays. It does not see your IP or the destination. A middle that also runs a guard or an exit under the same operator is a different problem — that is a Sybil / correlation risk, which directory authorities try to limit.
Does the destination see a Tor IP?
For clearnet sites, yes: it sees the exit IP. For onion services, there is no exit and the service does not learn your IP from the circuit. The service can still fingerprint the browser or trick you into a clearnet callback.
Should I run a relay?
A middle or guard from a server you control, with no exit traffic, is how the network stays up. An exit is a legal and operational commitment, not a weekend experiment. Read the Tor Project's relay guide before you advertise a flag.
Is a VPN safer than a random exit?
A VPN operator sees your IP and your destination. An exit sees the destination and not your IP. They leak different things. Combining them is a separate decision, covered in the Tor over VPN note.