Cloudflare 文档：JA3/JA4 指纹 原文标题：JA3/JA4 fingerprint

{
 "ja4Signals": {
 "h2h3_ratio_1h": 0.98826485872269,
 "heuristic_ratio_1h": 7.288895722013e-05,
 "reqs_quantile_1h": 0.99905741214752,
 "uas_rank_1h": 901,
 "browser_ratio_1h": 0.93640440702438,
 "paths_rank_1h": 655,
 "reqs_rank_1h": 850,
 "cache_ratio_1h": 0.18918327987194,
 "ips_rank_1h": 662,
 "ips_quantile_1h": 0.99926590919495
 },
 "jaSignalsParsed": {
 "ratios": {
 "h2h3_ratio_1h": 0.98826485872269,
 "heuristic_ratio_1h": 7.288895722013e-05,
 "browser_ratio_1h": 0.93640440702438,
 "cache_ratio_1h": 0.18918327987194
 },
 "ranks": {
 "uas_rank_1h": 901,
 "paths_rank_1h": 655,
 "reqs_rank_1h": 850,
 "ips_rank_1h": 662
 },
 "quantiles": {
 "reqs_quantile_1h": 0.99905741214752,
 "ips_quantile_1h": 0.99926590919495
 }
 }
}

{
 "ja4Signals": {},
 "jaSignalsParsed": {
 "ratios": {},
 "ranks": {},
 "quantiles": {}
 }
}

Documentation Index

Fetch the complete documentation index at: https://developers.cloudflare.com/bots/llms.txt
Use this file to discover all available pages before exploring further.

JA3/JA4 fingerprint

Last updated May 6, 2026||View as Markdown|Agent setup

JA3 ↗︎ and JA4 ↗︎ fingerprints identify TLS clients based on how they initiate connections. Each client type (browser, bot, or application) has distinct connection characteristics, so the resulting fingerprint acts as a stable identifier across different destination IPs, ports, and certificates.

JA4 improves on JA3 by sorting ClientHello extensions, which reduces the number of unique fingerprints for modern browsers and makes grouping easier.

If you want to use JA4 fingerprints and Signals Intelligence, your Workers script should be able to handle missing fields when Bot Management isn't able to calculate or populate JA4 Signals (for example, non-TLS traffic or when Bot Management is skipped). For Orange-to-Orange (O2O) scenarios where Bot Management is in effect, JA4 Signals correspond to the eyeball (end-user) connection and are preserved through the O2O chain, including O2O zone requests and any corresponding subrequests.

• The possibility that the JA4 fingerprint could be missing.

• The possibility that the ja4Signals array could be missing (for example, if JA4 isn't available for the request).

• Results with NaN or Infinity values will be excluded from the array.

{
 "ja4Signals": {
 "h2h3_ratio_1h": 0.98826485872269,
 "heuristic_ratio_1h": 7.288895722013e-05,
 "reqs_quantile_1h": 0.99905741214752,
 "uas_rank_1h": 901,
 "browser_ratio_1h": 0.93640440702438,
 "paths_rank_1h": 655,
 "reqs_rank_1h": 850,
 "cache_ratio_1h": 0.18918327987194,
 "ips_rank_1h": 662,
 "ips_quantile_1h": 0.99926590919495
 },
 "jaSignalsParsed": {
 "ratios": {
 "h2h3_ratio_1h": 0.98826485872269,
 "heuristic_ratio_1h": 7.288895722013e-05,
 "browser_ratio_1h": 0.93640440702438,
 "cache_ratio_1h": 0.18918327987194
 },
 "ranks": {
 "uas_rank_1h": 901,
 "paths_rank_1h": 655,
 "reqs_rank_1h": 850,
 "ips_rank_1h": 662
 },
 "quantiles": {
 "reqs_quantile_1h": 0.99905741214752,
 "ips_quantile_1h": 0.99926590919495
 }
 }
}

When JA4 Signals are missing, the output appears as follows:

Missing JA4 signals outputjson

{
 "ja4Signals": {},
 "jaSignalsParsed": {
 "ratios": {},
 "ranks": {},
 "quantiles": {}
 }
}

The JA3 or JA4 fingerprint is an SSL/TLS-based identifier and can be null or empty in logs under specific circumstances:

• Since JA3 and JA4 are calculated during the TLS (SSL) handshake, they will not be present for non-encrypted HTTP traffic.

• The field may be empty when a Worker sends a request to a zone that is either internal to Cloudflare's network (for example, non-proxied/internal O2O) or to a third-party origin, or when a Worker is routing traffic to the target zone.

• The fingerprints may be absent when Bot Management itself is skipped for a request, as the feature is responsible for calculating and populating these values.

• With TLS Session Resumption ↗︎, once the initial TLS handshake is successfully completed, subsequent connections will be streamlined. This results in no further fingerprint calculation.

In Orange-to-Orange (O2O) scenarios where Bot Management is in effect, JA3/JA4 fingerprints are preserved through the O2O chain and represent the eyeball (end-user) connection. This includes requests on the O2O zone and any corresponding subrequests.

Analytics

To get more information about potential bot requests, use these JA3 and JA4 fingerprints in:

• Security Events and Security Analytics

• Analytics GraphQL API, specifically the HTTP Requests dataset

Actions

To adjust how your application responds to specific fingerprints, use them with:

Use cases

Block or allow certain traffic

A group of similar requests may share the same JA3 fingerprint. For this reason, JA3 may be useful in blocking an incoming threat. For example, if you notice that a bot attack is not caught by existing defenses, create a custom rule that blocks or challenges the JA3 used for the attack.

Alternatively, if existing defenses are blocking traffic that is actually legitimate, create a custom rule with the Skip action allowing the JA3 seen across good requests.

JA3 may also be useful if you want to immediately remedy false positives or false negatives with Bot Management.

Allow mobile traffic

Often, mobile application traffic will produce the same JA3 fingerprint across devices and users. This means you can identify your mobile application traffic by its JA3 fingerprint.

Use the JA3 fingerprint to allow traffic from your mobile application, but block or challenge remaining traffic.

Docs