Tor Exit Node IP Risk: How Websites Should Interpret It

Tor carries a connection through a chain of volunteer-run relays. The last relay in the chain, the exit relay, opens the connection to the destination, so the website sees the exit relay's address and nothing about the connection before it. Many unrelated users share each exit at any moment, and a single user's traffic moves between exits as circuits change, so the address a site records is the exit's identity, not the visitor's.

The Tor Project publishes the exit relays itself. The bulk exit list at check.torproject.org is a plain list of exit addresses, and the companion exit-addresses file records each ExitNode fingerprint with Published and LastStatus timestamps and the ExitAddress it was seen using. Because exits come and go, both files are snapshots: an address that was an exit last month may be an ordinary server today.

Two further services make the check more precise. TorDNSEL is a DNS-based list of exit nodes that takes exit policies into account: since a relay can allow exits to some destination ports and not others, the list of exits relevant to your service depends on your service's own address and port, and TorDNSEL answers that specific question. ExoneraTor answers the historical one: given an address and a date, it reports whether that address was used as a Tor relay at the time, which matters when an abuse report arrives weeks after the event.

Commercial reputation feeds and the VPN and proxy checker on this site fold these lists into a Tor flag. When you see that flag, it means the address appeared on an exit list at the time of the check, and no more than that.

The flag exists because exits concentrate abuse. Automated signups, scraping, spam and attempts to evade an earlier block all route through Tor, and every one of them is attributed to the exit. Exit operators know this: the Tor Project's exit guidelines ask operators to set reverse DNS to something that signals the relay's use, such as a name containing anonymous-relay or tor-proxy, and to serve an explanatory notice on port 80 of the exit address. A reverse DNS lookup on a flagged address will often show exactly such a name.

That transparency also shows what the flag is not. The exit's operator is typically a university, a nonprofit or an individual volunteer, and the relay's address, hosting provider and autonomous system describe the operator, not the person behind the circuit. An IP lookup on an exit address returns the exit's location and network, which say nothing about where the user is.

A Tor flag says nothing about the individual, whose location, intent and history the exit relay itself cannot know, and less about the address than it seems to. The Tor Project's own abuse FAQ points out that relays have individual exit policies, that many relays do not allow exit connections at all, and that an operator deciding to ban Tor should parse those policies and block only the exits that can actually reach the service. A list that was downloaded once and never refreshed will block addresses that stopped being exits and miss the ones that started.

The right response depends on what the request is trying to do, not on the flag alone. Reading public pages costs you nothing and is where Tor users most need access, so allow read-only traffic by default; account creation, login, posting, payment and administrative actions are where shared, anonymous addresses carry real risk, so require more there: a CAPTCHA, email or phone verification, a second factor, or a lower rate limit for the exit's address range. The Tor Project asks operators to apply the same reasoning, comparing exits to other services that aggregate many users behind a few addresses, and the incident-response triage checklist covers how to document the decision so it can be reviewed later.

If a specific surface, such as a payout form, genuinely cannot accept anonymous traffic, build the rule from a live source: query TorDNSEL or refresh the bulk exit list on a schedule, scope the rule to that surface, give each entry an expiry, and review the matches, because a sudden rise in blocked requests usually means the list changed rather than that an attack started. Match exits, not neighbourhoods: blocking the exit's whole network range or autonomous system punishes every other customer of its hosting provider for one relay, and the firewall blocking guide covers scope, expiry and review in more detail.