Why a Static Tor Exit Node IP List Goes Stale
A Tor exit node IP list is a list of the public addresses from which Tor traffic leaves the network and reaches ordinary websites, and a copy saved once starts decaying immediately. Exit relays are run by volunteers, they join, leave and change addresses constantly, so any list frozen in a file or hard-coded into a firewall rule drifts away from reality within hours.
Why the list changes so fast
The Tor network publishes a consensus roughly every hour that lists the relays currently running and which flags they hold, including the Exit flag. Relays are operated by individuals, universities, nonprofits and hosting customers, and many run on rented virtual servers that are cancelled, reprovisioned or moved between providers. When a relay stops, its address returns to a hosting pool and may be assigned to an entirely unrelated customer. When a new exit appears, it is unknown to your copy until you fetch again.
Exit policies add another wrinkle. A relay can be an exit for some ports and not others, and an operator can change the policy without changing the address. A list that records only addresses cannot represent that nuance, so it overstates what each IP does while simultaneously missing newcomers.
What goes wrong with a stale list
There are two failure modes, and both cost you. The first is false negatives: a recently started exit is not on your list, so traffic you meant to treat differently passes through unflagged. The second is false positives, which are usually the more damaging. An address that used to be an exit is now a normal hosting customer, a small business or a residential line, but your frozen list still labels it as Tor. Real users get challenged or blocked for something they are not doing, and nobody notices because the rule looks correct in the config.
Stale lists also tempt people into blocking whole ranges to compensate for gaps. That multiplies false positives, because the neighbors of a relay in a hosting range are often unrelated services. If you need broader context on why a Tor flag alone is a weak reason to deny access, see Tor exit nodes explained.
What a fresher approach looks like
The fix is not clever matching; it is a short refresh interval and a way to age out entries. Fetch the list on a schedule, replace it atomically instead of appending forever, and treat the age of the data as part of the answer. If your last successful refresh is older than your tolerance, fail towards a softer response such as a challenge rather than a hard block.
ipto does this as a service: the VPN, Tor and abuse threat feeds refresh every 6 hours, and IP and ASN datasets refresh daily. An IP lookup returns is_tor alongside is_vpn, is_abuser and is_datacenter, so you read current state per request and do not have to maintain a file. You can try an address in the VPN, Tor and proxy checker, or browse the published lists on the threat feeds page to see what the current data looks like.
Even six hours is not real time, and it is worth being honest about that. A relay that started an hour ago may not be in the data yet, and one that stopped may still be flagged until the next refresh. A negative result means "not known as Tor", not "certainly clean".
Using Tor data without over-relying on it
Because the list is always slightly wrong, build decisions that tolerate error. Combine the Tor flag with other evidence instead of acting on it alone. The IP abuse checker corroborates across several feeds, which helps separate a privacy-minded visitor from an address that is actually misbehaving, and the fraud score checker folds several signals into a single 0-100 value you can threshold.
- Cache lookups for less than the feed refresh interval, not for days.
- Prefer a challenge, rate limit or extra verification step over a permanent block.
- Log which signal triggered an action so you can review false positives later.
- Re-check addresses that you previously blocked; an old decision about an IP may no longer apply.
The core point is simple: the Tor network is a moving target, and the useful property of a Tor list is its freshness rather than its size. Treat any static snapshot as a historical record, and prefer data with a stated refresh cadence that you can reason about.