How to detect Tor traffic without blocking real users

By the Tor Project's own count, roughly two million people connect to Tor every day. The overwhelming majority are not committing fraud. That single fact is what makes Tor detection less of a technical problem and more of a judgment one. Spotting that a request came through Tor is genuinely easy, because the list of Tor exit nodes is public and the Tor Project publishes it. The hard part is what you do next, when the same exit node carries a privacy-conscious shopper, a journalist, and the one account farmer you actually care about.

Key takeaways

• Detecting Tor at the web layer is mostly a lookup: the Tor Project publishes its exit-node addresses, so checking an IP against that list catches the bulk of Tor traffic.
• Tor is a privacy tool, not a fraud signal on its own. Journalists, activists, and ordinary privacy-minded users rely on it, so blocking all Tor traffic is a blunt instrument that costs you real visitors.
• The harder problem is that one actor rotates circuits, so an IP-only view sees many separate visitors. Reading the device underneath links those sessions back to one person.
• Treat Tor as one anonymity signal among several, weighed into a risk score, not as an automatic verdict.

Why detecting Tor is the easy part

Detecting Tor traffic is straightforward because Tor is designed to be a public network, not a covert one. Every relay, including the exit nodes that actually connect to your server, is listed in a directory the Tor Project maintains and publishes openly. When a request reaches your application, the IP address you see is the exit node's, and you can check that address against the published exit list in a single lookup.

A Tor network check is exactly that: a lookup of the request IP against the current exit-node list, which is also what public exit-node checkers do. That is why a security forum will tell you, plainly, that Tor traffic can be readily identified because all the Tor nodes are public information anyway.

So the "can I tell this is Tor?" question is mostly solved before you start. The interesting questions are the ones that come after: is this Tor session worth worrying about, and how do I tell the abuser apart from the two million people using Tor for ordinary reasons?

Tor tends to show up behind the abuse you already track, multi-accounting, payment and card-testing abuse, content scraping, account-takeover attempts at login, and ban evasion, because rotating circuits is a cheap way to change the IP each attempt arrives from. Those are not lookups. Those are the parts worth writing about.

What is Tor, and why the exit node is the visible point?

Tor, short for The Onion Router, first released in 2002, routes a connection through at least three volunteer-run relays, wrapping it in layers of encryption so no single relay sees both who you are and what you are visiting. The entry relay knows your real IP but not your destination; the exit relay knows the destination, your server, but not your real IP. Your application only ever sees the exit node, and because that exit relay is published, the exit node is the point where Tor becomes detectable to a website.

This is also why network-level Tor detection and web-level Tor detection are different jobs. On a corporate network, security teams identify Tor by inspecting traffic patterns, known ports, and the TLS handshake with deep packet inspection or flow analysis. That is the firewall and SIEM world. At the web-application layer, where a request simply arrives at your server, the practical signal is the exit-node address itself, plus what the rest of the session tells you about the visitor behind it.

The trap: Tor is not the same as fraud

The mistake that costs you real users is treating a Tor flag as a guilty verdict. Tor exists because anonymity has legitimate uses, and the people relying on it are mostly not the people you are trying to stop. The Electronic Frontier Foundation and the Tor Project document the everyday users: journalists protecting sources, people in censored regions, domestic-abuse survivors, security researchers, and ordinary users who simply do not want to be tracked. Using Tor is legal in most of the world, including the United States.

Blocking all Tor traffic outright is the blunt response, and it has a real cost: you turn away legitimate visitors to catch a thin slice of bad actors who, in any case, can switch to a residential proxy the moment Tor stops working.

The better posture is the same one that works for any anonymity signal: treat Tor as a risk input, raise the scrutiny on a Tor session without auto-rejecting it, and let the rest of the evidence decide. Score it, do not ban it.

The harder problem: one actor, many exit IPs

Here is the part the exit-node lookup does not solve. A single Tor user can build a new circuit, and therefore present a new exit IP, as often as every few minutes. To anything that reasons about visitors by IP address, that one person looks like a stream of unrelated strangers, each arriving from a different exit node. The whole technique of rotating circuits is built to defeat IP-based tracking, and against an IP rule it works.

What does not change between circuits is the machine. The browser, the device, and the way it renders and behaves stay the same while the exit node rotates underneath them. Reading that device layer is what ties the "different" Tor sessions back to one actor: a stable device identifier survives the circuit rotation that resets the IP.

So the useful question shifts from "is this Tor?" (easy, and the abuser knows you can see it) to "is this the same device coming back through Tor again?" (the linkage a rotating exit address is meant to hide).

Reading Tor as one anonymity signal, not a verdict

Tor is most useful as one entry in a wider set of anonymity signals, not as a standalone trigger. On its own a Tor flag tells you someone wants privacy. Combined with other signals it starts to tell you something about intent. The reads that do the work:

Signal alongside Tor	What it adds	Strength
The same device across several Tor sessions	one actor rotating circuits, not many visitors	High
An anti-detect browser over Tor	a profile deliberately built to look unique per session	High
Tor plus a declared identity that keeps changing	cosmetic identity churn behind a stable machine	Medium-High
A Tor exit in one place, device hints from another	a connection actively masking its origin	Medium

No single row is a verdict. A privacy-minded user on Tor trips the first signal once and looks nothing like a farm; the same device returning through a dozen exits to open a dozen accounts is the pattern worth a closer look. The combination, read into a risk score, is what separates the two without punishing either by default.

How to detect Tor traffic at the web layer

Putting it together, web-layer Tor detection is a short, honest stack:

1. Match the exit-node list. Check the request IP against the Tor Project's published exit addresses. This catches the bulk of Tor traffic at near-zero cost and is the commodity part of the job. It will not catch a Tor bridge, an entry point the project deliberately keeps off the public list for users evading censorship, which is one more reason not to lean on the list alone.
2. Link the device across circuits. Tie the session to a persistent device identifier so a rotating exit IP does not read as a new visitor each time. This is the part an IP-only view misses.
3. Corroborate with the other anonymity signals. Weigh Tor next to anti-detect-browser use, proxy and VPN signals, and the consistency of the rest of the session, so the score reflects the whole picture rather than one flag.
4. Decide on the score, not the flag. Keep the action, allow, challenge, or review, as a business rule on top of the score, so a legitimate Tor user is not blocked for using Tor.

Detecting Tor traffic with ShieldLabs

ShieldLabs reads Tor as one of its named anonymity signals, returned with a risk score from 0 to 100 on every visit through one JavaScript snippet. When a request arrives over a Tor exit node, that surfaces as an anonymity signal; when the same device comes back across rotating circuits, a persistent device identifier links those sessions back to one actor, which is the linkage the circuit rotation is meant to break.

To be clear about scope: ShieldLabs reads the web request. It names the Tor signal, links the device behind rotating exits, weighs it with the other anonymity signals into one score from 0 to 100, and provides pre-built patterns in the analytics dashboard; network-layer monitoring is a separate job. You read that risk score and the named anonymity signals through the API and webhooks and decide, by your own rules, whether to allow, challenge, or review, so a journalist on Tor is not treated like a farm. The same anonymity layer carries into proxy and VPN detection.