Detecting Tor Exit Nodes

Tor is one of the few network conditions you can identify with near-certainty, because the network publishes a signed list of its own exit relays. That makes exit-node detection unusually reliable compared with proxy or VPN detection, which lean on reputation and inference. The harder question is not whether a request came through Tor — that part is close to a lookup — but what to do about it, since Tor carries a genuine mix of privacy-conscious real users and abuse hidden behind anonymity.

This piece covers the authoritative way to identify exit-node traffic, the browser-level signals that corroborate it, and a scoring approach that treats Tor as risk context rather than an automatic block.

Why Tor is detectable when other anonymizers are not

Every request leaving the Tor network exits through a relay listed in the public Tor consensus — a signed directory of active relays, updated roughly hourly by the directory authorities. Exit relays are flagged as such. That means the source-of-truth is not a guess: if the connecting IP is a current exit relay, the request is Tor traffic. The datacenter IP detection and proxy detection problems are genuinely probabilistic; Tor exit detection is closer to deterministic.

There are two practical ways to consume this:

• The exit list / bulk exit endpoint. The Tor Project publishes a list of exit IPs you can pull and match against. Simple, but you must refresh it frequently because relays churn.
• DNS-based exit lookups. A DNSEL-style query answers, for a given destination IP and port, whether a source IP is a known exit. Useful when you want a targeted check.

Either way the operating discipline is the same: keep the data fresh. A list refreshed hourly tracks the consensus; a list refreshed daily will both miss new relays and flag decommissioned ones.

Corroborating with browser and fingerprint signals

IP-level detection tells you the transport. Combining it with client signals tells you far more about intent and hardens you against edge cases. Tor Browser is a hardened Firefox fork engineered so that all users present a near-identical fingerprint — that uniformity is a signal in its own right.

Characteristic markers include:

• A letterboxed viewport quantized to round dimensions rather than a natural window size.
• JavaScript restricted or disabled at higher security levels, suppressing canvas and WebGL probes.
• A deliberately generic user-agent and font set shared across the user base.
• Timezone reported as UTC regardless of exit geography.

When a request arrives from a confirmed exit relay and the client also matches the Tor Browser profile, confidence is very high. When the IP is an exit relay but the client looks like an ordinary Chrome on a normal window, you are likely seeing a scripted tool routing through Tor rather than a privacy user — which is a different and often higher risk.

Score, do not reflexively block

Blocking all Tor traffic is easy and frequently wrong. Journalists, researchers, users under censorship, and privacy-conscious customers use Tor legitimately. The better model is to fold the Tor signal into a suspect score and let the sensitivity of the action decide the response.

tor_exit_confirmed        -> +30 risk, reason "tor_exit_node"
tor_browser_profile       -> +10 risk, reason "tor_browser"
exit_ip + non_tor_client  -> +25 risk, reason "tor_scripted_client"

Then gate by action, not by page view:

Action	Tor present, low other risk	Tor present, high other risk
Browse / read	Allow	Allow
Create account	Step-up email verification	Proof-of-work + verification
Login	MFA prompt	Deny, flag for review
Payment / withdrawal	Manual review	Deny

This lets a real user read your site or log in with MFA over Tor while stopping the withdrawal or the promo abuse attempt that hides behind it. Tor is a common egress for multi-accounting and bonus abuse precisely because it looks anonymous — but the device fingerprint still ties those accounts together even as the exit IP changes.

Keeping detection honest

A few failure modes are worth guarding against:

• Stale data cuts both ways. An out-of-date list flags former relays (false positives) and misses new ones (false negatives). Automate the refresh and monitor the list age.
• Exit relays are not proxies. Do not lump Tor into a generic anonymizer bucket. Its deterministic list makes it more reliable than VPN detection, and its user population is different. Give it its own reason code.
• Middle relays are not exits. Only exit relays connect to your server; do not treat guard or middle relays as client IPs.
• Pair with device identity. IP reputation alone resets every time the circuit rebuilds. A durable device fingerprint is what links repeated Tor sessions to the same actor. See the broader IP reputation context.

Frequently asked questions

Is detecting Tor the same as blocking it?

No. Detection tells you a request arrived through a Tor exit node so you can adjust risk. Blocking is one possible response, but scoring and step-up challenges usually serve legitimate Tor users better.

How current does the exit node list need to be?

The Tor consensus rotates roughly every hour and relays change often, so a list refreshed hourly is the practical minimum. Stale lists produce both misses and false positives.

Can Tor Browser itself be fingerprinted?

Tor Browser deliberately makes users look alike, which is itself a signal. A uniform, letterboxed, JavaScript-restricted profile combined with an exit-node IP is a strong combined indicator.

Tor is the rare anonymity layer you can identify with confidence, so the engineering effort belongs less in detection and more in response design. Consume the consensus fresh, corroborate with the Tor Browser profile, score the result, and let the value of the action set the friction. Handled this way, you stop the abuse that hides in Tor without punishing the people who rely on it. See the network signals reference or the bot detection overview to place this in context.