Tor Exit List: How Exit Nodes Route Traffic Through the Network

The Tor exit list contains the IP addresses and metadata of every relay operating as an exit node on the Tor network. Exit nodes are the last hop before traffic reaches its final destination—a website, mail server, or other service. Because exit traffic is decrypted at this point, exit nodes can theoretically observe unencrypted data passing through them. The Tor Project publishes exit list data to help administrators identify which IP addresses belong to Tor and to allow users and services to make informed decisions about traffic routing. Knowing which nodes are exits helps you understand potential vulnerabilities in your anonymity chain and why using HTTPS and end-to-end encryption remains important even over Tor.

Tor constructs a three-hop circuit by default: entry node, middle relay, and exit node. Your Tor client selects these relays randomly from the network directory. The entry node sees your real IP address but cannot read your traffic. The middle relay sees neither your IP nor your destination. The exit node sees the destination but not your identity. Each layer of the circuit uses a different encryption key, so only your client can decrypt the full path. Exit nodes are chosen based on their bandwidth, uptime, and exit policy—a set of rules each operator defines to specify which ports and destinations they will or will not serve. This architecture means exit nodes are critical infrastructure, but also potential chokepoints if compromised or monitored by adversaries.

Every Tor exit node publishes an exit policy that defines which traffic it will relay. A node might accept traffic to port 80 (HTTP) and 443 (HTTPS) but reject port 25 (SMTP) to avoid spam relay abuse. Some nodes reject all exit traffic and operate only as middle relays. Exit policies are published in the network directory and can be queried to understand which destinations are reachable through which exits. When you browse over Tor, your client automatically selects an exit node with a policy that permits your destination. If no suitable exit exists, your connection fails. Restrictive exit policies reduce the attack surface but also limit network capacity. Operators balance security, legal liability, and network utility when setting their policies. Understanding these policies helps explain why certain destinations may be unreachable from Tor or why connection attempts fail.

The Tor Project publishes exit list data through its CollecTor service and via the Onionoo API, which provides real-time information about relay status, bandwidth, and exit policies. Exit list data includes relay fingerprints, IP addresses, bandwidth metrics, and exit policies in machine-readable format. Security researchers, system administrators, and service operators use this data to identify Tor traffic, block specific relays, or analyze network topology. Individual users can query exit list APIs to see which exit node their current circuit is using or to understand which IP address a destination will see. Tools like the Tor Browser's circuit display show your current exit node's country and IP address. Interpreting this data requires understanding that exit IP addresses are not your identity—they are the identity of the relay, not you. Confusing exit IP with user identity is a common misunderstanding that leads to false attribution.

Onion addresses (.onion domains) route differently than clearnet destinations. When you connect to an onion service, your traffic never leaves the Tor network—no exit node is involved. Instead, your client builds a circuit to a rendezvous point, and the onion service builds its own circuit to the same rendezvous point. They meet there without either party knowing the other's IP address or location. This is why onion services offer stronger anonymity than Tor-to-clearnet routing. Exit nodes are irrelevant for onion traffic, which means exit node compromise or monitoring cannot affect your anonymity when using onion addresses. This architectural difference is why onion services are preferred for sensitive communication and why understanding the distinction between onion routing and exit-based routing is important for threat modeling.

A widespread misconception is that exit nodes can identify you. They cannot—they see only the destination and the traffic content if unencrypted. Your real IP address is never visible to exit nodes. However, exit nodes can perform man-in-the-middle attacks on unencrypted traffic, modify HTTP requests, or inject malicious content. This risk is mitigated by using HTTPS, which encrypts the connection between your client and the destination server, making the exit node unable to read or modify the content. Another misconception is that all exit nodes are malicious. Most are operated by volunteers following strict policies. However, some exit nodes have been observed performing traffic analysis or content injection, which is why using end-to-end encryption and verifying onion address authenticity through PGP signatures or official channels remains essential. Assuming the exit node is hostile and using HTTPS or onion services accordingly is sound OpSec practice.

When accessing onion services, verify the .onion address through multiple independent sources before trusting it. Phishing clones often use similar-looking addresses or are distributed through compromised exit nodes. Check official project documentation, PGP-signed announcements, or community discussions to confirm the correct address. For clearnet destinations over Tor, always use HTTPS to prevent exit node eavesdropping. Check SSL certificates carefully—a valid certificate proves the destination's identity, not the exit node's. If you suspect an exit node is performing attacks, you can configure your Tor client to exclude specific relays or countries from your exit selection. The Tor Browser allows circuit isolation per domain, reducing the risk that a single compromised exit affects multiple sessions. Understanding these verification techniques and using them consistently prevents common attacks that exploit exit node positioning.