スクレイピング時にCAPTCHAを回避する方法（信号を切る、解決しない）
CAPTCHAを解決することは遅く、費用がかかり、症状を治療するだけです。持続可能な解決策は、CAPTCHAを呼び出さないことです。トリガーとなる信号をクリーンにしてリスクスコアを下げましょう。
スクレイパーがCAPTCHAに遭遇したときの本能的な反応は、解決サービスに頼ることです。しかし、それは間違った本能です。CAPTCHAは突破すべき壁ではなく、すでに自動化されたと判断されたリスクスコアの可視的な出力です。解決することは遅く、解決ごとに費用がかかり、そのスコアを下げることはできません。そのため、次のリクエストも再び挑戦されます。スクレイピング時にCAPTCHAを回避する方法の持続可能な答えは、CAPTCHAをトリガーしないことです。スコアを赤に押し上げる信号をクリーンにしましょう。
なぜ解決することが負ける動きなのか
reCAPTCHA v2が実際にどのように機能するかを考えてみましょう。サイトは公開サイトキーを埋め込み、チャレンジを解決すると、サーバーが後で検証する隠されたg-recaptcha-responseフィールドに長いトークンを書き込みます。そのトークンは設計上使い捨てです - リプレイ保護のため - なので、一度解決して再利用することはできません。解決サービス（人間のファームやMLソルバー）は、チャレンジごとに新しいトークンを返します。つまり、スコアが高いままの場合、毎回お金を払い、数秒待たなければなりません。症状を自動化しただけで、原因を取り除いていません。
さらに微妙な罠もあります：チャレンジが表示されるのは、ページ所有者がそのルートで自動化されたトラフィックを望んでいないからです。文書化されたAPIが存在する場合は、それを使用してください。そうでない場合、実用的な目標は、リスクエンジンがエスカレートしない程度に普通の訪問者のように見えることです。それは完全に送信する信号に関することです。
信号1：IPの質が最大のレバー
最も強力な入力はリクエストの送信元です。データセンターのIP範囲はカタログ化され、事前にスコアリングされています。新しいリクエストが送信される前に、リスクスケールの半分まで上昇することがあります。住宅用IP - 実際の家庭接続 - ははるかに低い位置から始まります。これが、古典的なフィールドアドバイスが「住宅用IPから実行し、チャレンジが現れた瞬間に新しい出口に回転する」という理由です。住宅用プロキシプールは、90M+のIPにわたるリクエストごとの回転を自動化し、一つのアドレスから全てのジョブをスクレイプすることはありません。
どのプールも信頼する前に測定してください。当社の無料IP品質スコアチェッカーは、アンチボットエンジンが出口に割り当てる詐欺/評判スコアを示します。高い詐欺スコアを持つデータセンターIPは、CAPTCHAが発生するのを待っています。なぜ評判がほとんどのサイトでフィンガープリントを上回るのかの全体像を知りたい場合は、詐欺スコアが重要な理由に関する投稿をご覧ください。
import requests
# Detect a challenge in the response and rotate the exit instead of retrying
CHALLENGE_MARKERS = ("g-recaptcha", "hcaptcha", "/cdn-cgi/challenge", "captcha-delivery")
def looks_challenged(resp):
if resp.status_code in (403, 429, 503):
return True
body = resp.text[:20000].lower()
return any(m in body for m in CHALLENGE_MARKERS)
def fetch(url):
# rotating gateway hands out a new residential IP each request
proxy = "http://USER:PASS@rotating.quantumproxies.io:8000"
r = requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=20)
if looks_challenged(r):
return None # burn this exit, the gateway rotates on the next call
return r信号2：TLSフィンガープリントがあなたを暴露する
クリーンなIP上でも、TLSハンドシェイクがあなたを暴露します。PythonやGoのデフォルトスタックからの生のリクエストは、Chromeとは全く異なるJA3/JA4フィンガープリントを生成します。実際のブラウザは、特定の暗号順序、拡張機能、ALPN値を広告しますが、スクリプトライブラリはそれを再現しません。アンチボットエンジンはそのハンドシェイクをハッシュ化し、既知のボットの署名と一致させます。修正策は、TLS-模倣クライアントを介して、または実際のブラウザエンジンを実行して、本物のブラウザフィンガープリントを送信することです。JA3/JA4フィンガープリントがどのように機能するかでメカニズムをカバーしています。
信号3：ヘッダーの整合性
ヘッダーは互いに、そしてフィンガープリントと一致していなければなりません。Windows上のChrome 120を主張するリクエストが、対応するsec-ch-uaクライアントヒントを省略し、ヘッダーを間違った順序で送信し、モバイルUser-AgentをデスクトップTLSプロファイルと組み合わせると、簡単に矛盾します。User-Agentを設定するだけでなく、実際のブラウザが送信する完全な整合セットを送信し、模倣しているプラットフォームと一致させ続けてください。
# Coherent header set that matches a Chrome-on-Windows fingerprint
headers = {
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) "
"AppleWebKit/537.36 (KHTML, like Gecko) "
"Chrome/120.0.0.0 Safari/537.36",
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8",
"Accept-Language": "en-US,en;q=0.9",
"sec-ch-ua": '"Not_A Brand";v="8", "Chromium";v="120", "Google Chrome";v="120"',
"sec-ch-ua-platform": '"Windows"',
"Upgrade-Insecure-Requests": "1",
}
信号4：行動とペース
IPごとのリクエスト頻度は主要なレート信号です。一つのアドレスから1分間に60リクエストはボットと見なされますが、60のIPに分散された同じ60は60人と見なされます。速度を落とし、リクエスト間にジッターを追加し、プール全体にボリュームを分散させます。JavaScriptが多用されるターゲットでは、行動スコアリングもマウスの動き、スクロール、滞在時間を監視します。ヘッドレスブラウザを操作している場合、クリックを即座に発火させないでください。回転はIPベースのブロッキングを減らしますが、マシンガンのようなリクエストパターンを正当化するものではありません。完全なディシプリンは、当社のアンチバンチェックリストにあります。
信号5：セッションとクッキーの連続性
第五の、より静かな信号があります：連続性です。クッキー、リファラー、履歴がない状態で到着するリクエストは、どこからともなく現れたように見えます - これはまさに単純なボットが行うことです。実際のユーザーはセッションを蓄積します：ページに着地し、クッキーが設定され、クリックを通じてそれらを持ち運びます。セッション内でクッキーを持続させ、保護されたルートに冷たくディープリンクするのではなく、もっともらしいページを通じて入ります。そして、一貫したフローの間に一つのアイデンティティを保持します。ログイン中にIPを回転させることは逆効果です - それは連続性を破壊し、スコアを上げます - これがカートやログインのようなステートフルなステップのためにスティッキーセッションが存在する理由です。
チャレンジが避けられない場合
すべての訪問者をゲートするルート - ログインウォール、チェックアウト、積極的に保護された検索など - では、どんなに信号をクリーンにしてもチャレンジは取り除けません。ブラウザフィンガープリント、TLS模倣、クリーンプールを手作業で維持すること自体がプロジェクトになります。その時点で、実際のブラウザフィンガープリントを持ち、住宅用IPを回転させ、JavaScriptをオンデマンドでレンダリングするScraper APIに全スタックを任せるのがポイントです。URLを送信し、HTMLまたはJSONを受け取るだけで、チャレンジ処理も含まれます。自家製のソルバーファームよりも動く部品が少なく、成功率が高いです。
よくある質問
ウェブスクレイピング時にCAPTCHAを回避するにはどうすればいいですか？
それらをトリガーするリスクスコアを下げましょう。フラグが立てられたデータセンター範囲ではなく住宅用IPからスクレイプし、本物のブラウザTLSフィンガープリントと整合性のあるヘッダーを送信し、リクエストのペースを調整して多くのIPに分散させ、セッション内でクッキーを保持します。チャレンジが現れたら、焼かれたIPを再試行するのではなく、出口を回転させましょう。
CAPTCHAを解決するのと回避するのとではどちらが良いですか？
回避することです。解決はチャレンジごとに行われ、費用と時間がかかり、reCAPTCHAトークンは使い捨てなので、リスクスコアが高いままであれば、毎回再び支払うことになります。予防は原因を一度に修正します。どんなに信号がクリーンでもすべての訪問者にチャレンジを課す稀なルートのために解決を予約しましょう。
住宅用プロキシはCAPTCHAを止めますか？
最大のトリガーである悪いIPの評判を取り除きますが、それだけでは完全な修正にはなりません。PythonのデフォルトTLSフィンガープリントとマシンガンのようなリクエストレートを組み合わせた住宅用IPは、依然として挑戦されます。クリーンなIPをブラウザフィンガープリント、整合性のあるヘッダー、適切なペースと組み合わせてください。
住宅用IPでもCAPTCHAが出るのはなぜですか？
IPは一つの入力に過ぎないからです。TLS/JA3フィンガープリント、ヘッダーの整合性、リクエストレート、セッションクッキーの欠如がスコアに影響を与えます。一度フラグが立てられた住宅用出口も最近の履歴を持つことがあります。無料のIP品質ツールで出口を確認し、本物のブラウザフィンガープリントを送信し、リクエストレートを遅くする前にIPが問題だと決めつけないでください。
CAPTCHAを障害物として扱うのをやめましょう。それは現れる前に送信したすべてのものの読み出しです。IP、フィンガープリント、ヘッダー、ペースをクリーンにし、読み出しが緑のままであれば、ソルバーは不要です。