あなたはすべてを正しく行ってきました。クリーンなレジデンシャルIP、本物のChromeのUser-Agent、信じられるヘッダー、適切なレート制限。それでも厳重に保護されたターゲットは即座にあなたをブロックし、時には実際のページのバイトを一つも送る前にそうします。IPを疑ってローテーションしたくなりますが、ローテーションは効果がなく、それこそが手がかりです。あなたは多くのスクレイパーが考えもしない層でフィンガープリントされています。それはHTTPクライアント自体、TLSハンドシェイクとHTTP/2接続であり、リクエストが読まれる前の段階です。
これはIPとも、アンチ検知ブラウザが管理するブラウザとデバイスのフィンガープリントとも別の、第三の識別層です。これを理解することが、簡単なサイトでは動くがハードなサイトでは動かないスクレイパーと、そうでないものを分けます。
三つの層、一つではない
サイトがあなたが本物のユーザーかどうかを判断する際、独立した三つの要素を見ています。
- ネットワーク層: あなたのIPアドレスとそのレピュテーション。データセンターIPやフラグ付きIPはここで失敗します。
- クライアント層: HTTPクライアントが接続を開く方法、そのTLSハンドシェイクとHTTP/2の動作。スクリプトライブラリは、完璧なIPからでもここで失敗します。
- デバイス層: ブラウザのフィンガープリント、canvas、フォント、
navigatorなど。自動化されたブラウザはここで失敗する可能性があります。
クリーンなレジデンシャルIPは第一の層を解決しますが、それ以外は何も解決しません。TLSハンドシェイクが「私はPythonです」と告知していれば、世界中のどんなIPを使っても人間らしく見せることはできません。これが、最も厳格なターゲットがページの読み込み前にあなたをブロックする理由です。彼らはクライアント層で接続を拒否し、IPが意味を持つ機会は一度も訪れません。
TLSフィンガープリント、すなわちJA3
すべてのHTTPS接続はTLSハンドシェイクから始まり、最初のメッセージであるClientHelloは驚くほど多くの情報を明らかにします。この中で、クライアントは対応する暗号スイートを特定の順序で列挙し、さらにTLS拡張、対応する楕円曲線、署名アルゴリズムなどを含めます。この組み合わせは接続を行うソフトウェアに特有であり、著しく安定しています。
Chromeは特徴的な一つのClientHelloを生成します。Firefoxは別のものを生成します。システムのOpenSSLを使用するPythonのrequestsは、どちらとも似ていないものを生成します。Goのnet/httpは独自のものを生成します。アンチボットベンダーはこれらの値をハッシュ化してコンパクトなフィンガープリントにします。よく知られた形式はJA3とその後継のJA4であり、本物のブラウザがどのように見えるかの情報を保持しています。あなたのClientHelloが明らかにスクリプトライブラリであってブラウザではないものにハッシュ化されると、リクエスト行やヘッダー、クッキーを送る前に、ハンドシェイクの時点でフラグが立てられます。
残酷な部分は、それが露呈させる矛盾です。あなたはUser-Agent: Chromeを設定していますが、あなたのTLSフィンガープリントはPython経由のOpenSSLだと告げています。本物のChromeはそのような組み合わせを決して生成しないため、この不一致は単に偽装が失敗したというだけでなく、何かが装っているという積極的な信号になります。User-Agentを何も送らなかった場合よりも、あなたは悪い状況に置かれることになります。
HTTP/2フィンガープリント
あなたのTLSフィンガープリントが説得力を持っていると仮定しましょう。その直後にもう一つの層があります。本物のブラウザはHTTP/2を話し、それをどのように話すかもフィンガープリントになります。HTTP/2接続が開かれるとき、クライアントは特定の値(ヘッダーテーブルサイズ、最大同時ストリーム数、初期ウィンドウサイズ)を持つSETTINGSフレームを送信し、特定のウィンドウ更新を告知し、擬似ヘッダー(:method、:authority、:scheme、:path)を特徴的な順序で並べます。ブラウザは認識可能なパターンでストリーム優先度情報まで送信します。
HTTPクライアントライブラリはこれらの詳細を露呈するような形で誤って処理するか、完全にHTTP/1.1にフォールバックしてしまいます。これは現代のサイトでは疑わしいこと自体です。そのため、スクレイパーがTLSチェックを通過しても、その一つ上の層で捕まる可能性があります。なぜなら、そのHTTP/2のSETTINGSやヘッダーの順序が本物のブラウザと一致しないからです。そして普通のHTTP/1.1では、ヘッダーの順序と大文字小文字がもう一つのフィンガープリントになります。ブラウザは一貫した順序でヘッダーを送信しますが、多くのライブラリはそれを再現しません。
ヘッダーを設定するだけでは解決しない理由
これがこれほど根強い理由は、その仕組みのどれも、あなたが設定できる値の中には存在しないからです。User-Agentを偽装し、Accept-Languageを追加し、ブラウザのヘッダーリストを正確にコピーしても、それでも捕まる可能性があります。なぜなら、フィンガープリントはリクエストに何を入れるかではなく、接続がどのように行われるかの特性だからです。ClientHelloの暗号順序、あなたのライブラリが発するHTTP/2のSETTINGS、ヘッダーがワイヤーに送られる順序は、あなたのコードではなく、あなたのTLSとHTTPスタックによって決定されます。JA3の不一致を、ヘッダーで解決することはできません。
ネットワーク層で本物のブラウザのように見せる方法
ブラウザ級のクライアントフィンガープリントを提示するには、二つの正当な方法があります。
本物のブラウザを使う。 Playwright、Puppeteer、Seleniumは本物のChromiumを駆動するため、そのTLSとHTTP/2のフィンガープリントは、定義上、本物のブラウザのものです。最も厳格に保護されたターゲットに対しては、これが最も堅牢な方法ですが、その代償としてワーカーごとにブラウザを実行する必要があります。
TLSを偽装するHTTPクライアントを使う。 軽量に保ちたい場合、ブラウザのClientHelloとHTTP/2設定を模倣しながら、シンプルなHTTP呼び出しとして機能することを専門とするクライアントのクラスが存在します。curl-impersonateとそのPythonバインディングであるcurl_cffi、tls-client、Goのutlsなどのツールを使えば、実際にブラウザを起動せずにChromeやFirefoxとしてフィンガープリントされるリクエストを送信できます。
from curl_cffi import requests
# Presents a real Chrome TLS + HTTP/2 fingerprint, not python-requests'.r = requests.get( "https://example.com", impersonate="chrome", proxies={"https": "http://customer-USER-country-us:PASS@p.shifter.io:443"},)print(r.status_code)この一つのimpersonate引数が、ChromeだというClientHelloとOpenSSLだというClientHelloの違いを生み出します。クリーンなレジデンシャルIPと組み合わせることで、ネットワーク層とクライアント層を同時にクリアします。それこそが、ハードなターゲットがチェックしている対象です。
すべての層で一貫性を保つ
貫かれているテーマは一貫性です。あなたのストーリーは三つの層すべてで一致していなければなりません。ChromeのUser-AgentにはChromeのTLSフィンガープリント、ChromeのHTTP/2設定、Chromeのヘッダー順序が必要であり、それらは地理的位置が一致するIPを通じて発信される必要があります。アンチボットシステムは、これらの信号の一致を、個々を単独で見るのではなく、ますます採点するようになっています。そのため、ライブラリのハンドシェイクにブラウザのUAがある、外国のIPに米国のペルソナがあるといった単一の矛盾は、いずれかの層がわずかにずれていることよりも大きな信号になります。これは、検知を引き起こすミスの背後にある一貫性の原則と同じものです。すべての層が同じストーリーを語らなければなりません。
クライアントフィンガープリントブロックの診断
クライアント層のブロックとIP層のブロックは、その振る舞いによって通常見分けることができます。厳格な保護で知られるサイトで即座にブロックされ、IPをローテーションしても何も変わらず、本物のブラウザに切り替えると突然うまくいく場合、それはIPの問題ではなくクライアントフィンガープリントのブロックです。逆に、普通のHTTPクライアントがほとんどの場合正常に動作し、一部のIPだけがチャレンジされる場合、それはIPレピュテーションに戻る問題を示しています。どの層が失敗したかを知ることで、どのレバーを引くべきかがわかります。IPとは全く関係のない問題に対してIPをローテーションするのではなく。これは、リクエストがタイムアウトする理由やサイレントブロックの検出を診断する際の「失敗を正しく読み取る」という規律と同じです。
結論
厳重に保護されたサイトは三つの層であなたを判断し、クリーンなIPはそのうちの一つにしか答えません。クライアント層、つまりあなたのTLSハンドシェイクとHTTP/2の動作は、リクエストが読まれる前にスクリプトライブラリをブロックし、ヘッダーの偽装をどれだけ行ってもそれを解決することはできません。なぜなら、フィンガープリントは接続がどのように行われるかにあるからです。ハードなターゲットを高い成功率でスクレイピングするには、本物のブラウザを駆動するか、TLSを偽装するクライアントを使用することで、ブラウザ級のクライアントフィンガープリントを提示し、それをヘッダーとIPの地理的位置と一貫させる必要があります。
クリーンなレジデンシャルIPは依然として必要です。それはレピュテーションを突破するための層ですが、最も厳しいサイトではそれだけでは十分ではありません。ネットワーク層での本物のブラウザフィンガープリントと組み合わせ、すべての信号を一致させることで、以前はページが読み込まれる前に発生していたブロックが起こらなくなります。GB単位の課金により、リクエストごとの課金に悩まされることなく、この組み合わせを自分自身の最も難しいターゲットに対して試すことができます。