> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fingerprintiq.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Edge Signals

Edge-derived signals and analyses extracted at the Cloudflare edge, impossible to spoof from the browser.

Edge signals and derived analyses are extracted at the Cloudflare edge before the request reaches FingerprintIQ's Worker code. Because they are derived from the underlying TCP/TLS connection and HTTP framing — not from JavaScript — they **cannot be modified by browser extensions, privacy tools, or JavaScript injection**.

Edge analysis complements the 41 browser signals. A sophisticated attacker can spoof canvas hashes or navigator values, but they cannot spoof their TLS stack, ASN, or network routing without fundamentally changing their infrastructure.

**TLS Fingerprint**

Every TLS connection begins with a ClientHello message containing cipher suite preferences, extension list, compression methods, and protocol versions. This combination is characteristic of the client's TLS implementation — Chrome, Firefox, and Safari each produce distinct fingerprints.

    FingerprintIQ captures:
    - **Cipher suite** negotiated for this connection
    - **TLS version** (1.2 or 1.3)
    - **HTTP protocol** (HTTP/1.1, HTTP/2, or HTTP/3 via QUIC)
    - **ClientHello length** — total bytes in the ClientHello message
    - **JA4 hash** — standardized, structured TLS fingerprint format

    Spoof resistance: Very High

    If the TLS fingerprint claims to be Chrome but the User-Agent says Firefox, the `UA_TLS_MISMATCH` risk factor is added and bot probability increases significantly.

  **ASN Classification**

Every IP address belongs to an Autonomous System (AS). FingerprintIQ classifies the AS into a category that characterizes the type of network the visitor is using.

    | Category | Description | Bot Signal |
    |----------|-------------|------------|
    | `RESIDENTIAL_ISP` | Home internet (Comcast, AT&T, BT) | Low |
    | `MOBILE_CARRIER` | Mobile network (T-Mobile, Verizon, EE) | Low |
    | `DATACENTER_MAJOR` / `DATACENTER_MINOR` | Cloud hosting (AWS, GCP, Azure, Hetzner, smaller VPS providers) | High |
    | `VPN_COMMERCIAL` | VPN provider (NordVPN, ExpressVPN, Mullvad) | Medium |
    | `TOR_EXIT` | Tor exit node | High |
    | `UNIVERSITY` | University or research network | Low |
    | `PROXY_RESIDENTIAL` | Residential proxy network | Medium |
    | `SATELLITE` | Satellite or atypical long-haul network | Medium |

    Spoof resistance: High

    FingerprintIQ also exposes direct booleans on the response: `isVpn`, `isTor`, `isDatacenter`, and `isResidentialProxy`. The API now includes taxonomy provenance too: `matchKind` tells you whether the result came from an exact ASN record, an exact organization record, or the fallback classifier, while `sources` and `confidence` show how strong that classification is.

  **Exact IP / Range Intelligence**

ASN classification is good, but it cannot disambiguate mixed hosting networks where only part of an ASN is used for proxies or Tor exits. FingerprintIQ therefore also supports exact IP and IP-range intelligence.

    Current feed types:
    - **Tor exit IPs** — exact IP matches from the Tor bulk exit list
    - **Public proxy ranges** — IP/range matches from the free IP2Proxy Lite feed
    - **Residential / provider metadata** — when present in richer free IP2Proxy Lite variants such as `px10`, `px11`, or `px12`

    The response includes `signals.server.ipNetwork`:
    - `matchKind` — `exact_ip`, `network_prefix`, or `none`
    - `category` — `TOR_EXIT`, `PROXY_GENERAL`, `DATACENTER_MINOR`, `VPN_COMMERCIAL`, `PROXY_RESIDENTIAL`, or `UNKNOWN`
    - `confidence` — confidence of the exact IP/range match
    - `sources` — feed provenance such as `tor:bulk_exit` or `ip2proxy:lite`

    Spoof resistance: Very High

    Exact network intelligence is stronger than ASN inference. A shared hosting ASN might look generic at the ASN level while a matched IP or range cleanly identifies a Tor exit route or public proxy.

    Feed freshness:
    - The repo includes a scheduled refresh pipeline via `pnpm refresh:intel --publish`
    - The free-only stack uses GeoLite ASN, the Tor bulk exit list, and an IP2Proxy Lite download URL injected via CI secrets
    - For the free stack, prefer an IP2Proxy Lite `px10` / `px11` / `px12` URL over the minimal `px2` feed so FingerprintIQ can ingest residential and provider metadata too
    - `lastRefreshedAt` on the API response tells you when the matched record was last rebuilt

  **Geo Coherence**

Cross-validates the claimed IP geolocation against actual network timing. A VPN or proxy creates a systematic discrepancy: the IP resolves to New York, but the TCP round-trip time is consistent with a connection originating in Europe.

    FingerprintIQ measures:
    - **TCP RTT** — Round-trip time for the TCP handshake
    - **QUIC RTT** — Round-trip time for the QUIC connection (HTTP/3)
    - **Expected RTT** — Estimated based on distance from the nearest Cloudflare colo to the claimed city

    **Coherence score** (0.0 – 1.0):
    - **1.0** — RTT matches location perfectly
    - **0.5 – 0.9** — Minor discrepancy (could be suboptimal routing)
    - **< 0.3** — Anomalous — likely VPN, proxy, or location spoofing

    Spoof resistance: High

    FingerprintIQ fuses exact IP intelligence, ASN classification, and geo coherence into a higher-level `vpnDetection` verdict:
    - **`detected`** — known Tor exit, public proxy, or explicitly catalogued VPN/proxy network from exact IP/range or ASN intelligence
    - **`suspected`** — hosting-network or RTT anomalies consistent with anonymized routing, but without a hard exact-network match
    - **`not_detected`** — no current network evidence of VPN/proxy routing

  **Network Oracle Benchmarking**

FingerprintIQ can sample a small percentage of production requests and compare its own network verdicts against an external oracle. This runs asynchronously after the identify request completes, so it is a QA and calibration tool, not a hot-path dependency.

    The API exposes the latest daily aggregate under `signals.server.oracleBenchmark`:
    - `status` — `active`, `warming_up`, or `disabled`
    - `sampleRate` — fraction of requests sampled in the background
    - `sampleCount` — number of sampled requests accumulated today
    - `matches` / `mismatches` — raw counters by metric (`asn`, `country`, `city`, `vpn`, `tor`, `hosting`)
    - `mismatchRates` — normalized disagreement rates by metric
    - `lastMismatchFlags` / `lastOracleService` — latest disagreement context for debugging

    This is useful for:
    - auditing ASN taxonomy quality
    - spotting geolocation drift or feed issues
    - tracking whether FingerprintIQ is over- or under-calling VPN / hosting traffic

    Treat oracle disagreement as calibration data, not ground truth. External IP intelligence providers disagree with each other too.

  **HTTP Header Order**

Browsers send HTTP headers in a characteristic order that differs between Chrome, Firefox, and Safari. This order is determined by the browser's network stack and does not change across requests.

    FingerprintIQ:
    1. Captures the exact header order hash
    2. Infers the browser from the order pattern
    3. Cross-validates against the User-Agent string

    A mismatch (e.g., header order consistent with Safari but UA claims Chrome) adds a `HEADER_UA_MISMATCH` risk factor.

    Spoof resistance: High

  **UA Consistency**

Cross-validates the User-Agent claim against independent signals collected from the same request:

    - UA says Chrome but TLS fingerprint matches Firefox → **`UA_TLS_MISMATCH`**
    - UA claims HTTP/2 support but connection is HTTP/1.1 → **`PROTOCOL_MISMATCH`**
    - Header order pattern matches Safari but UA says Chrome → **`HEADER_UA_MISMATCH`**
    - UA claims a browser version incompatible with the TLS cipher suite → **`VERSION_MISMATCH`**

    Any mismatch significantly increases bot probability, as legitimate browsers do not produce inconsistent signals.

    Spoof resistance: Very High

  **Request Priority**

HTTP/2 and HTTP/3 include stream priority signaling (PRIORITY frames or PRIORITY_UPDATE frames). Different browsers signal priority differently — this forms a subtle but reliable fingerprint of the browser's HTTP implementation.

    Spoof resistance: High