cf_clearance クッキーとは

最終確認 2026年11月10日 · 約7分

結論から: cf_clearance は Cloudflare が「あなたはボットではない」と判断したあとにブラウザへ付けるクッキーです。解くトークンではなく、Cloudflare のエッジが発行する領収書です。通したチャレンジが刻まれ、IP アドレスと User-Agent に紐づき、限られた時間だけ有効です（既定 30 分）。その後の失敗は、ほぼこの 3 つのどれかが崩れた結果です。

どこから来るのか

このクッキーは、3 種類のチャレンジのいずれかが完了したあとにだけ現れます。

• JS チャレンジ ― 「ブラウザを確認しています」のインタースティシャル。ページ内で小さな JavaScript の計算を行い、それが終わるとエッジが clearance を渡します。
• Managed Challenge ― Cloudflare がリクエストごとに JS・目に見える CAPTCHA・何もしない、を選びます。どれが走ったかはクライアント側からは分かりません。
• Turnstile ウィジェット ― ウィジェットが返すトークンは clearance クッキーではありません。ウィジェットのトークンはサーバ側検証のために自分のオリジンへ送るもので、cf_clearance は同じリクエストの流れの中で Cloudflare のエッジが別に付けます。

この区別が効きます。Turnstile のトークンを買ってヘッダに貼り、「なぜまだチャレンジページなのか」と悩む例は定番です。トークンが答えるのは「人間がウィジェットを解いた」で、クッキーが答えるのは「この接続がチャレンジを完了した」です。

中身と紐づけ先

値は 40〜60 文字程度の不透明な文字列に、ドット区切りの接尾辞が付いた形で、署名されています。Cloudflare は形式を公開していませんが、実務上の含意は内部構造に依存しません。チャレンジを実行せずにクライアント側で作ることはできず、マシンを移すと死にます。

混同されやすい 3 つのクッキー

• __cf_bm ― ボット管理のテレメトリ用で、clearance ではありません。日常的に付き、何も証明しません。
• cf_chl_2 / cf_chl_prog ― 実行中のチャレンジの一時状態。これが見えているなら、まだ通っていません。
• cf_clearance ― 「エッジを越えた」を意味する唯一のものです。

コードでの形

実ブラウザで 1 回通し、そのジャーとネットワーク同一性を保つ最小形です。3 つを 1 組として扱うのが要点です。

ctx = browser.new_context(proxy=PROXY)      # 出口は固定
page = ctx.new_page()
page.goto(url)                               # ここでチャレンジが走る
jar = await ctx.cookies()                    # cf_clearance が入る
# 以降の直接 HTTP 呼び出しも、同じ出口・同じ UA で行う。
# 期限が来たら、クッキー単体ではなく 3 点セットごと作り直す。

実務で再利用が失敗する 4 つの型

• クッキーを書き出したあと、別のプロキシからリクエストを出す ― IP の紐づけで死にます。
• Chrome から書き出したクッキーを、Python の requests のヘッダ一式で再生する ― TLS フィンガープリントで死にます。
• Redis に 24 時間の TTL でキャッシュする ― 30 分で死んでいるのに、コードは送り続けます。
• 並列ワーカーで共有する ― 最初の 2 本は通り、残りはクレデンシャルスタッフィングのように見えます。

直すのは解決器の性能ではなくアーキテクチャです。1 セッションを 1 つの出口 IP、1 つのフィンガープリント、1 つのクッキーに固定し、期限が来たら 3 点セットごと更新します。

意図的に取得する 3 つの道

1. 実ブラウザを動かす。 使うのと同じマシンで Playwright か Selenium を走らせ、1 回チャレンジを通し、ジャーを書き出します。以降は同じ IP と同じ User-Agent を保ちます。対話式（Turnstile）だと無人では通りません。
2. 解決サービスを使う。 スクリプト処理なら、サイトキーと URL を渡すと cf_clearance を返す API が通常の経路です。SolveHub は Cloudflare のインタースティシャルと Turnstile のタスクに 1 つの REST エンドポイント を用意し、完了タスク単位で課金します。どのサービスでも、返ってきたクッキーが実際のリクエストを出すのと同じプロキシ出口と対になっているかを確認してください。
3. そもそも要らなくする。 オリジンのサイトマップ、RSS、API、提携データフィードに届くなら、チャレンジは現れません。最も安く、最も検討されない選択肢です。

よくある質問

別のサブドメインでも cf_clearance は通りますか。 通りません。clearance はホスト名とゾーン単位です。

ブラウザなしで生成できますか。 計算ではできません。チャレンジを完了するしかなく、そのためには JS エンジンか、それを代わりに走らせるサービスが必要です。

有効に見えるクッキーなのに 403 が返るのはなぜですか。 発行時と使用時で IP か User-Agent が動いているのが普通です。解決器を疑う前に、両側でその 2 つをログに取ってください。

cf_clearance の寿命は変えられますか。 サイト側の設定であり、クライアントからは変えられません。既定は 30 分ですが、サイトごとに違い、セッション限定のこともあります。

__cf_bm があれば通りますか。 いいえ。__cf_bm は日常的に付くテレメトリ用で、エッジを越えた証明にはなりません。