cf_bm cookie?Short answer: cf_bm is the cookie Cloudflare's Bot Management product sets to remember how it scored a client. It is a verdict, not a pass: a low score on cf_bm gets you more challenges, and no cookie value you can edit will raise it. It is separate from cf_clearance, which is issued only after a challenge has actually been passed.
The two are routinely confused, and the confusion wastes a lot of engineering time.
cf_bm | cf_clearance | |
|---|---|---|
| What it records | A score Cloudflare computed for the client | The fact that this client solved a challenge |
| Who can get it | Almost any visitor, including bots | Only after a challenge or JS check passes |
| Typical lifetime | About 30 minutes | Set by the zone's challenge passage setting |
| Effect | Changes which rules and challenges you meet | Skips the challenge while it lasts |
So: having cf_bm does not mean you are through. Not having it does not mean you are blocked. The cookie that actually decides access on a challenged path is cf_clearance — see that entry.
cf_bm is a signed blob validated at the edge against your connection. It was issued to a specific TLS fingerprint, IP range and user agent combination. Copy it to a client that looks different and the value is either ignored or treated as a mismatch — which is worse than not sending it at all, because a mismatched verdict cookie is itself a signal.
Because the lifetime is short and the score is re-evaluated, whatever keeps your score low will keep coming back. If you see periodic 403s or challenge pages at roughly half-hour intervals in a long crawl, that is not random: the verdict expires, Cloudflare re-scores, and your request pattern is what it scores. The two things that move the score most are request rate consistency and whether your TLS/HTTP2 fingerprint matches the browser you claim to be.
cf_bm was carrying.cf_clearance. If a path is challenged, the durable credential is cf_clearance; a Turnstile or Managed Challenge solution is how you get one. The Turnstile endpoint documents the token flow.The frequent mistake is exporting a whole cookie jar from a browser that passed a challenge and expecting it to work elsewhere. The jar usually contains cf_bm from an earlier visit under a different fingerprint; the edge reads that as a contradiction before it even looks at cf_clearance. Export the clearance cookie and the identity it was issued to, or neither.
Is cf_bm the same as cf_clearance? No, and the difference decides your architecture. cf_bm records Cloudflare's verdict about the client; cf_clearance records that the client passed a challenge. Only the second one skips the challenge.
Why does cf_bm expire so quickly? It is deliberately short-lived, around 30 minutes, so a verdict can be re-evaluated against current behaviour instead of being held forever by an old cookie.
Can I set cf_bm myself? No. It is signed and validated against the connection it was issued to. A value you invent is discarded, and a mismatched one is a stronger signal than sending nothing.