Blocking Tor Bridges, Not Just Exit Nodes

If you have ever blocked Tor traffic on your store, you almost certainly blocked exit nodes. Public directories list every exit relay, so it takes one lookup to reject an order coming from a known Tor endpoint. Fraudsters know this too. That is why the more determined ones stopped using plain exit nodes years ago and moved to bridges instead.

The result is a false sense of security. Your dashboard shows Tor orders dropping to near zero, and you assume the problem is solved. In reality, a portion of that traffic simply changed shape and kept coming through.

Exit nodes vs. bridges

The Tor network is built from volunteer relays. Traffic hops through several of them before reaching the open internet.

• Exit nodes are the last hop. They are the IPs that actually connect to your Shopify store, so they appear in your logs. Because the Tor Project publishes the full exit list, anyone can download it and block every address on it.
• Bridges are unlisted entry points into the Tor network. They exist specifically for users in censored regions who cannot reach the public relays. Bridges are distributed privately, in small batches, through email, HTTPS, or messaging bots so that no single actor can enumerate them all.

Here is the important part for fraud: a user who connects through a bridge can still exit through a normal exit node, or through a pluggable transport that disguises the traffic entirely. But the reverse trick matters more. When someone runs their own exit path or uses obfuscated transports like obfs4, meek, or Snowflake, the connecting IP that hits your checkout may look like an ordinary residential or cloud address. It will not appear on any exit-node blocklist, because it is not an exit node at all.

Why bridges evade blocklists

Blocklists work by enumeration. Someone has to know an address is malicious before it can be added. Bridges break that model by design:

• They are handed out in small pieces. The distribution system deliberately prevents anyone from harvesting the full set, which is exactly the property that stops fraud teams from harvesting it too.
• Snowflake uses volunteer browsers. Snowflake proxies run inside ordinary people's web browsers as temporary WebRTC relays. The connecting IP is a random residential address that changes constantly and belongs to someone with no idea they are relaying traffic.
• Pluggable transports mimic normal traffic. obfs4 and meek are built to look like regular HTTPS or CDN traffic, so simple protocol fingerprinting does not catch them.

An exit-node list has none of this information. It is a snapshot of known endpoints, and bridges live entirely outside that snapshot.

What a Tor bridge order looks like at checkout

You will rarely get a single smoking-gun signal. Bridge-routed fraud tends to show up as a cluster of small oddities:

• Signals. A residential or datacenter IP with no order history, paired with billing details from a completely different region. Time-zone mismatch between the browser and the stated shipping country. A brand-new customer placing a high-value order for easily resold goods. Rapid checkout completion with autofilled fields, suggesting scripted assistance.
• Signals. Connection latency patterns consistent with multi-hop routing. Repeated attempts from rotating IPs that share a device fingerprint. Email addresses on disposable or freshly registered domains.

No one of these proves Tor bridge usage. Together, they paint a picture that a flat blocklist will never see.

Layered blocking beats list blocking

The lesson is not "give up on blocking Tor." It is that a single list is the wrong tool. Effective anonymized-fraud defense stacks several independent checks so that traffic hiding from one layer still trips another.

Best control. Combine network reputation, behavioral signals, and risk scoring rather than relying on any single feed. A layered stack typically looks like this:

• IP reputation, refreshed continuously. Known exit nodes, public VPN ranges, datacenter ASNs, and flagged proxies get scored on arrival, not from a stale monthly download.
• VPN and proxy detection beyond named lists. Many bridge users chain a commercial VPN or proxy in front of Tor. Detecting the anonymization layer catches the traffic even when the specific bridge is invisible.
• Behavioral and device fingerprinting. Rotating IPs cannot easily rotate a device fingerprint. When the same fingerprint reappears across many "new" customers on different addresses, that is a stronger signal than any single IP.
• AI fraud scoring. A model weighing dozens of features at once, such as geo mismatch, order composition, velocity, and email age, flags the composite risk that no individual rule would catch.
• Checkout-level enforcement. The block has to land at the moment of purchase, before the order is created, so you are not chasing refunds and chargebacks after the fact.

This is precisely the layered approach Shieldy Fraud Filter is built around. Instead of a single Tor toggle, it scores IP reputation, detects VPN and proxy layers, fingerprints devices, and applies AI risk scoring at checkout, so traffic that dodges the exit-node list still meets several other filters.

A practical setup for Shopify stores

You do not need to catch every bridge in the world. You need to make anonymized fraud expensive enough that it moves on. A reasonable configuration:

1. Block known Tor exit nodes and public VPN or proxy ranges outright. This clears the easy 80 percent of anonymized traffic with almost no false positives.
2. Raise the risk score, do not hard-block, on ambiguous residential IPs with strong secondary signals like geo mismatch or a disposable email. Send these to manual review rather than auto-approving.
3. Enforce device-fingerprint velocity limits. If one fingerprint spawns five "new" accounts in an hour across five IPs, hold every one of them.
4. Let AI scoring make the final call on borderline orders, so you are not maintaining brittle rules by hand.

The false-positive risk is real, and it matters. Some legitimate privacy-conscious shoppers use VPNs or even Tor for entirely benign reasons. That is why the middle tier should score and review rather than reject outright. Blocking a genuine customer costs you a sale and goodwill; the layered model keeps that cost low by reserving hard blocks for high-confidence cases.

The takeaway

Exit-node blocking is necessary but not sufficient. Bridges exist specifically to be unlistable, and Snowflake in particular can make Tor traffic look like an ordinary home connection. The only durable answer is layered defense: reputation, VPN and proxy detection, device fingerprinting, and AI scoring working together at the checkout level.

If your current setup is a single Tor list, you are catching the traffic that wanted to be caught. Everything else is walking through. Take a few minutes to review your pricing and plan options and turn on the layers that a blocklist alone can never provide.