What Is the Tor Network?
Why Tor Exit Node check? Tor (The Onion Router) is an anonymity network that routes internet traffic through a series of volunteer-operated relay nodes, encrypting it in layers at each hop, before exiting onto the public internet through a final exit node. From the perspective of any web server receiving that traffic, the visible source IP is the exit node’s address — not the original user’s. This design makes Tor a powerful tool for privacy-conscious users and journalists operating under surveillance, but the same anonymization mechanism is routinely exploited for fraud, credential stuffing, scraping, and other abuse where the attacker needs to obscure their real location.
The Tor Exit Node Check API by GLOBUS.studio checks any IP address against the current list of known Tor exit nodes, refreshed every 30 seconds to track the network’s constantly rotating infrastructure. It returns a structured JSON response with a boolean is_tor flag and a descriptive message, at 1ms latency.
API Endpoint and Parameters
GET https://api.globus.studio/v2/tor?ip={address}ip— the IPv4 address to check against the Tor exit node list
The response is always JSON with three fields: ip, is_tor (boolean), and message (human-readable status string). Full reference and live testing are available on the Tor Exit Node Check API documentation page.
Request and Response Examples
Tor Exit Node Detected
GET /v2/tor?ip=185.220.101.30
{
"ip": "185.220.101.30",
"is_tor": true,
"message": "The IP address is using Tor."
}Regular IP — Not Tor
GET /v2/tor?ip=8.8.8.8
{
"ip": "8.8.8.8",
"is_tor": false,
"message": "The IP address is not using Tor."
}Why the 30-Second Refresh Cycle Matters
The Tor network’s exit node list is not static. Volunteer operators bring nodes online and offline continuously — the Tor Project’s own metrics show thousands of relays active at any given time, with the set changing throughout the day. An exit node list that is hours or even minutes stale will miss recently activated nodes, allowing fresh Tor traffic to pass undetected. The API’s 30-second refresh cycle tracks the live network state as closely as any production system can practically achieve, making detections reliable rather than approximate.
Common Use Cases
Fraud Prevention and Risk Scoring
Tor exit nodes are a common infrastructure choice for payment fraud, account takeover, and carding operations — anonymization is a prerequisite for attacks that would otherwise be trivially traced. Detecting Tor usage at transaction time adds a high-signal risk dimension that is independent of behavioral analysis: a legitimate customer checking out on an e-commerce site rarely does so through Tor, while a fraudster almost always needs anonymization. A is_tor: true result can automatically elevate a transaction’s risk score, trigger additional verification steps, or flag the order for manual review.
Account Registration Abuse Prevention
Bulk account creation — for spam, fake reviews, referral fraud, or platform manipulation — requires anonymization to prevent IP-based rate limiting from stopping the operation. Tor provides that anonymization at scale. Checking registration-origin IPs against the exit node list before committing a new account to the database adds a gate that forces abusers to either abandon Tor (exposing their real IP to other detection methods) or accept that their accounts will be blocked or flagged at creation time.
WordPress Security Plugins
WordPress login pages, comment forms, and contact endpoints are among the most frequently targeted surfaces on the internet. A security plugin that calls the Tor exit node check API via wp_remote_get() during the authenticate or pre_comment_approved hook can apply differentiated treatment to Tor traffic — blocking it outright, requiring CAPTCHA completion, or silently queuing it for moderation — without affecting legitimate users. Given the 1ms latency and a transient cache keyed on IP, the check is effectively free in terms of response time impact.
Access Control for Sensitive Resources
Applications handling high-value or regulated content — financial dashboards, healthcare portals, legal document platforms — may have compliance or policy requirements to prevent access from anonymized sources. Checking the source IP at session creation time and blocking or logging Tor exit nodes satisfies this requirement without relying on VPN detection (which is broader and catches legitimate users) or user-agent analysis (which is trivially spoofed).
Content Moderation and Comment Spam
Abusive content submissions — harassment, doxxing, coordinated spam campaigns — frequently originate from Tor to prevent author identification. Forums, community platforms, and comment systems can use Tor detection as an early signal to route submissions into a moderation queue rather than publishing immediately, giving human reviewers a chance to evaluate content before it reaches an audience. This is a softer approach than outright blocking, which would exclude legitimate whistleblowers and privacy-conscious users who have valid reasons to use Tor.
Credential Stuffing and Brute-Force Protection
Automated login attacks that cycle through leaked credential databases need to distribute requests across many IPs to avoid rate limiting. Tor provides a continuously rotating pool of exit node IPs that makes traditional IP-based rate limiting ineffective on its own. Detecting Tor at the authentication endpoint and applying a strict per-exit-node rate limit — or requiring a second factor for all Tor-originated logins — significantly raises the cost of these attacks without blocking legitimate Tor users from authenticating entirely.
Analytics and Traffic Segmentation
Understanding what share of your traffic originates from Tor provides actionable intelligence for both security and product teams. A sudden spike in Tor traffic to a specific endpoint — a checkout page, a registration form, an API route — is an early indicator of an ongoing automated attack before abuse becomes visible in conversion metrics or error rates. Tagging analytics events with Tor status at ingestion enables real-time dashboards that surface these anomalies as they develop.
Regulatory Compliance Logging
Financial institutions, exchanges, and regulated platforms operating under KYC/AML requirements must log and in many cases restrict access from anonymizing infrastructure. Recording is_tor: true in audit logs alongside each transaction or session creates a compliance trail that demonstrates due diligence without requiring a separate Tor detection system to be built and maintained internally.
Integration Examples
cURL
curl "https://api.globus.studio/v2/tor?ip=185.220.101.30"JavaScript (Fetch API)
const res = await fetch('https://api.globus.studio/v2/tor?ip=185.220.101.30');
const data = await res.json();
if (data.is_tor) {
console.warn('Tor exit node detected — applying additional verification');
} else {
console.log('Not Tor:', data.message);
}PHP
$ip = '185.220.101.30';
$response = json_decode(
file_get_contents("https://api.globus.studio/v2/tor?ip={$ip}"),
true
);
if ($response['is_tor']) {
// block, flag, or require additional verification
echo 'Tor detected';
} else {
echo 'Not Tor';
}Python
import requests
data = requests.get(
'https://api.globus.studio/v2/tor',
params={'ip': '185.220.101.30'}
).json()
if data['is_tor']:
print(f"Tor exit node: {data['ip']}")
else:
print(data['message'])WordPress (PHP) — Login Hook with Transient Cache
add_filter( 'authenticate', function( $user, $username ) {
$ip = $_SERVER['REMOTE_ADDR'];
$cache_key = 'tor_' . md5( $ip );
$cached = get_transient( $cache_key );
if ( false === $cached ) {
$response = wp_remote_get(
'https://api.globus.studio/v2/tor?ip=' . rawurlencode( $ip )
);
$cached = json_decode( wp_remote_retrieve_body( $response ), true );
set_transient( $cache_key, $cached, 30 ); // match API refresh cycle
}
if ( ! empty( $cached['is_tor'] ) ) {
return new WP_Error(
'tor_blocked',
'Login from anonymizing networks is not permitted.'
);
}
return $user;
}, 30, 2 );Node.js — Express Middleware
const fetch = require('node-fetch');
async function torDetectMiddleware(req, res, next) {
const ip = req.ip;
const response = await fetch(
`https://api.globus.studio/v2/tor?ip=${ip}`
);
const data = await response.json();
if (data.is_tor) {
return res.status(403).json({
error: 'Access from Tor exit nodes is not permitted.'
});
}
next();
}
// Apply to sensitive routes only:
app.post('/register', torDetectMiddleware, registerHandler);
app.post('/checkout', torDetectMiddleware, checkoutHandler);Balancing Security and Privacy
Tor carries a dual reputation: it is the tool of choice for both privacy-conscious legitimate users — journalists, activists, researchers, people under authoritarian surveillance — and for a subset of bad actors who exploit anonymization for abuse. A blanket block of all Tor traffic will exclude some legitimate users; a blanket allow will admit abusers. The right policy depends on the application context:
- High-risk endpoints (checkout, account creation, password reset) — block or require strong additional verification
- Content access — allow but route to a moderation queue or stricter rate limit
- Read-only public content — allow with logging; Tor users reading public pages are almost never a risk
- Analytics — tag and segment; never conflate Tor traffic with organic user behavior
The API’s boolean response makes it straightforward to implement any of these policies conditionally, per route, rather than applying a single global rule.
Performance
At 1ms average latency, Tor detection adds no perceptible overhead to any request pipeline. The check is a pure in-memory lookup against the locally cached, 30-second-refreshed exit node list — no external network calls, no DNS queries. The WordPress transient example above sets a TTL of 30 seconds to align with the API’s own refresh cycle, ensuring that a newly activated exit node is never missed by more than one cache window.
Explore live detections and review the full response schema on the Tor Exit Node Check API documentation page.