Cloudflareの「検証（Challenge）」は、WAFやBot対策の設定次第で表示され方が変わります。スクレイピングや自動化の現場では、原因の切り分けが遅れるほど、失敗リトライやIP枯渇、アカウント凍結リスクが増えがちです。この記事では、Cloudflareのチャレンジ種類を整理し、チャレンジ別に「まず何を確認し、どこを直すか」をフローでまとめます。 Cloudflareのチャレンジは、大きく「画面で止めるタイプ」と「ページ内に埋め込むタイプ」に分かれます。公式ドキュメントでは、WAFやBot Fight ModeなどがInterstitial Challenge Page（割り込み型のチャレンジページ）を発行し、TurnstileはEmbedded widget（埋め込みウィジェット）として動く、と整理されています。 押さえておきたい要点
まず全体像
種類の見分け方
画面で止まる
アクセス直後に「Checking your browser…」「Just a moment…」のような表示になり、目的ページへ進めない場合は、Interstitial Challenge Page（Managed Challengeなど）が疑わしいです。スクレイパーだとHTML本文がチャレンジページになり、以後の抽出が崩れます。
フォームで止まる
ページ閲覧はできるが、ログイン・会員登録・問い合わせ送信などの操作時にブロックされる場合はTurnstileが典型です。Turnstileはページの一部に埋め込まれ、トークンをサーバ側で検証（siteverify）してから処理が進む設計です。
即エラー画面
「1020 Access denied」などのエラーコードが表示される場合は、チャレンジではなくCloudflareのファイアウォール系ブロックの可能性が高いです（後述）。
① 「Managed Challenge」の対処
- 現象確認：同一URLで、通常ブラウザとヘッドレスで挙動が違うか（ヘッドレスだけループ等）。
- ネットワーク確認：VPN/プロキシを一度無効化して再現性を見る（チャレンジ失敗の典型要因）。
- IP整合性確認：チャレンジを受けたIPと解決リクエストのIPが一致しているか。IPローテを「チャレンジ完了まで固定」に切り替える。
- クライアント要因除外：拡張機能、User-Agent改変、Canvas/WebGL改変などを止める（自動化環境なら該当パッチを解除）。
- 最終手段：アクセス頻度・同時接続を下げる、待機時間を増やし、人間操作に近い挙動へ寄せる（レート制限やBot判定を避ける目的）。
注意
「チャレンジを別IPで解く」構成はループしやすいです。プロキシプールや分散実行（ワーカー数増）をしているときほど、IP固定の区間を作ってください。
②「Turnstile」の対処
利用者側の切り分け
Turnstileのチャレンジが失敗する場合、公式は次の観点での切り分けを推奨しています（ブラウザ更新、拡張機能無効、JavaScript有効、シークレットモード、別端末、VPN/プロキシ回避、別ネットワーク）。
スクレイピング時にTurnstileで止まるケース
Turnstileはフォーム送信やログインなどの操作時に挿入されることが多く、ヘッドレスブラウザでは以下のパターンで止まりがちです。
- ウィジェットが描画されない —
JavaScriptの実行が不完全、またはDOMの読み込み完了前にフォームを操作している - トークンは取得できたが送信後にブロックされる —
サーバ側でsiteverify検証が行われており、自動取得したトークンが拒否されている - SPA遷移後にチャレンジが出現する —
ページ遷移でウィジェットが再初期化され、以前のセッション状態がリセットされている
Turnstileの突破は現実的か
Managed Challengeと異なり、Turnstileはサイト運営者が意図的に埋め込む検証です。トークンはサーバ側（siteverify API）で検証されるため、クライアント側だけでの回避は困難です。
実務上の選択肢
- 公式APIの有無を確認する — Turnstileで保護されたデータは、多くの場合サイト側がAPI提供していることがある。スクレイピングより安定かつ規約上も安全
- ヘッドレスブラウザで正攻法を試す —
Puppeteer/Playwrightで実際にチャレンジを完了させる。ただしbot検知との併用で成功率は低い場合がある - 対象ページの再検討 —
Turnstileが入っているページを避け、同等データが取れる別のエンドポイントやページを探す
エラーコードで原因を特定する
Turnstileにはクライアント側エラーコードがあり、拡張機能の干渉やJavaScript実行エラーなど、失敗の原因を機械的に分類できます。ヘッドレスブラウザでTurnstileが動かない場合、コンソールログからエラーコードを確認することで原因の切り分けが早まります。
Cloudflareの「Error 1020: Access denied」は、Cloudflareのファイアウォールルールによってアクセスが拒否されたことを示します。チャレンジの失敗ではなく、明示的にブロックされている状態です。 注意 利用者側（第三者）からは、1020を「技術的に回避」するより、Ray ID付きで運営者へ連絡するのが最短です。自動化用途で第三者サイトに対して繰り返すと、IPやアカウント単位で状況が悪化しやすくなります。 ③ 「1020 Access denied」の対処
意味を確認
運営側の手順
比較早見表
現場での切り分けを速くするために、代表パターンを表にまとめます。
| 症状 | 疑う種類 | 最初に見る点 | 有効な対処 |
|---|---|---|---|
| アクセス直後に検証画面 | Interstitial/Managed | IPの一貫性、VPN/プロキシ | チャレンジ完了までIP固定、頻度低下 |
| ページは見れるが送信不可 | Turnstile | siteverify検証、失効 | expired/timeout処理、二重初期化回避 |
| 1020 Access denied | Firewallブロック | Ray ID、Security Events | ルール修正、IP許可 |
スクレイピング要点
再現性を作る
まずは「同一IP・同一UA・同一ヘッドレス設定」で再現する条件を固定します。条件が揺れると、Managed Challengeのループと、単なるネットワーク揺れが区別できません。
ログを残す
- 取得HTMLがチャレンジページに差し替わっていないか
- ステータスコード、リダイレクト回数
- レスポンス内にRay ID相当の識別子がある場合は保存
IP運用を見直す
Cloudflareのチャレンジは、発行IPと解決IPの不一致で失敗し得ます。プロキシローテは「ブロック時にだけ切り替える」より、「チャレンジ完了まで固定」へ寄せる方が安定します。
注意
サイトの利用規約・robots.txt・法的要件に反する自動化は避けてください。特にログインが必要な領域や個人データが絡む領域は、技術面より先に要件整理が必要です。
スクレイピングを安定化しませんか？
Cloudflare配下で失敗しやすい検証フローやIP運用を見直すと、収集停止やリトライ増を抑えられます。要件に合わせた構成設計・実装方針の整理はご相談ください。
まとめ
- Cloudflareの検証は「割り込み型」と「埋め込み型（Turnstile）」で対処が変わります。
- Managed Challengeは「発行IPと解決IPの一致」が安定運用の鍵です。
- Turnstileはトークン失効や二重初期化など、実装側の落とし穴が多いので、コールバックとsiteverify前提で設計します。
- 「1020 Access denied」はチャレンジ失敗ではなくFirewallブロックなので、Ray IDでSecurity Eventsを追うのが最短です。
