Playwrightを使用してウェブスクレイピングを行っている開発者が、フル機能のChromiumインスタンスを起動し、本物のUser-Agentを設定し、人間のような遅延を挿入しているにもかかわらず、最初のリクエストが拒否されるという事態に直面しています。サーバーは、TLSフィンガープリントと呼ばれる手法を用いて、TLSハンドシェイク中にリクエストをブロックしています。

TLSフィンガープリントの解説

ブラウザがHTTPS接続を開くとき、ClientHelloメッセージを送信します。このパケットには、TLSバージョン、サポートされている暗号スイート、一連の拡張機能（楕円曲線、署名アルゴリズム）、およびその他のいくつかのフィールドがリストされています。この正確な組み合わせが、ネットワークスタックを一意に識別します。

研究者は、これらの生のフィールドをハッシュ化し、JA3（またはその新しい派生であるJA4）と呼ばれるコンパクトな識別子を作成します。本物のChromeブラウザは一つのハッシュを生成しますが、PythonのHTTPライブラリは別のハッシュを生成します。サーバー側のハッシュが主張されているUser-Agentと一致しない場合、そのリクエストはスクリプトによるものとしてフラグが立てられます。

なぜ標準的なPlaywrightブラウザが依然として検知されるのか

PlaywrightのデフォルトのChromiumビルドは、通常、正しいChromeのフィンガープリントを発行しますが、多くのスクレイパーは一貫性を損なう手順を追加してしまいます。

  1. リクエスト戦略の混在 – 開発者は、Playwrightに重いページをレンダリングさせる一方で、軽量なHTTPクライアントを使用して補助的なリソース（JSON、画像など）を取得させることがよくあります。これらの高速な呼び出しはChromeではなくライブラリのフィンガープリントを伴うため、サーバーは即座に不一致を検知します。
  2. TLS終端プロキシ – 一部のプロキシサービスは、TLSストリームを復号してトラフィックを検査または修正し、その後再暗号化します。サーバーは最終的にプロキシのフィンガープリントを見るため、非ブラウザクライアントとしてブロックされる可能性があります。
  3. その他のプロトコルレイヤー – アンチスクレイピングシステムは、HTTP/2の設定、ヘッダーの順序、およびIPレピュテーション（評判）も比較します。どのレイヤーであっても不一致があると、ブロックがトリガーされる可能性があります。

JA3からJA4へ：軍拡競争

JA3は、広く採用された最初のTLSフィンガープリントでした。現在、Chromeは起動するたびに拡張機能の順序をランダム化しているため、JA3ハッシュは実際のブラウザにとって不安定なものになっています。JA4は、ハッシュ化する前に拡張機能のリストをソートすることでこれを解決し、Chromeが順序をシャッフルした場合でも安定した識別子を提供します。JA4を採用している検知ツールは、静的なJA3ハッシュを単にコピーしているスクリプトクライアントと、実際のChromeインスタンスを確実に区別できます。

開発者が今日できること

サーバーを永遠に欺き続けることができる「魔法の文字列」は存在しません。信頼できるアプローチは、リクエストのあらゆるレイヤーが同じストーリーを語るようにすることです。

  • User-Agent、TLSハンドシェイク、HTTP/2設定、およびヘッダーの順序を、同じブラウザバージョンおよびOSに合わせる。
  • フルブラウザ自動化ツールと個別のHTTPクライアントを混在させるのをやめる。速度が重要な場合は、些細な呼び出しであってもすべてPlaywrightにネットワークコールを処理させる。
  • 接続を終端せずに**TLSを透過させる（pass TLS through）**プロキシを選択するか、元のTLSハンドシェイクを変更せずに転送するように構成する。
  • IPレピュテーションサービスを監視する。クリーンなIPプールを使用することで、過去の不正利用に基づくブロックの可能性を低減できる。

フィンガープリントの一貫性を無視することの代償

スクレイパーがハンドシェイク段階でブロックされると、ページロジックに到達することさえできないため、データは収集されず、JavaScriptの実行に時間も費やされません。大規模なデータ収集に依存している企業では、リトライループが回転するにつれてクラウドコンピューティングのコストが増大します。繰り返されるブロックは、同じネットワークからの他の正当なトラフィックに影響を与えるIPバンにつながることもあります。

反論：なぜサイトはTLSフィンガープリントを採用するのか

サイト所有者は、TLSフィンガープリントを正当な防御策と考えています。自動化されたスクレイピングは、サーバーに過負荷をかけたり、ペイウォールを回避したり、個人データを大規模に収集したりする可能性があります。TLSフィンガープリントが主張されているブラウザと一致するかを確認することで、サイトは実際のユーザーを損なうことなく、低レベルなボットの大部分をフィルタリングできます。この手法はCAPTCHAよりも侵入性が低く、ユーザーエクスペリエンスを維持できます。

今後の注目点

  • JA4の採用 – 今後数ヶ月の間に、より多くのセキュリティベンダーやCDNプロバイダーがJA4ベースの検知を導入することが予想されます。
  • ブラウザレベルのランダム化 – ChromeなどのブラウザはTLSパラメータを変化させ続ける可能性があり、フィンガープリントツールはトラフィックのタイミングやJavaScriptの実行パターンといった、より複雑なシグナルへと向かうでしょう。
  • プロキシ市場の反応 – ハンドシェイクを変更せずに維持したいスクレイピングコミュニティのニーズに応える、「TLS透過型（TLS-transparent）」ルーティングを謳うサービスが登場する可能性があります。

まとめ

Playwrightスクレイパーがページを読み込む前に拒否される場合、その原因はほぼ間違いなくTLSフィンガープリントの不一致にあります。これは単なる応急処置で解決できる問題ではなく、宣言されたブラウザプロファイルに合わせて、すべてのプロトコルレイヤーを厳密に整合させる必要があります。User-Agent、TLSハンドシェイク、HTTP/2設定、ヘッダーの順序、そしてプロキシの挙動にわたる一貫性を保つことこそが、現代のアンチスクレイピング防御策の検知を回避するための唯一の確実な方法です。