Tony Wang6 分で読めますフィンガープリント偽装、エンジンアーキテクチャ、タイムゾーンマッチングをテストしました。どれもCloudflareに単独では勝てませんでした。
3つの社内テストの結果、フィンガープリント偽装・ブラウザ構成・IPタイムゾーン整合性はいずれも単独では本物のアンチボットに勝てませんでした。
私たちは今、本物のアンチボット導入に勝てるレバーを見つけるために、3つの別々のテストを行ってきました。フィンガープリント偽装ではダメでした。ブラウザアーキテクチャでもダメでした。IP・タイムゾーンのマッチングという、特定のよく知られた「ベストプラクティス」ですら、単独で切り分けてテストするとダメでした。これはひとつのすっきりした話ではありません。正直な話です。そのどれか一つだけから間違った結論を導き出す前に、書き留めておく価値があります。
すでに単独では機能しないとわかっていること
このシリーズの最初の2つの記事は、「ステルスブラウザ」マーケティングが通常売り込む2つの要素が、本物のターゲットの判定を動かさないことを、実際の数値で示しました。
| テストしたシグナル | エンジン/構成の数 | g2.comに対する結果 |
|---|---|---|
| フィンガープリント偽装の方式（ネイティブC++/Blink 対 JSパッチ 対 パッチ済みFirefox） | 3エンジン | 3つとも完全に403、同一のブロックページ |
| ブラウザアーキテクチャ（リクエストごとに起動するHTTPサービス 対 永続的なCDPセッション） | 4エンジン | 4つとも完全に403、同一のブロックページ |
| データセンタープロキシプール、タイムゾーン一貫性なし | 1エンジン、6回試行 | 6回中4回が完全に403、6回中1回が判定不明、6回中1回が接続失敗 |
3つの異なる軸で、一貫した答えが出ました。どれ一つとして、単独では本物のBot Management導入がチェックしている対象ではないということです。
きれいに切り分けられていない一つの軸 — タイムゾーンの一貫性
スクレイピング界にはよく知られた言い伝えがあります。プロキシがアムステルダムから出ているなら、ブラウザの時計と言語設定もアムステルダムを示すべきで、そうでなければその不一致が手がかりになる、というものです。私たちは実際にこれを直接テストしました。このシリーズが始まる前の、より早い時期の社内ベンチ（2026年6月22日）です。専用インスタンスでtimezone="auto"を使い、プロキシの出口IPを実際のIANAタイムゾーンに解決し、ブラウザの時計をそれに合わせました。テスト対象は同じクラスの硬いCloudflareターゲットで、このシリーズを通じて使ってきたのと同種のデータセンタープロキシプール経由です。
タイムゾーンの一貫性は何も変えませんでした。 有効にした場合と無効にした場合とで、通過率は同じでした。
この結果には、フィンガープリントとアーキテクチャのテストには不要だった留意点が必要です。「タイムゾーンの一貫性は重要ではない」ということと、「データセンタープロキシのIPレピュテーションがすでに悪すぎて、下流の何をしても助けにならなかった」ということを、私たちはきれいに切り分けられません。 よく知られたアンチボットベンダーは、時計とIPが一致しているかだけをチェックしているわけではなく、そのIPがこれまでにデータセンターをホストしたことがあるかもチェックしています。2つ目の質問の答えが「はい」であれば、1つ目の質問はそもそも評価されないかもしれません。これはまさに、結論を出すためにクリーンなレジデンシャルIPが必要な種類のテストであり、私たちはまだそのバージョンを実施していません。
一貫性が実際に重要だった場所 — スタックの別の部分
「一貫性」が私たちにとって本当に効果を発揮した場所について、正確を期す価値があります。それはブラウザ群ではなく、その下のネットワーク層だからです。私たちの送信側HTTPクライアントは、どのブラウザエンジンが関与しているかとは無関係に、実際のChromeブラウザに一致するようTLSハンドシェイク（JA3/JA4フィンガープリント）とHTTP/2のSETTINGSフレーム（Akamaiフィンガープリント）を制御しています。ある時点で、私たちの公開HTTP専用スクレイピング層はChrome 133のJA4フィンガープリントを提示しながら、文字通りのユーザーエージェント文字列req/v3を送信していました。 個々のシグナルはそれぞれ単体では問題なかったのですが、両者が互いに一致していませんでした。これは厳密な意味での一貫性の失敗です。偽装が欠けていたのではなく、食い違う偽装があったということです。私たちはこれを発見し、修正し、デプロイしました。実際に出荷できる本物の改善です。
これは「これはCloudflareに勝てるか」とは根本的に別の問いであり、私たちはそれ単独で勝てると主張しているわけではありません。エンジンとアーキテクチャをテストしたのと同じように、これをBot Managementターゲットに対して単独でテストしたわけではないからです。この事例が示しているのは、一般原則——検出器は欠落したシグナルを必要とせず、他のシグナルと矛盾するシグナルを捕まえることができる——が、実際にエンドツーエンドで検証できたシステムの一部で成り立っていたということです。これは、硬いブラウザターゲットに対する完全なIP＋タイムゾーン＋挙動の一貫性について現時点で言えることよりも、多くを語っています。
これを本当に決着させるために必要なこと
3つのテストが証明「していない」ことについて正直に言うと、私たちはまだレジデンシャルIP経由でブラウザ群のリクエストを実行し、地理情報、タイムゾーン、TLS/JA4、言語設定、そして単発の冷たいリクエストではなく現実的なナビゲーションパターンといった、すべての一貫性シグナルを同時に揃えたテストを行っていません。このシリーズで使ったプロキシプールはすべて、データセンターまたはクラウドホスティングでした（6月はDigitalOcean、Oracle、Hetzner、Alibaba、AEZA、Cogento、8月はオランダのホスティングASNとScaleway）。これが「単独では機能しないいくつかの要素を除外できた」ことと「何が機能するかがわかった」ことの間のギャップです。
結論
エンジンの選択、アーキテクチャ、そして単独でテストした特定の一貫性シグナルを通じて、私たちが測定した中で本物のアンチボット導入に単独で勝てるものはありませんでした。これは「何も機能しない」ということとは違います。私たちがテストしてきたベンダーが、単一のトリックよりもっと集約的な何かを評価している証拠であり、正直な次のステップはより良いブラウザではなく、より良いIPだという証拠です。私たちはまだそのテストを実施していません。実施したときには、このシリーズの4本目の記事になります。最初の3本の書き直しではありません。
留意点
この記事は、このシリーズより前に実施された結果（タイムゾーンのテスト）を報告しており、この記事のために新たに再実施したものではありません。上記で明示的にフラグを立て、交絡因子（データセンターIPレピュテーションが完全な説明である可能性）もごまかさずに明記しています。
TLS/JA4の一貫性修正は本物で、実際に出荷済みですが、このシリーズが使っている特定の硬いターゲット（g2.com）に対してはテストしていません。 私たちはこれを一般原則の証拠として引用しているのであり、他のデータと同じ表の4つ目のデータポイントとして提示しているわけではありません。
「単独では何も機能しない」というのは、私たちが切り分けたシグナルについての主張であり、網羅的なリストではありません。 挙動シグナル（マウスの動き、アクション間のタイミング、スクロールパターン）は、このシリーズでは一切テストしていません。
シグナルの切り分けを自分でやる手間を省く
Crawloraのブラウザ群は、エンジン・プロキシ・フィンガープリントの一貫性を1つのAPIの背後で組み合わせているので、変数を1つずつテストする必要はありません。月2,000クレジット無料、クレジットカード不要です。
よくある質問
プロキシのタイムゾーンをブラウザの時計に合わせると、Cloudflareに勝てますか？
データセンタープロキシプール経由で硬いCloudflareクラスのターゲットに対して行った社内テストでは、単独では勝てませんでした。タイムゾーンの一貫性を有効にしても無効にしても通過率は同じでした。重要な留意点として、そのテストは「タイムゾーンの一貫性は重要ではない」ということと「データセンターIPのレピュテーションがすでに悪すぎて下流の何も助けにならなかった」ということを完全には切り分けられません。結論を出すにはレジデンシャルIPが必要ですが、まだテストしていません。
フィンガープリント偽装やタイムゾーンマッチングで勝てないなら、実際に本物のアンチボット導入に勝つものは何ですか？
エンジン/フィンガープリントの選択、ブラウザアーキテクチャ、IPタイムゾーンの一貫性という3つの独立したテストのいずれも、本物のCloudflare Bot Managementターゲットに対して単独では判定を動かしませんでした。残るまだテストしていない変数はIPレピュテーションそのものです。このシリーズで使ったプロキシプールはすべてデータセンターまたはクラウドホスティングで、レジデンシャルではありませんでした。それが実際に決着をつけるテストです。
Webスクレイピングにおける「フィンガープリントの一貫性」とは何を意味しますか？
ターゲットがチェックできるすべてのシグナル——TLS/JA4ハンドシェイク、HTTP/2フィンガープリント、ユーザーエージェント、WebGLレンダラー、タイムゾーン、IPジオロケーション——が互いに一致していることを意味し、単一のシグナルだけが個別に説得力を持つということではありません。私たちは自分たちのスタックで実例を見つけました。ChromeのTLSフィンガープリントを提示しながら、文字通りのユーザーエージェント「req/v3」を送信していたHTTPクライアントです。個々の要素はそれぞれ単体では問題ありませんでしたが、両者は一致しておらず、まさに検出器が見つけるように作られている種類の不一致でした。
アンチボットシステムに対するスクレイピングの成功を決める主な要因は、ステルスブラウザエンジンの選択ですか？
私たちが測定した限りでは違います。過去2回のベンチマーク（3エンジン、次に4エンジン。ネイティブのフィンガープリント偽装、JSパッチ、Firefoxベースのパッチ、CDP直接制御にまたがる）を通じて、すべてのエンジンが無料検出ツールを通過し、すべてのエンジンが同じ本物のCloudflare Bot Managementターゲットに同じ割合で完全に403されました。エンジンの選択はカバレッジと保守負担において重要でしたが、この特定のクラスのターゲットに勝つことにおいては重要ではありませんでした。