Tony Wang7 分で読めますundetected-chromedriver・nodriver・Playwright-Stealth・Camoufox：4エンジン徹底比較
ChromiumFish、patchright、camoufox、zendriverを無料検出ツールと実在のCloudflareターゲットで比較。4つとも同じ結果——理由はそれぞれ違う。
「undetected-chromedriver vs. nodriver vs. Playwright-Stealth vs. Camoufox」を検索しているなら、あなたが本当に知りたいのは、ブラウザのステルスに対する4つの異なるエンジニアリング・アプローチのうちどれが実際に機能するのか、ということです。私たちはすでにそのうち3つを実在のアンチボット・ターゲットに対してベンチマークしました。今回は4つ目——このグループの中でアーキテクチャ的に最も異質なもの——を追加し、そのパターンが維持されるかどうかを確認しました。
ラウンド1：bot.sannysoft.com、4つのエンジンすべて
| エンジン | アプローチ | コアテスト | WebGL ベンダー/レンダラー |
|---|---|---|---|
| ChromiumFish | ネイティブC++/Blinkスプーフィング | 8/8合格 | FAIL |
| patchright | JSパッチ済みChromium | 8/8合格 | FAIL |
| camoufox | パッチ済みFirefox | 7/8合格（Chrome専用テストは対象外） | PASS |
| zendriver | CDP直接制御、永続セッション | 8/8合格 | FAIL |
最初のベンチと同じ結果で、それを裏づける4つ目のデータポイントが加わりました：エンジンがフィンガープリントをネイティブに偽装しようと、JSでパッチしようと、実在のChromeをCDPで直接操作しようと、コアのステルスチェックは同じ結果を返します。WebGLは依然としてChromium形の唯一の穴です——4つ中3つがそこで失敗し、Firefoxベースの例外だけが失敗しません。
今回私たちが見つけた唯一の本物のエンジンレベルの違いは、チェックリストにはまったく載っていないものでした。 ChromiumFish、patchright、camoufoxはそれぞれ偽装したWindowsのユーザーエージェントを提示します。zendriverはそんな手間をかけません——ありのまま、X11; Linux x86_64と報告します。これは明らかに劣っているわけではありません。正直なOS文字列は、フィンガープリントの残り部分（WebGLレンダラー、フォントリスト、navigator.platform）と一貫性を保ち続けなければならない要素が1つ減るということであり、申告したOSとそれらのいずれかとの不一致のほうが「これはLinuxだ」よりもはるかによくあるアンチボットの手がかりです。どちらの戦略をアンチボット・ベンダーが実際により重く評価しているかについてのデータは私たちにはありません——重要なのは、これらのエンジンが単に異なるスプーフィング機構を使っているだけでなく、ここで異なる賭けをしているという点を知っておくことです。
ラウンド2：同じ実在のターゲット、今度は4つ目のアーキテクチャで
| エンジン | nowsecure.nl（公開JSチャレンジ・デモ） | g2.com（実在のBot Management） |
|---|---|---|
| ChromiumFish | PASS | 403 |
| patchright | PASS | 403 |
| camoufox | PASS | 403 |
| zendriver | PASS | 403 |
完全な一致、両方向とも4対4です。すべてのエンジンが緩やかな公開デモを通過しました。すべてのエンジンが実在のBot Managementのターゲットで厳格な403で弾かれました——まったく同じ小さなCloudflareのブロックページ（<title>g2.com</title>、#cmsgチャレンジ挿入マーカー）で、バイト単位でまったく同じ形状であり、最初のベンチで他の3つのエンジンについて見られたものと一致します。
ここでじっくり考える価値があるのは次の点です。zendriverは他の3つと同じテーマのバリエーションではなく、構造的に異なるブラウザ制御の方法です——リクエストごとにHTTPサービスとして新規起動するのではなく、生のCDPを介した永続セッションです。もしエンジンのアーキテクチャが実在のアンチボット・ベンダーの判断に影響するのであれば、まさにこの種の違いが表面化するはずでした。しかし表面化しませんでした。（ここでは最初のベンチのプロキシ・ラウンドを再実行していません——データセンター・プロキシプールの結果についてはその記事を参照してください。これはどのエンジンが動かしていようと、このターゲットに当てはまります。）
この4つのエンジンの間で実際に異なる点
両方のベンチマークを重ねてみると、実際に本物である違いは「ステルス・ブラウザ」系のコンテンツが普段真っ先に取り上げるものではありません。
- camoufoxだけがWebGLをクリーンに通過します。ヘッドレスChromiumで動いていない唯一のエンジンだからです。
- zendriverはOSについて正直に申告します。他の3つはWindowsを偽装します。異なる賭けをしていますが、いずれの方向でも合格率に測定可能な違いはありません。
- zendriverのセッションモデルはアーキテクチャ的に異なります——リクエストごとの新規起動ではなく、長寿命の1つのブラウザです。これは大規模運用でのレイテンシとリソース使用に影響しますが、個々のリクエストが通過するかどうかには影響しません。
- 測定できたそれ以外のすべての軸——「ネイティブ vs. JSパッチ vs. CDP直接」というマーケティングの謳い文句が普段中心に据えるまさにその軸——は引き分けでした。 実在のCloudflare Bot Managementのターゲットを通過できるかどうかは、最初のベンチではIPレピュテーションで決まっており、アーキテクチャの異なる4つ目のエンジンも、まったく同じ壁にぶつかりました。
結論
undetected-chromedriverの後継、playwright-stealth的なJSパッチのアプローチ、パッチ済みFirefoxのアプローチのどれを選ぶか迷っているなら、今や2つのベンチマークから得られる正直な答えはこうです。ステルス性ではなく、メンテナンスの負荷とエコシステムとの相性で選んでください。私たちがテストした4つのアプローチ——ネイティブ・スプーフィング、JSパッチ、Firefoxパッチ、実在のブラウザのCDP直接制御——のどれ1つとして、実際にIPレピュテーションをチェックしているターゲットに対して事態を動かしませんでした。事態を動かすレバーは、この記事でも前回の記事でも、ブラウザの中にはまったく見つからなかったものです。
私たちがどうやってこれを行ったか（そして注意点）
zendriverには他の3つとは異なるベンチマーク手法が必要でした。 ChromiumFish、patchright、camoufoxはそれぞれシンプルなPOST /fetchのHTTPコントラクトを公開していますが、zendriverはホストヘッダーを書き換えるプロキシの背後で生のCDP WebSocketを公開しています。そのため私たちは、同じクラスタ内の別のPodからPlaywrightのconnect_over_cdpで操作し、テストごとに新しいブラウザ・コンテキストを取得しました（zendriver自体のブラウザ・プロセスは共有・永続的であるため、他の3つがデフォルトで得ている分離状態に合わせるためです）。
nodriver自体はテストしていません——現在、私たちのフリートではレプリカ数0にスケールされています。zendriverはここでは、その最も近いライブの同等品（同じコードベースの積極的にメンテナンスされているフォーク）として提示しているのであり、nodriverそのものとして提示しているわけではありません。
最初のベンチと同じ小標本の注意点がここにも当てはまります：無料の検出ツール1つ、ライブターゲット2つ（1つは緩やか、1つは厳格）、単発の逐次リクエスト。これはベンチマークであって負荷テストではなく、存在する「ネイティブ・スプーフィング」や「CDP直接制御」のすべての実装ではなく、4つの特定のエンジンを測定したものです。
4つのエンジンから自分で選ぶ手間を省く
Crawloraのフリートはこれらすべてのアプローチを1つのAPIの背後で稼働させ、ターゲットが現在ブロックしているエンジンを自動的に迂回します。月2,000クレジット無料、クレジットカード不要。
よくある質問
undetected-browserの自動化にはnodriverとzendriver、どちらが良いですか？
私たちのフリートでは、nodriver自体は現在レプリカ数0にスケールされています——実際に稼働しているのは、積極的にメンテナンスされているフォークのzendriverです。私たちのベンチでは、zendriverはステルス関連のテストすべてで他のエンジンと同点となり、実在のCloudflare Bot Managementのターゲットでも他の3つとまったく同じように厳格な403で弾かれました。したがって2つのフォークのどちらを選ぶかは、測定されたステルス性ではなく、メンテナンスの活発さとAPIの安定性で決まる可能性が高いです。
2026年時点でPlaywright-Stealthは依然としてCloudflareに対して有効ですか？
JSパッチ済みChromiumのアプローチ（私たちのベンチではpatchright、playwright-stealthと同じ発想）は、私たちが実施したすべての無料検出ツールのテストに合格しました——bot.sannysoft.comでコア8/8です。実在のCloudflare Bot Managementのターゲットに対しては厳格な403で弾かれ、これは完全に異なる他の3つのエンジンとまったく同じ割合でした。パッチ自体は機能しています。ただしそれは、実在のアンチボット導入環境が実際にチェックしている項目ではありません。
camoufoxはChromiumベースのステルス・ブラウザよりCloudflareに強いですか？
私たちのベンチにおける実在のターゲットに対しては、そうではありません——camoufoxもCloudflare Bot Managementのサイトで、一緒にテストした3つのChromiumベースのエンジンとまったく同じように厳格な403で弾かれました。camoufoxが実際に測定可能な違いを見せた点は、4つの中で唯一bot.sannysoft.comのWebGLチェックに合格したことです。GPUのないヘッドレスChromiumで動いていない唯一のエンジンだからです。
nodriverやzendriverのようなCDP直接制御のブラウザは、playwright-stealthのようなJSパッチ型ブラウザと挙動が異なりますか？
アーキテクチャ的には異なります——zendriver（CDP直接制御）は生のWebSocketの背後で1つの永続的なブラウザ・セッションを動かし、patchright（JSパッチ）はHTTPコントラクトの背後でリクエストごとに新しいブラウザを起動します。私たちのベンチにおける実在のアンチボット・ターゲットに対しては、このアーキテクチャの違いは結果を変えませんでした。両方とも同じCloudflare Bot Managementのサイトで、同じ割合で厳格な403に弾かれました。
なぜzendriverはWindowsを偽装せずLinuxのユーザーエージェントを使うのですか？
私たちのベンチにおける他の3つのエンジン（ChromiumFish、patchright、camoufoxはすべて偽装したWindowsのUAを提示します）とは異なり、zendriverは実際のLinux環境を正直に報告します。どちらのアプローチも、私たちがテストした実在のアンチボット・ターゲットに対する合格率を変えませんでしたが、正直なOS文字列には実用上の利点が1つあります。捏造した申告と一貫性を保ち続けなければならないフィンガープリント項目（WebGLレンダラー、フォントリスト、navigator.platform）が1つ減るということです。