> ## Documentation Index
> Fetch the complete documentation index at: https://docs.shieldlabs.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Anonymity Signals
> Learn which anonymity signals ShieldLabs detects, what each one means, and how they add up to a score.
Each anonymity signal answers one question: is this visit masked — relayed, tunneled, spoofed, or coming from infrastructure rather than a genuine, unmasked visitor?
When a signal fires, it becomes a stable slug in the webhook's `data.signals` array (`name` + `weight`) and a matching boolean in `data.detection_flags`. **Branch on `name`, `detection_flags`, and the score band in code.** ShieldLabs surfaces these signals; your own code owns the decision: allow, challenge, review, or block. [Risk Scoring](/features/risk-scoring) explains how the points roll up.
## Network and anonymity
These signals indicate the connection is relayed, tunneled, or coming from infrastructure rather than a genuine, unmasked visitor.
| Signal | What it indicates | Why it matters |
| --------------------- | --------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| **Tor** | The connection exits through the Tor network. | The strongest single anonymity signal: ordinary visitors rarely use Tor, and it is built to hide where a visit comes from. |
| **VPN** | The connection runs through a VPN. | Common and often legitimate (corporate or privacy use), so a lighter signal on its own. |
| **Privacy Relay** | iCloud Private Relay or a similar relay. | Mainstream and privacy-driven, so it is surfaced on its own and treated more gently than a deliberate proxy. |
| **Proxy** | The connection is routed through a proxy. | A common masking tool; weigh it together with the datacenter and abuser signals. |
| **Browser VPN/Proxy** | An in-browser VPN or proxy extension is in use. | An extension-level mask, a deliberate choice to hide the connection. |
| **Datacenter IP** | The IP belongs to a datacenter or hosting network, not a residential ISP. | Ordinary people rarely browse from datacenters, so it points to automation or relayed traffic. |
| **Abuser Flag** | The IP or device is on an abuse reputation list (a blocklist of addresses or devices tied to past abuse). | Prior abuse history corroborates other masking signals. |
## Consistency and mismatch
These signals indicate two readings of the same visit disagree, which is what spoofed or relayed visits leave behind.
| Signal | What it indicates | Why it matters |
| --------------------- | ---------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| **OS Mismatch** | The operating system the browser reports is inconsistent with other evidence about the device. | A strong spoofing tell: an honest device does not contradict itself. |
| **Timezone Mismatch** | The device timezone does not match the IP geolocation. | A lighter location-spoofing tell; it can be innocent (travel), so weigh it with the rest. |
## Environment
These signals indicate the runtime is spoofed, stripped, or could not be fully verified.
| Signal | What it indicates | Why it matters |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
| **Anti-detect Browser** | Anti-detect or fingerprint-spoofing tooling is present. | A deliberate, sophisticated attempt to evade identification — a strong tell. |
| **Browser Automation** | The browser is driven by an automation framework rather than a person — the standard `navigator.webdriver` flag is set (frameworks such as Selenium, Puppeteer, or Playwright set it by default). | Automation-controlled browsers are near-certain non-human traffic — a strong tell that scores independently of the connection. |
| **JavaScript Disabled** | The page ran without the scripting a real browser provides. | Near-certain automation or a headless client, not an ordinary visitor — one of the strongest tells. |
| **OS not Detected** | The operating system could not be derived from the available evidence. | A stripped or unusual environment; treated as precautionary. |
| **Stun not checked** | The follow-up network check did not complete. | Anonymization tools often block this check, so a failure can mean the visit's network is masked. |
## Surfaced, not currently scored
These are detected and returned on the webhook in `detection_flags`, but they add **no points** to the Risk Score today:
| Signal | What it indicates |
| ------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Incognito** | The visit is in a private / incognito browsing mode (`incognito`). |
| **IP Mismatch** | The public `public_ip` differs from the local network-check IP (`ip_mismatch`). A raw difference can be benign — mobile networks route over different paths — so compare `public_ip.country` with `local_ip.country` if location matters. |
| **Suspicious paid click** | A request that arrived on a paid channel and scored high (`suspicious_paid_click`). See [Traffic Quality](/use-case/traffic-quality). |
| **Search bot** | The visit comes from a known search-engine crawler IP such as Googlebot or Bingbot (`search_bot`). It is not a masking signal: it adds no points and instead reclassifies the visit into the **Search bot** [traffic channel](/features/traffic-analytics) so crawlers do not distort your analytics. |
## Signal weights
Each anonymity signal adds to the Risk Score by a fixed weight, listed in the full weight table on [Risk Scoring](/features/risk-scoring). Signals sum into the score and the total is capped at 100. The strongest anonymity signal (Tor, then Privacy Relay, then VPN) takes priority over the others.
## Why the VPN signal catches more
ShieldLabs corroborates VPN across multiple signals, so it catches masking that a simple IP blocklist misses.
A blocklist is always behind: commercial VPNs rotate through large IP pools daily, and residential proxies hide on ordinary consumer ISPs. Because the VPN signal does not depend on a list alone, a fresh exit node that no blocklist has yet seen can still surface.
## Connection type
Every visit also resolves to a single **connection type**, the headline label for how the visit reaches you. It is surfaced as `connection_type` on the [webhook](/api/webhooks) and as `ConnectionType` on each [History API](/api/server-api) snapshot.
The per-visit `connection_type` on the webhook and API is one of: **Direct**, **Mobile**, **VPN**, **Proxy**, **Tor**, **Privacy Relay**, **Browser VPN/Proxy**, or **Unknown** (when the type could not be resolved). The dashboard **Connection Types** breakdown uses the same buckets and rolls **Browser VPN/Proxy** into **Proxy** for the chart.
| Connection type | What it indicates | Webhook / API (`connection_type`) | Dashboard breakdown |
| --------------------- | ----------------------------------------------------------- | --------------------------------- | ---------------------------------- |
| **Direct** | An ordinary connection with no masking signal. | Yes | Yes |
| **Mobile** | A cellular carrier network, including tethering or hotspot. | Yes | Yes |
| **VPN** | Traffic runs through a VPN. | Yes | Yes |
| **Proxy** | The connection is routed through a proxy. | Yes | Yes (includes Browser VPN/Proxy) |
| **Tor** | The connection exits through the Tor network. | Yes | Yes |
| **Privacy Relay** | The connection is relayed through iCloud Private Relay. | Yes | Yes |
| **Browser VPN/Proxy** | An in-browser VPN or proxy extension. | Yes | Rolled up under Proxy in the chart |
| **Unknown** | The connection type could not be resolved. | Yes | Yes |
The connection type is a summary. The `signals` array on the Risk Score is the full breakdown: one visit can carry a proxy connection type along with a datacenter and abuser flag underneath it.
## A masked visit is not always abuse
A legitimate visitor can carry these signals. A corporate VPN, iCloud Private Relay, or a privacy-focused browser all raise the score without any wrongdoing.
The connection type alone is not a verdict. Take the Risk Score, the anonymity `signals`, and the sensitivity of the action into account together — the same masked visit can warrant no friction on a low-stakes page and a challenge at a withdrawal, so [match the response to the stakes](/guides/acting-on-risk-score).
Because every signal is explainable, your code can treat a Privacy Relay differently from a Tor exit or a datacenter IP. All are masking, but they carry different intent, and you decide which action each one warrants.
## Example
A visit on an anti-detect browser running through a proxy returns both reasons in `signals`:
```json theme={null}
{
"request_id": "13f84f05-3b2a-4f1e-9c7d-2a4b6e8f0a11",
"device_id": "5eb7fd5c-8c2e-4a91-b0f3-1d7c9e2a4b55",
"visitor_id": "161dfbad-2f4a-4c81-9e0b-7a3c5d8f1e22",
"public_ip": {
"ip": "203.0.113.42",
"country": "NL"
},
"os": "Windows",
"user_hid": "u_7f3c9a2b",
"connection_type": "proxy",
"risk_score": 70,
"signals": [
{ "name": "Anti-detect Browser", "weight": 60 },
{ "name": "Proxy", "weight": 10 }
],
"observed_at": "2026-06-16T18:00:45Z"
}
```
The two signals add 60 and 10, landing at 70 in the High band.
The `signal` strings are display labels and can change — **never branch on them**. Use `detection_flags` to see which signals fired. The same numeric weight from two different signals is not interchangeable; read the band, the flags, and the action context together.
Because both reasons are visible, your code can require verification before a withdrawal while letting a low-stakes action through with no friction.
## Next steps
How signal weights roll up into the 0-100 score and the Clean, Low, Medium, and High bands.
The dashboard patterns that grade an identity over time, distinct from these per-request signals.