The Tor exit list is one of the few network facts that is exact rather than inferred: the Tor Project publishes which relays allow traffic to leave the network, and a request from one of them arrived through Tor. It is also a list that changes through the day, and most of the blocking built on it treats it as if it did not. This guide is about that gap and what Spaw does with it.
What the list is
A Tor circuit ends at an exit relay, the machine that makes the request to the destination on the user's behalf. Which relays are exits depends on each operator's exit policy, and the set changes as relays come online, go offline, change policy or are reconfigured. The Tor Project publishes two views of it. The bulk exit list at https://check.torproject.org/torbulkexitlist is the plain list of exit addresses, regenerated many times an hour. Onionoo, the project's relay-details API at https://onionoo.torproject.org/, describes every relay with its addresses, its flags and, usefully, the time it was last seen — and it covers IPv6, which the bulk list does not.
How rotation breaks a static copy
A blocklist is only as current as its last download, and Tor exits rotate faster than most download schedules. Two failures follow, in opposite directions.
The first is the miss. A relay that became an exit this morning is not in a file copied last week, so the traffic it carries is not recognised as Tor at all. The list is right; the copy is stale.
The second is the false positive, and it is the one that hurts real people. A relay stops being an exit — its operator changes the policy, the machine is decommissioned, a volunteer's home connection is reassigned — and the address goes back to ordinary use. A copy that still lists it keeps blocking whoever holds it next: a broadband customer whose ISP handed them the address a week after the relay left. Weeks-old copies are common, and every one of them is blocking addresses that are no longer exits.
There is a subtler version too. An address that left the list yesterday is very likely still the same machine, run by the same operator, and treating it as clean the moment it drops off is as wrong as treating it as an exit forever. The truth is in between, and a single boolean cannot say it.
What Spaw does
Three things, each aimed at one of those failures.
The list is synced hourly. Both Tor feeds — the bulk exit list and the Onionoo relay data — are small files, and the service re-downloads and recompiles them every hour, alongside the daily run that refreshes everything else. is_tor answers from the current copy, so a miss is at most an hour old, and a false answer is a checked negative: "not on the list as of this hour".
A thirty-day history is kept. After every Tor sync the service rebuilds an exit history from both lists (today's count and sync date are on the exit list's source page): every address either list has named in the last thirty days, with the date it was last seen exiting — Onionoo's own last-seen time where it gives one, the sync date otherwise. The history is compiled into a feed of its own and consulted for every public address. On one sync on 12 September 2026 it held 2,257 exits.
Recency is a signal with its own weight. tor_last_seen answers the date: the current list's date while the address is on it, else the history's date, else null. And recently_tor is a separate risk signal, at +40, for an address the history saw exiting within the last seven days that is not on the current list. A live exit scores +70; a machine that was an exit this week scores 40; one that left the list three weeks ago scores nothing and still carries its date, so the reader can see it. The two signals never stack: while an address is on the current list, recently_tor is false, because the +70 already counts it.
Seven days and forty points are choices, and they are published so they can be recomputed or ignored. A week is about how long an exit's address plausibly stays with the same machine; forty is the weight of a strong hint rather than a fact.
What to do with it
- Block nothing on
is_toralone. Tor is used by people who need it. The VPN and relay policy guide argues for a step-up — a confirmed email, a second factor — rather than a refusal, and the same applies here. - Read the date.
tor_last_seentwo days ago on an address that is not an exit now is the same machine; two months ago is an address that has moved on. Branch on the date rather than on the flag when the flag is false. - Watch your own addresses. A monitored list re-checks the addresses you care about on a cadence and alerts you the day one becomes an exit — the case where a volunteer's relay on your network gets your mail server blocked elsewhere.
- Never keep your own copy. If the list you block on is downloaded weekly, it is wrong in both directions by Wednesday. Ask per request, or if you must cache, cache the answer with its date and expire it within the hour.
Sources
- The Tor Project's bulk exit list: https://check.torproject.org/torbulkexitlist
- Onionoo, the Tor relay details API: https://onionoo.torproject.org/
- The history size above is one sync on 12 September 2026 on one deployment; the current figures for every feed, with their dates, are on the status page.
The IP intelligence guide documents is_tor, tor_last_seen and the weights in full.