Why This Question Comes Up

Every site that accepts user signups, processes payments, or publishes region-licensed content eventually asks the same thing: *should we block Tor users, and if so how*? The answer is nuanced. Tor users are a mix of privacy-conscious individuals, journalists and activists in restrictive regimes, security researchers, and — statistically — a disproportionate share of fraudsters and abusers.

The Tor network itself is large and active. As of mid-2025 the network runs approximately 8,000 active relays, of which roughly 2,500 are exit relays — the subset that actually reaches out to destination sites, and therefore the subset you see as source IPs on your servers. That number has almost doubled from the ~1,400 exit relays counted in late 2021. The total user base sits in the low millions daily.

The exit relays are the ones that matter to defenders. Every Tor user's traffic reaches your site from one of those ~2,500 IPs. Block the list and you have blocked every Tor user. The list is publicly maintained by the Tor Project itself (see the bulk exit list), refreshed every 30 minutes, and trivially fetchable.

The Good News: Tor IPs Are Fully Enumerable

Unlike VPN detection, where new servers appear daily and attribution is a constant arms race, Tor has a fundamental property that makes it easy to detect: every exit relay has to publish itself in the network consensus document. If a relay does not publish, it does not receive circuits. This is baked into the Tor protocol.

As a result, detecting Tor is deterministic, not probabilistic. You either match the published exit relay list or you do not. False positives are essentially zero.

Predax refreshes its Tor list hourly from the Tor Project's authoritative directory. A response with classification.is_tor: true is as close to 100% accurate as IP classification gets.

The Hard Part: Deciding What to Do With It

This is where most people get it wrong. They treat "is this a Tor user" as a binary policy question — block or allow — when the right answer depends entirely on the action the user is trying to take.

At signup, Tor users are statistically high-risk. A very rough rule of thumb from industry fraud data: the fraud rate on signups from Tor is 20–50× higher than residential baselines for consumer SaaS. Treat Tor signups with more scepticism: require email verification with a long delay, block disposable email domains, reject the signup outright if the user also supplies a payment method from a mismatched country, or simply present a "this IP is not supported for signup" message and let them retry without Tor.

At login, legitimate Tor users exist. A privacy-conscious user who created their account normally and now wants to log in from Tor is not necessarily a threat — they are protecting themselves from surveillance. Blocking at login is a heavy-handed move that breaks a real use case. A better default: allow Tor logins, but require step-up authentication (TOTP, WebAuthn, email code) every time. This gives privacy-conscious users a path through and makes account takeover via Tor meaningfully harder without breaking anyone.

At checkout / payment, Tor users are a solid block. The correlation between Tor exits and card-not-present fraud is high enough that almost every payment processor and fraud engine rates Tor transactions at near-maximum risk. Declining is the right call.

At content access, the answer depends on your licensing obligations. Streaming services typically have to block Tor because they cannot establish the user's real jurisdiction; news sites typically do not and should not, because Tor is a lifeline for readers in restrictive countries.

On your blog or marketing site, blocking Tor is almost always the wrong call. You lose legitimate readers and gain nothing — a marketing page is not a threat surface. Allow freely.

A Practical Blocking Pattern

The cleanest pattern is to evaluate Tor at the action layer, not globally at the request layer. Your signup endpoint checks for Tor. Your payment endpoint checks for Tor. Your comment form checks for Tor. Your / homepage does not.

Using Predax's API, this looks like:

async function isRiskyTorRequest(ip) {
  const res = await fetch('https://predax.io/api/v1/check/ip', {
    method: 'POST',
    headers: {
      'X-API-Key': process.env.PREDAX_API_KEY,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ ip }),
  });
  const data = await res.json();
  return data.classification?.is_tor === true;
}

// Signup handler
app.post('/signup', async (req, res) => {
  if (await isRiskyTorRequest(req.ip)) {
    return res.status(403).json({
      error: 'Signup via Tor is not supported. Please try again from a regular connection.',
    });
  }
  // ... continue with signup
});

// Login handler
app.post('/login', async (req, res) => {
  const isTor = await isRiskyTorRequest(req.ip);
  if (isTor) {
    req.session.requireMfa = true; // force step-up, don't block
  }
  // ... continue with password check
});

Three rules that will save you pain:

1. Never block at the homepage level. You will kill SEO and cut off legitimate readers, including researchers who may cite you.
2. Always return an informative error. "Tor is not supported for signups" lets a legitimate user switch networks and retry. A generic "Access denied" just makes them bounce and complain.
3. Audit your block rate. If more than ~1% of login attempts are Tor, you have a bigger problem (Tor is not that popular). If it's under 0.1%, you probably don't need to do anything special for login at all.

What About Tor Bridges?

Tor bridges are unpublished entry relays designed to hide the fact that someone is using Tor. They are used by people in countries that block the public Tor relays (China, Iran, Russia). Bridges do not help attackers — they help real users reach Tor in the first place. From the destination site's perspective, bridged users still exit from the same ~2,500 public exit relays, so your detection still works.

Alternatives to Full Blocking

If outright blocking feels too aggressive for your use case, the middle path is friction tuning:

• Trial signup limits: Tor users get a shorter trial (7 days instead of 14), lower rate limits, cannot invite teammates, cannot use certain high-abuse features.
• Delayed email confirmation: email confirmation link expires in 5 minutes instead of 24 hours — annoying but not impossible for legitimate privacy users.
• Reputation scoring: attach Tor origin as a single signal among many. If the user has a valid paid account, completes KYC, and their billing country matches their registered country, let them log in from Tor without friction. If they are a week-old free account with no verified data, block them.
• Manual review queue: any high-value action from a Tor exit (password reset, email change, payout request) triggers manual review instead of auto-processing.

Summary

Tor is the easiest privacy network to detect — the exit relay list is public and authoritative. The hard part is deciding what to do with that detection. Block at signup and payment, friction-adjust at login, allow freely at content. Never block indiscriminately. Monitor your rate, tune your thresholds, and remember that most Tor users are just people who care about their privacy — not attackers.

Related guides

• How to detect VPN users — the policy decisions are similar; the false-positive profile is not.
• Residential vs datacenter proxies — Tor is one privacy layer; here's the rest of the landscape.
• How IP risk scoring works — Tor is one of the highest-weight signals in the score.
• ASN-based blocking explained — the cheaper bulk-block alternative when per-IP feeds lag.
• iCloud Private Relay vs Cloudflare WARP — privacy layers that, unlike Tor, carry mostly legitimate paying users.

See pricing to add Tor-aware policy to your stack.