15種類のステルスブラウザエンジンをCloudflareでベンチマークした結果、問題はブラウザではなかった

私たちがテストしたすべてのステルスブラウザエンジン——JSパッチではなくC++/Blink層でネイティブにフィンガープリントを偽装するものも含めて——は、本物のアンチボットベンダーが登場した途端、まったく同じ割合でブロックされました。「やや劣る結果」ではありません。フィンガープリントがどれだけクリーンであっても、同一にブロックされたのです。私たちは本番環境でこうしたエンジンを15種類運用しており、「最良の」エンジンを選ぶことが、その周辺のマーケティングが示唆するほど重要なのかどうかを、実際の数値で検証することにしました。

「無料の検出ツールに合格する」が本当のテストではない理由

bot.sannysoft.comのような無料フィンガープリントチェッカーは、navigator.webdriver が設定されているか、window.chrome が存在するか、プラグインリストが空かといった、わかりやすい兆候だけを探します。今どき、使う価値のあるステルスエンジンならどれもこれらをクリアします——これは差別化要因ではなく、最低条件にすぎません。それらがチェックしないのは、実際に本物のアンチボットベンダーがリクエストを通すかどうかを決める要因、つまりリクエストがどこから来ているかです。そこで私たちは同じ3つのエンジンを、両方のテスト——簡単な方と、本当に重要な方——にかけてみました。

ラウンド1：ネイティブ偽装 vs JSパッチ、無料検出ツールにて

エンジン	コアテスト（webdriver、chrome、pluginsなど）	WebGL vendor/renderer
ChromiumFish（ネイティブフォーク）	8/8 合格	失敗 — WebGLコンテキストなし
patchright（JSパッチ適用済みChromium）	8/8 合格	失敗 — WebGLコンテキストなし
camoufox（パッチ適用済みFirefox）	7/8 合格 — Chrome固有のwindow.chromeチェックのみ失敗。Firefoxベースのブラウザには元々存在しない項目	合格

ステルス性を測るテストではほぼ完全に同点でした。唯一の実質的な差は、Chromiumベースの2エンジンがどちらもWebGL vendor/rendererチェックに失敗する点です——GPUのないヘッドレスChromeには報告すべき実際のWebGLコンテキストがなく、ネイティブ偽装であっても関係ありません——一方でcamoufoxのFirefoxエンジンはこれを問題なく通過します。これは本物の、測定可能なエンジンレベルの差です。ただし「ネイティブなフィンガープリント偽装」がもたらすはずだったものとは違います。

ラウンド2：同じ3エンジンを、プロキシなしで実際のCloudflareターゲットに投入

ここからが興味深く、単一のテスト対象だけでは誤解を招いていたはずのポイントです。私たちは3つすべてを、Cloudflareで保護された2つの異なるサイトに対し、クラスタのデータセンターIPから直接、プロキシなしで実行しました。

エンジン	nowsecure.nl（公開JSチャレンジデモ）	g2.com（実際のBot Management — 素のcurlに403）
ChromiumFish	合格	403
patchright	合格	403
camoufox	合格	403

すべてのエンジンが公開デモを問題なく通過しました——本物の成功コンテンツがレンダリングされ、チャレンジページは表示されませんでした。すべてのエンジンが実際のBot Managementターゲットで完全に403を返され、しかもラウンド1でどのエンジンのフィンガープリントがよりクリーンだったかに関わらず、まったく同じ割合でした。

**「Cloudflareを突破する」は単一の主張ではありません。**軽量なJSチャレンジのデモと実際のBot Management導入は、まったく異なる難易度であり、簡単な方だけをテストして「Cloudflareを突破した」と呼ぶブログ記事は、間違ったものを測定しています。実際に重要なターゲットに対しては、フィンガープリントの質は何ももたらしませんでした。

ラウンド3：プロキシプールで解決するのか

私たちはChromiumFishを自前のローテーティングプロキシプール経由にし、g2.comに対してさらに6回実行しました。（私たちの構成では、リクエストごとにプロキシを受け取るのはChromiumFishだけです。他の2つは、稼働中のサービスには設定されていない固定の環境変数からのみプロキシを読み込むため、このラウンドはChromiumFishのみ——このベンチマークの他の部分と同じスコープです。）

結果	試行数
完全な403（小さなブロックページ）	4 / 6
実際のG2ホームページのコンテンツが配信 — ただし403ステータス下	1 / 6
プロキシのホップ自体が失敗（接続断）	1 / 6

真ん中の行はよく考える価値があります。ある試行では、実際のG2ホームページが返されました——正しいタイトル、本物のコンテンツ、チャレンジのマーカーなし——にもかかわらず、HTTPステータスコードは403のままでした。実際のスクレイピング結果は、必ずしも明確な合格/不合格ではありません。サイトがコンテンツとブロック信号を同時に渡してくることもあります。私たちはこれを信頼できる成功としてはカウントしていません。同じプールからサンプリングした2つの出口IPは、オランダのホスティングASNと、hosting: true のフラグが立ったScaleway（フランス）のアドレスであることが判明しました——依然としてデータセンター・クラウドのインフラであり、住宅用ではありません。これは6月に類似のベンチマークが見つけたのと同じ性質のプロキシプールであり、単にプロバイダーが違うだけです。

規模を拡大したときに実際に通過・失敗を予測するもの

3つのラウンドを重ねてみると、どのステルスブラウザを選んだかとは無関係なパターンが浮かび上がります。

1. **フィンガープリント偽装は必要だが、おおむね互換性がある。**ネイティブとJSパッチのエンジンは、私たちが実施したあらゆるステルス特有のテストで同点でした。「より優れた」偽装エンジンを選んでも、得られたのはWebGLのチェックボックス1つ分で、実際のターゲットに対する通過率の上昇ではありませんでした。
2. **IPの評判こそが実際の関門である。**同じ3つのエンジンが、どのCloudflare導入にアクセスするかを変えただけで、3/3通過から3/3ブロックへと変わりました——コードは変わらず、エンジンも変わっていません。
3. **データセンター系プロキシプールは#2を解決しない。**ローテーティングするクラウドIPを経由しても、実際のBot Managementターゲットに対しては6回中4〜5回失敗しました。出口が依然としてクラウドホストであり、住宅用ではなかったからです。

スクレイピング環境を最適化しようとしているなら、成果を左右するレバーは「どのステルスブラウザか」ではありません。「誰がIPを提供しているか」です。（この主張を、アーキテクチャの異なる4つ目のエンジンでさらに検証しました——4つのステルスブラウザエンジン、1つの本物のテストを参照してください。）

15種類のエンジンを自前で運用する本当のコスト

私たちがこれら15種類を維持しているのは、カバレッジが重要であり、単一のエンジンがあらゆる場面で勝つわけではないからです——しかし、それぞれが独自の保守負担でもあります。ChromiumFishのようなネイティブフォークや、Cagebaseクラスの代替は、セキュリティパッチが出るたびにChromiumフォークをコンパイル・再コンパイルすることを意味します（ビルドごとに数時間、数十ギガバイトのディスク容量）——単なる pip install ではありません。patchrightのようなJSパッチ適用型エンジンは、アンチボットベンダーが検出スクリプトを更新するたびに再パッチが必要で、それは頻繁に起こります。こうした保守作業のどれも、実際にIPの評判をチェックしているターゲット——ラウンド2と3の結果から見ると、その大半がそうなのですが——に対して、意味のある通過率の向上をもたらしません。

結論

フィンガープリント偽装は、ネイティブであれJSパッチ経由であれ、最低条件にすぎません——簡単なチェックを突破するには必要ですが、実際のアンチボット導入を突破するには十分ではありません。7週間の間隔を空けた2回のベンチマークを通じて、同じ3つのエンジンは私たちが投げかけたあらゆるステルス特有のテストで同点となり、リクエストがクリーンなIPから来たかどうかによってのみ分かれました。あるベンダーの「最良のステルスブラウザ」という売り込みが、リクエストがどこから来ているかに触れていないなら、それは間違った問いに答えていることになります。

私たちがどうやってこれを行ったか（そして留意点）

インフラ: 3つのエンジンはすべて、私たちの本番Kubernetesフリート内で常時稼働するマイクロサービスとして動作しており、15エンジン全体で使われている同じ POST /fetch 契約の背後にあります。リクエストは単発かつ逐次でした——これはベンチマークであり、負荷テストではありません。

これは2026年6月22日に実施した社内ベンチマークの続報であり、古い数値を再利用するのではなく、この記事のために改めて実施し直しました。2回のベンチマークの間の7週間で変わった、指摘に値する点が2つあります。areyouheadlessの特定のテストルートが今は502を返すようになったこと（ドメイン自体は稼働していますが、その1つのパスが機能しなくなったため除外しました）と、CreepJSの信頼スコアパネルは、20秒の待機を経ても静的なHTMLスナップショットから復元できないことです——その結果は、私たちのフェッチしてシリアライズするというアプローチでは捕捉できない方法でレンダリングされるため、根拠を持って報告できない数値を出すよりは、除外することを選びました。両エンジンのプロキシ層も、その間に名称変更・再構成されていました。今回テストしたプールは、現行の稼働中の同等物です。

プロキシプールのサンプルは小さい（直接確認した出口2件、1つの難しいターゲットに対する6回の試行）——データセンター/クラウドというパターンをはっきり見て取るには十分ですが、プール全体の挙動を精密に特徴づけるには不十分です。

**フリートの15エンジンのうち、深くテストしたのはわずか3つです。**選んだ理由は、比較する価値のある2つの偽装アプローチ——ネイティブエンジンとJSパッチ——に、非Chromium系のベースラインを加えて代表させるためです。残り12は カバレッジのために存在しており、今回の比較には含まれていません。

**「実際のBot Managementターゲット」とは、素の curl に403を返すことが確認された1サイト（g2.com）を指します。**これは「JSチャレンジを超えて実際にチェックしているサイト」の妥当な代理であり、Cloudflareの製品ライン全体に関する主張ではありません。

15エンジンを自前でパッチする手間を省く

Crawloraが、ステルスブラウザ・フリート、プロキシローテーション、アンチボット対応を1つのAPIの裏側で運用・保守します。月2,000クレジット無料、カード不要。

Web Scraping APIを見る料金を見る