Contents
Getting started
10-minute quick startArchitecture
Install and upgrade
Install the controllerAdd nodesOnline upgradesStaged rollout and automatic rollbackBackup and point-in-time restoreUninstall and migrate
Sites
Add a siteSet up the CNAME recordHTTPS certificatesCache rulesPurge and prefetchOrigin settingsAlways Online, 0-RTT and 103 Early HintsTiered origin (L2)Stream forwarding (Layer 4)
Security
Security overview and big screenWebsite checkupAttack logCC protectionWAFLists and access controlBots and scannersJA4 / TLS fingerprintXDP kernel-level filteringPaid features
Analytics and alerts
StatisticsAccess logsAlerts and notificationsAlert channels
Accounts and licensing
Users and plansLicenses and add-onsOnline top-up and identity verification

JA4 / TLS fingerprint

About 6 minApplies to v2.3.1Updated 2026-11-02

JA4 is a fingerprint computed from the features of a client's TLS handshake. A tool or script that changes its IP or User-Agent usually keeps the same handshake features, so JA4 helps identify automated traffic that hides its identity. JA4 exists only for HTTPS requests and is computed by the node during the handshake.

Where JA4 shows up

  • Access log: a JA4 column, plus a "Create matcher from this JA4" entry that turns it into a reusable condition.
  • Attack logs: Security Center › Attack Logs can be searched by JA4, showing which attacks a fingerprint produced.
  • Node details: a read-only "JA4 Fingerprint" support item shows whether the node has the capability.

Where to use JA4

  • CC matchers and access-control conditions: choose the condition type "TLS fingerprint (JA4)"; "Request Header" can also be matched.
  • CC counting dimension: CC filtering can count by IP, by TLS fingerprint, or by IP + fingerprint.
  • Replay: a matcher's "Replay" runs it against the last 24 hours of access logs and shows how many requests it would match, so you see the impact before going live.
Caution Counting by TLS fingerprint alone (ja4) can only be paired with the log-only action. To enforce, use IP + fingerprint (ip_ja4), so that many normal users sharing one browser fingerprint are not blocked together.

Recommended workflow

  1. Find an abnormal request in the attack log and take its JA4 from the access log.
  2. Create a matcher and use Replay to confirm the matched range is reasonable.
  3. Run it log-only for a while; once you see no false positives, switch to blocking with the IP + fingerprint dimension.
Tip Mainstream browsers share fingerprints across huge numbers of legitimate users, so never block on JA4 alone; combine it with the IP dimension or other conditions.

See also CC protection and Lists and access control.