あなたのPlaywrightスクリプトがCloudflare(および修正方法)によってブロックされるのをキープする理由 - 説明Clawbrowserの記事カバー

なぜあなたのPlaywrightスクリプトはCloudflareによってブロックされたまま (そしてそれを修正する方法)

Clawbrowser TeamPlaywrightCloudflareアンチボットトラブルシューティング

Playwrightスクリプトが先週動作していた場合、Cloudflareのチャレンジページがヒットするか、HTTP 403を戻す error 1020 — 問題は、コードがほとんどない。 問題は、ブラウザがシグナルのスタックを介して自動化として認識しているということです。

このガイドでは、PlaywrightスクリプトがCloudflareによってブロックされる理由、具体的にCloudflareが読み込まれているもの、そして彼らが実際に生産している信頼性によってランクされている修正の4つのクラスについて説明します。 TL;DR:ページレベルのパッチは数週間あなたを購入します。 ブラウザバイナリレベルでの一貫性のあるアイデンティティは、唯一の耐久性のある修正です。

Playwright Triggers Cloudflareボット検出

Cloudflare は、デフォルトの Playwright-driven Chromium ブラウザが、Cloudflare のボット管理システムが自動化として認識するために訓練されているという一貫性のある一連の信号を放出するので、Playwright セッションをブロックします。ブロックはランダムでなく、レート制限だけでは適用されません。スクリプトのファーストインタラクションの前に起こるアイデンティティ分類に基づいています。

Cloudflare保護されたページのロードの最初の200ミリ秒は、コードが機能する前に実行される指紋と行動チェックのスタックを含みます。 時間を節約 page.goto() 解決します。, セッションは既に分類されています。.

なぜこれが時間をかけて悪化するのか

Cloudflareのボット管理は、検出モデルを継続的に更新します。 Cloudflareのボット管理文書つまり、システムでは、数百万のサイトを横断してトラフィックパターンで訓練された機械学習を使用しています。つまり、今日のステルスセットアップが発するシグネチャは良心的かもしれませんが、Cloudflareのモデルが更新されたため、翌月を発するシグネチャはフラグが付けられます。これは「動作を停止」がPlaywright + Cloudflareのデバッグスレッドで最も一般的なパターンです。

6つの信号CloudflareはPlaywrightから読みました

PlaywrightのCloudflareの問題を解決するには、Cloudflareが実際にチェックしているかを知る必要があります。 6つの高影響力信号があります。

1. は navigator.webdriver ログイン

最も基本的な信号。バニラPlaywright制御Chromiumセット navigator.webdriver = true. 検出システムは、最初のスクリプト実行でこれを読み込みます。ほとんどのステルスプラグインはこれを処理するが、パッチ自体が検出可能です。

2. TLS指紋(JA3/JA4)

Playwright のアンダーリングChromiumは TLS Client Hello を特定の暗号注文、拡張リスト、および楕円曲線セットで生成します。このフォームは、Cloudflare が既知のオートメーションクライアントの署名と一致できる JA3 または JA4 ハッシュです。 SalesforceのオープンソースJA3仕様 説明すると、TLS ハンドシェイク自体は、ユーザエージェントの指紋性独立性です。

3. HTTP/2フレームの発注

ブラウザがHTTP/2 SETTINGS、WINDOW_UPDATE、HEADERSフレームをChrome版内で一貫して送信する順番は、HTTP/2を別々に構築する自動化ライブラリとは異なります。 Cloudflareはこのレイヤーを読み込みます。

4. キャンバス、WebGLおよび可聴周波指紋

このページがCloudflareチャレンジJavaScriptを実行すると、テストコンテンツがキャンバスとWebGLのコンテキストにレンダリングされ、ピクセルデータを読み込みます。 株式のPlaywright Chromiumは、決定的、反復可能な読み取りバックを生成します。 数千回のセッションで表示される同じ読み戻りは、ボット信号です。

5. タイムゾーン × ロケール × IP 地コヒーレンス

ブラウザが提示する場合 en-US そして、 America/New_York IP は、フランクフルトのデータセンターを経由してルーティングする間、不一致は、近くのボット信号です。 Cloudflare は 3 つすべてにクロス環境を横断します。

6.ページの負荷の後の行動信号

チャレンジが指紋ステージを通過すると、行動チェックが始まります。マウスの動きのエントロピー、スクロールパターン、キーストロークのcadence。純粋なプログラマティックインタラクション(正しい座標でクリックする)が検出可能です。

修正の4つのクラス、ランク付け

Playwright + Cloudflareブロックの修正の4つの実際のカテゴリがあります。 それらは、作業を続ける期間に大きく異なります。

層 4 (より信頼できる): ユーザー エージェントおよび基本的な旗の操作

これは、ほとんどの開発者が試す最初のことです。カスタムユーザーエージェントを設定し、削除します。 --enable-automation フラグ、オーバーライド navigator.webdriver フォロー addInitScript. 上記6つの信号の1つを1つ1つにまとめます。

生産の寿命: 日〜週。Cloudflareの基本的な検出は、このレイヤーを過ぎます。

適切な場合: 実際のボット検出のないサイト、最も明らかなフラグを抑制する必要があるサイト。

層 3 (制限された信頼性): Stealth のプラグイン

ザ・オブ・ザ・ puppeteer-extra-stealth プラグインの家族, のようなライブラリを介してPlaywrightに移植 playwright-stealth. これらのパッチは、数十以上のナビゲーター特性、ノイズでキャンバスの読み戻しをオーバーライドし、ページレベルのJavaScriptインジェクションを介して上記のいくつかの信号を処理する。

生産の寿命: 週から数か月。パッチ自体はシグネチャ検出システムが特定でき、パッチはクロミウムの根本的なレンダリングパイプラインよりも異なる層で動作するので、キャンバスとWebGLの読み戻りはエッジケースでチャレンジしたときにブラウザを裏切る。

適切な場合: 適度に保護された場所、プロトタイプ、時折故障が許容される環境の軽いスクレイピング。

最終的に失敗するのはなぜか: ページレベルのパッチは既知のパターンです。 ヘッドレスブラウザの検出に関する研究, 自動化されたブラウザは、そのパッチのタイミングと動作によって、そのパッチが正常にプロパティ値のスプーフィを犯す場合でも識別することができます。

層2(変調信頼性): ステアスプラグイン+住宅プロキシ+慎重な動作

住宅プロキシを追加し、スクリプトを現実的なタイミングで計測する—変数遅延、マウスの移動曲線、ステルスプラグインスタックへのスクロールパターン。 IP-geo シグナルと行動シグナルをアドレスします。

生産の寿命: 月。 これは、ほとんどの自動化チームが合理的に保護されたサイトのために解決する場所です。

残りの故障モード: ローカル×タイムゾーン×IPコヒーレンスの問題。 ドイツの住宅プロキシを購入します。 ブラウザタイムゾーンを欧州/ベルリンに設定することを忘れないでください。 言語ヘッダーはまだ送信します en-US. ミスマッチはサイレントです。あなたのスクリプトはエラーではありませんが、Cloudflareのチャレンジレートは数週間に着実に上昇します。

層 1 (最も信頼できる):エンジンレベルのアイデンティティの一貫性

これは、JavaScript 注射を介してではなく、ブラウザのバイナリ自体に指紋表面がパッチが組み込まれているChromiumビルドを意味します。 これは、キャンバス、WebGL、オーディオ、ナビゲーター特性、画面、フォント、タイムゾーン、および locale が互いに一致するように生成され、プロキシ IP 地理を意味します。 そして、プロキシはプロファイルにバインドされるので、演算子が覚えているものよりも、アライメントは自動です。

これは、 Clawbrowser 提供。エンジンレベルのパッチングとは、検出システムがステルスそのものをパターンマッチさせることができないことを意味します。なぜなら、ステルスコードがページ上で実行されていないからです。つまり、値はブラウザがネイティブに報告するだけです。プロファイル・バウンド・プロキシは、失敗の locale/timezone/IP の不一致クラスを排除します。

Playwrightをローカルのanti-detectランタイムに切り替えて、ホストされているブラウザサービスに移動するかどうかを選択すると、 Clawbrowser対Browserbase比較 導入、プライバシー、およびコストのトレードオフのため。

生産の寿命: Indefinite、定期的なプロファイル再生。各プロファイルは、既知のステルスシグネチャを運ぶのではなくユニークであるため、アプローチは優雅に劣化します。

適しているとき: 信頼性が在庫Chromiumにとどまる利便性以上重要である生産のワークフロー。特に、オーケストレーションレイヤーは、ランタイムレイヤーが下塗りしたときに変更されていない作業を続けることができるため、AIエージェントのワークロード。

ステップバイステップの実装: 層 1 修正

在庫のPlaywright +ステルスプラグインのセットアップからエンジンレベルのランタイムに移動すると、4つのステップと1行のコードの変更が行われます。

ステップ1:既存のスタックがどのようなものなのかを特定する

何かを変更する前に、既存の設定を公共の指紋検査器に実行してください。 browserleaks.com ブラウザ または creepjs. どの表面がフラグが付けられているかに注意. ほとんどのステルスプラグインの設定は、少なくともキャンバスに失敗します, WebGL, TLS.

ステップ2:ランタイムをインストールする

Clawbrowserはスタンドアローンから始まります clawctl 公開中のアーカイブ clawbrowser/clawctl リリース:

# Download the matching clawctl-* archive for your OS/arch.
open https://github.com/clawbrowser/clawctl/releases/latest

アーカイブを抽出した後、マッチングエージェントの統合とセットをインストールします。 API キー:

clawctl install --agent claude-code --json
clawctl config set --api-key "clawbrowser_xxxxx"

ステップ3:指紋プロファイルで管理されたセッションを開始

clawbrowser start --session work -- --fingerprint=fp_us --country=US --connection-type=residential
clawbrowser endpoint --session work
# prints: http://127.0.0.1:9222

ザ・オブ・ザ・ --fingerprint, --country, と --connection-type フラグは、キャンバス、WebGL、ナビゲーター、画面、フォント、タイムゾーン、ロケール、and の境界住宅プロキシ IP が米国 ID とすべて整列するプロファイルを選択します。

ステップ4: Playwrightスクリプトで1行を変更

前へ:

browser = await p.chromium.launch(headless=False)

後:

endpoint = "http://127.0.0.1:9222"
browser = await p.chromium.connect_over_cdp(endpoint)
page = browser.contexts[0].pages[0]

すべての下流 — ロケータ、ナビゲーション、アサーション — 変更されていない動作します。 エージェントまたは自動化ロジックは非接触です。 接続パターンの変更のみ。

ステップ5:生産トラフィックを実行する前に確認

実行時間で出荷する検証ページを実行して、外向きの ID が期待しているものを確認します。

clawbrowser start --session work --verify -- https://example.com

これは、ほとんどのチームがスキップし、ほとんどのチームが後悔するステップです。 プロフィール生成がバグのサイレント・ロケール・ミスマッチのクラスをキャッチした後に検証します。

複数のセッション展開を含む完全なCDP統合パターンについては、 Clawbrowser ドキュメント.

期待される結果と利点

ステルスプラウジンベースのステルスからエンジンレベルのアイデンティティコヒーレンスに移動した後、生産で変化するメトリックは次のとおりです。

  • CAPTCHA率 は、Cloudflare保護されたサイト(ステルスプラグインと典型的な)から1桁のパーセンテージに30〜60%から低下し、残りのCAPTCHAは、アイデンティティ分類ではなく行動パターンによって正当にトリガーされています。
  • セッションの寿命 は、セッションが最初の数十回のアクション後にプログレッシブにフラグが付けられていないため、時間から日または週まで延長します。
  • メンテナンスオーバーヘッド パッチは、Cloudflareの検出モデルが進化するたびに更新する必要はありませんので、ドロップします。
  • 複数のアカウントワークフロー は、各セッションが同じステルスパッチ署名がすべてのセッション間で共有されるのではなく、一貫性のある明確なアイデンティティを持っているため、信頼性が高まります。

正直な洞窟: ブラウザは、CAPTCHAをユニバーサルにバイパスしません。 インタラクティブなチャレンジをすべての新しいセッションに発行するサイトは、今後も継続してやります。また、CAPTCHAがまだ処理する必要があるのは、ワークフローを調整したり、CAPTCHAソルバーを使ってワークフローを調整したり、ワークフローによっては人間が介在する介入が必要になるということです。

避けるべき一般的な間違い

エンジンレベルのパッチの上にCDPをオーバーライドするレイヤー

もし、ランタイムがバイナリレベルで指紋を処理する場合、PlaywrightのCDPコマンドを使用して、ナビゲータープロパティやキャンバスの動作をオーバーライドしないでください。 2つのレイヤーは、エンジンレベルのアプローチが特に回避するように設計された、検出可能な矛盾を解除、作成できます。

ミッドセッションプロキシ回転

アクティブなセッション中にプロキシを回転させる — ワークフローを介してIPを半分に切り替える — 実際の人間は30秒ごとにIPを変更しないため、強力なボット信号です。 1つのセッションあたりのプロキシを使用して、新しいアイデンティティのために、再生されたプロファイルで新しいセッションを開始します。

timezone/locale のアライメントを無視する

プロキシを手動で設定する場合は、ブラウザのタイムゾーン、ロケール、およびプロキシの地理で受け入れられた言語を手動で整列する必要があります。 これらのいずれかを忘れることは、最も一般的なサイレント障害モードです。 プロファイル・バウンド・プロキシ・システムは、バグのこのクラスを排除します。

同一の指紋を「異なる」のアイデンティティに再利用

同じキャンバスの指紋と同じWebGLのレンダラー文字列を持つ2つのセッションは、各ユーザーエージェントが提示しているかに関係なく、Cloudflareと同じアイデンティティです。 識別のアイデンティティは、異なる指紋プロファイルを必要とします。

ヘッドレスモードをヘッドフルに扱う

Headless Chrome には、追加の指紋が記載されています(異なるオーディオ出力、異なるデフォルトプラグインリスト、いくつかのケースで異なるレンダリングパス)。ローカルデバッグがヘッドフルモードにあり、生産デプロイはヘッドレスで、プロダクションアイデンティティを個別に検証します。

よくある質問

Playwrightスクリプトがローカルで機能するのはなぜですか?

最も一般的な理由は、環境の差です。ローカル開発は、住宅IP、リアルタイムゾーン、および開発者向け指紋を使用しています。生産は、データセンターやプロキシIPの背後にあるLinuxコンテナで実行され、潜在的な異なるタイムゾーン、ローカライズ、指紋表面を備えています。オーケストレーションコードは同じです。アイデンティティレイヤーは完全に異なります。この修正は、両方の環境で一貫したアイデンティティを生成するランタイムを使用しています。

住宅のプロキシだけでCloudflareの問題を解決しますか?

いいえ。住宅プロキシはIP-geo信号を固定しますが、キャンバス、WebGL、TLS、ナビゲーター、タイムゾーンの信号は変更されません。 それでも自動化パターンを放つと、Cloudflareはセッションを自動的に検出します。 修正は、IPだけでなく、すべての信号を一緒に対処する必要があります。

は、 playwright-stealth Cloudflare保護されたサイトには十分ですか?

軽く保護されたサイトについては、多くの場合、はい。 アクティブなCloudflare Bot Managementまたは適度に最新のエンタープライズボットソリューションを備えたサイトでは、通常、Cloudflareのモデル更新として、数か月にわたって信頼性が劣化します。 信頼性の問題が発生した生産ワークフローでは、プラグインレベルのステルスは既知の天井を持っています。

Cloudflareの「Verified Bot」プログラムについて、ボットを登録するだけですか?

ユースケースが修飾される場合(検索エンジンクローラー、監視サービス、アクセシビリティツール)、 Cloudflareの検証ボットプログラム 正当なパスと正しい回答です。ほとんどの自動化およびAIエージェントワークフローは、検証済みのボットステータスを修飾せず、統合された自動化は、独自のメリットに関する検出を処理する必要があります。

他のアンチボットベンダー(DataDome、Akamai、PerimeterX)に対してこのアプローチは機能しますか?

同じ原則が適用されます: バイナリレベルでのアイデンティティがより一貫性があり、簡単に検出システムは、セッションを自動化としてフラグを立てることができます。 特定のシグナルは、各ベンダーがそれぞれ異なるため、動作パターンに大きくDataDome、TLSのAkamai、PerimeterXをミックスで強調していますが、エンジンレベルのアイデンティティコヒーレンスは、それらすべてにわたって構造的回答です。

コンテンツ

パターンは一貫しています: Playwright +ストックChromiumは、検出可能な信号を生成し、ページレベルのパッチは、検出可能になる間、いくつかの信号に対処し、唯一の耐久性のある回答は、ブラウザのバイナリと一致するプロキシのエグレス内のアイデンティティ一貫性です。

スクリプトがCloudflareによってブロックされ続けると、最も高いレベルの変更は「Chromiumに盗まれた」から「Chromiumビルドを使用して、ステルスがデフォルトであり、プロキシはコヒーレントプロファイルにバインドされます」に移動します。 これは構造的修正であり、2年間動作するスクリプトの違いです。

Clawbrowser このレイヤーを正確に作成します。標準のCDPを話すので、既存のPlaywrightスクリプトは1行ずつ変更します。そして、下にあるブラウザは、プラグインベースのアプローチが一致できない指紋、プロキシ結合、アイデンティティコヒーレンスを処理します。

続きを読む

すべての記事 →