Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -111,3 +111,11 @@ JA3 may also be useful if you want to immediately remedy false positives or fals
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](/waf/custom-rules/use-cases/challenge-bad-bots/#adjust-for-mobile-traffic) from your mobile application, but block or challenge remaining traffic.

## Limitations

### Orange-to-orange (O2O) traffic

When traffic routes through an O2O setup — where one Cloudflare zone proxies requests to another — JA3 and JA4 fingerprints may be unavailable. Cloudflare sees only the inner Cloudflare-to-Cloudflare TLS session on the receiving zone, not the original client handshake, so no fingerprint can be derived.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"may be" or "is"?

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch — after checking the existing ja3-ja4-null partial on the live page, the correct behavior is that O2O traffic generally includes JA3/JA4 fingerprints; they're only absent when a Worker is used to route the O2O traffic. The limitation I added was an oversimplification that contradicted the existing docs. Closing this PR — no new section is needed here.


If you rely on JA3/JA4 for bot detection on zones that receive O2O traffic, use `cf.bot_management.verified_bot`, `cf.bot_management.score`, or other bot fields that do not depend on the TLS handshake.