Skip to main content
Anonymity detection is the part of ShieldLabs that answers one question for every visit: is this connection hiding where it really comes from? A visitor can mask their origin with a VPN, a proxy, the Tor network, a datacenter host, or an anti-detect browser. ShieldLabs identifies these connection types, scores how anonymous the visit looks, and names the exact signal that fired. As always, ShieldLabs only surfaces the signal. Your own code decides allow, challenge, review, or block. See Acting on the Risk Score.
Anonymity signals are a subset of the full signal set that feeds the Risk Score. This page covers connection and masking signals. For every signal and its weight in one table, see Signals.

​
Why blocklists are not enough

The naive approach to anonymity detection is a static IP blocklist: keep a list of known VPN and proxy IPs and look up each visitor. That approach is always behind, for three reasons.

VPNs rotate IPs

Commercial VPN services cycle through large IP pools and add new addresses daily. A list that was current yesterday already misses today’s exit nodes.

Residential proxies hide on consumer ISPs

Residential proxies route traffic through real consumer ISP addresses that never appear on a datacenter blocklist, so a lookup sees an ordinary home connection.

New services outpace static DBs

New masking services launch faster than any single database can catalog them, so a blocklist is structurally incomplete the day it ships.
ShieldLabs does not rely on a blocklist lookup. It runs multi-layer connection analysis: it compares what the browser claims against what the network shows, looks for disagreement across layers, and runs a real-IP (WebRTC) check that can reveal an address the connection is trying to hide. Reputation data is one input among several, never the only one.

​
Connection types

Every visit resolves to a connection type, shown in the dashboard and stored on the snapshot. These are the labels you will see:
Connection typeWhat it means
DirectAn ordinary connection with no masking signal. This is the default when no masking is found.
TorThe connection exits through the Tor network.
Privacy RelayiCloud Private Relay or a similar privacy-forwarding service.
VPNThe connection runs through a VPN, corroborated by the 2-of-3 rule below.
ProxyThe IP is flagged as a proxy.
A single connection type is the headline label. Underneath it, multiple individual signals can fire (for example a proxy IP that also carries a datacenter and abuser flag). The connection type is a summary. The Details array on the Risk Score is the full breakdown. See Risk Score.

​
The masking and reputation signals

These are the connection-level signals ShieldLabs evaluates. Each one is a plain-language entry in the Details array when it fires, with the points it contributed.
SignalWeightWhat it indicates
Tor99The connection exits through the Tor network.
VPN15The connection runs through a VPN, corroborated by the 2-of-3 rule.
Privacy Relay15iCloud Private Relay or a similar privacy-forwarding service.
Proxy10The IP is flagged as a proxy.
Datacenter IP10The IP belongs to a datacenter or hosting range, not a consumer ISP.
Abuser Flag10The IP or device appears on an abuse reputation list.
Browser VPN/Proxy30An in-browser VPN or proxy extension is detected.
Tor, Privacy Relay, and VPN are mutually exclusive in priority order: Tor first, then Privacy Relay, then VPN. If one fires, the others are not added. Tor is the strongest anonymity signal and short-circuits the rest. By contrast, Proxy, Datacenter, and Abuser do stack with each other, because a single connection can legitimately be all three.

​
Privacy Relay is treated as lower risk

Not every masked connection is adversarial. iCloud Private Relay and similar services are used by ordinary, privacy-conscious people on their everyday devices. ShieldLabs detects Privacy Relay as its own connection type and scores it far below Tor, so a privacy-aware customer does not look like a Tor exit node. This is a deliberate product nuance. The point of explainable scoring is that your code can treat Privacy Relay differently from a datacenter VPN. Both are masking, but they carry very different intent, and you decide which actions each one warrants.
A legitimate user can score high on anonymity alone. A corporate VPN, a privacy browser, or iCloud Private Relay all raise the score without any wrongdoing. Decide on Score plus Details plus the action context (a payment screen is not a blog read), never on the connection type alone. See Acting on the Risk Score.

​
Why corroboration surfaces VPNs that blocklists miss

VPN is the signal where corroboration matters most, because a blocklist alone gets it wrong in both directions: it flags retired IPs that are no longer VPNs, and it misses fresh exit nodes and residential proxies. ShieldLabs does not call a connection a VPN from a single hit. VPN is asserted only when at least 2 of 3 independent checks agree:
1

IP reputation

The IP’s reputation data indicates a VPN.
2

TCP / network fingerprint

The connection’s network fingerprint is consistent with a VPN tunnel rather than a direct connection.
3

Failed real-IP (STUN) check

The real-IP (WebRTC / STUN) check did not return the IP the connection is presenting, which is what you expect when a tunnel is in the way.
When two of these three agree, ShieldLabs asserts VPN. When there is no network-fingerprint data to consult, the threshold drops to 1 of 2 of the remaining checks. This corroboration is the reason a rotated VPN IP that is missing from every blocklist still surfaces: even with no reputation hit, the network fingerprint and the failed real-IP check can carry the verdict. The same real-IP check feeds two more signals that blocklists cannot produce:
SignalWeightWhat it indicates
IP Mismatch30The public IP does not match the IP derived from the real-IP (WebRTC) check.
STUN not Checked30The real-IP check did not complete, so masking could not be ruled out.
The real-IP discovery runs after the initial score, so it arrives in the update webhook (Phase: "update"), which carries only the delta signals. Correlate by RequestID and keep your handler idempotent. See Webhooks.

​
Anti-detect browsers and spoofing

Anti-detect browsers exist to forge a clean-looking browser signature so a visitor can run many identities without being linked. A fingerprint on its own can be faked, so ShieldLabs surfaces these tools through cross-layer mismatch: it compares what the browser claims against what the network and local environment actually show. When the layers disagree, the spoof is visible even though the fingerprint looks plausible.
SignalWeightWhat disagreement reveals
OS Mismatch60The OS the browser claims does not match the OS the network fingerprint shows.
Anti-detect Browser60Local indicators consistent with anti-detect or fingerprint-spoofing tooling.
Port-scan Proxy60Local routing indicates the connection is proxied. A hint of anti-detect tooling.
Anti-detect signals do not stack. One anti-detect verdict is enough, so a second indicator does not add a second penalty. The cross-layer mismatch story belongs as much to Device Intelligence as to anonymity, because it joins the browser fingerprint layer to the network layer.

​
Location and timezone mismatch

A masked connection often leaves a tell in geography. If a browser reports a Berlin timezone while its IP geolocates to Singapore, the two layers disagree, and that disagreement is its own signal.
SignalWeightWhat it indicates
Timezone Mismatch10The browser timezone does not match the timezone of the IP.
On its own a timezone mismatch is minor. Its value is in combination: a timezone mismatch alongside a VPN or proxy signal is a much stronger story than either alone, and because every signal is explainable you can write that combination logic in your own code.

​
Where the “up to 99%” accuracy comes from

ShieldLabs corroborates a verdict across independent layers rather than trusting any single lookup. The headline accuracy figure of up to 99% comes from 2-of-3 identifier agreement: instead of relying on one input, ShieldLabs cross-checks the device fingerprint layer and the network layer (IP reputation, network fingerprint, and the failed real-IP check) and only commits to a masking verdict when independent layers corroborate. Two layers agreeing is far harder to fake or to get wrong than a single blocklist lookup, and the VPN 2-of-3 rule above is one concrete instance of that approach.
ShieldLabs claims up to 99% accuracy, not 100%. Anonymity detection is probabilistic, and the honest framing is that a corroborated signal is strong evidence, not a guarantee. Always weigh the Risk Score, the Details, and the sensitivity of the action together.

​
How anonymity feeds your decision

ShieldLabs surfaces the connection type and the signals behind it. Your application owns the verdict. There is no in-product rules engine: you read the Score and Details from the webhook or History API and write the allow, challenge, review, or block logic in your own code. A sample webhook body for a visit on a proxy with a timezone mismatch: 
{
  "RequestID": "13f84f05-3b2a-4f1e-9c7d-2a4b6e8f0a11",
  "DeviceID": "5eb7fd5c-8c2e-4a91-b0f3-1d7c9e2a4b55",
  "VisitorID": "161dfbad-2f4a-4c81-9e0b-7a3c5d8f1e22",
  "IP": "203.0.113.42",
  "OS": "Windows",
  "Country": "Germany",
  "UserHID": "u_7f3c9a2b",
  "Score": 20,
  "Details": [
    { "Value": 10, "Description": "Is proxy" },
    { "Value": 10, "Description": "Browser timezone ≠ IP-timezone" }
  ],
  "LastRequestTime": "2026-06-16T18:00:21.685Z",
  "Phase": "initial"
}
Because you can see both reasons, your code can hold this visit for a step-up challenge on a withdrawal while letting the same visit read a blog post with no friction. A Is tor or Is proxy entry on a sensitive action usually warrants a hard challenge, while an Is abuser flag is worth treating as high-risk even at a moderate score.

​
Next steps

Signals

Every signal, its weight, and what it means for the Risk Score, in one reference table.

Risk Score

The 0-100 explainable score, the Clean / Low / Medium / High bands, and how signals combine.

Device Intelligence

How the browser fingerprint layer joins the network layer to catch spoofing.

Acting on the Risk Score

Turn Score plus Details into allow, challenge, review, or block in your own code.