なぜあなたのオートメーションはトリガリングCAPTCHAを保ちます:7信号の診察道具

自動化スクリプトが突然CAPTCHAの課題をトリガーし始めると、ステルスライブラリが最後に試してみなかったこと、希望を問わないこと、という試みが始まります。そのアプローチは、6か月かけて5つの異なるステルスプラグインを通してサイクリングを終わらせ、実際に変化したことをまだ知らずにすることです。

より良いアプローチは、診断です: 7 つの信号の現在、あなたのセッションをフラグを立てているか、その信号を修正し、出荷します。このガイドは、それらを量る注文検出システムで7つの信号を歩きます - ほとんど同様に、最初に - 分離で各テスト方法を示しています。目標は、生産 CAPTCHA レート スパイク時に 15 分で実行できるチェックリストを与えることです。

なぜ検出システムの問題CAPTCHAチャレンジ

CAPTCHAチャレンジは、原因ではなく、出力です。原因は、検出システム(Cloudflare Bot Management、DataDome、Akamai、hCaptchaのリスクエンジン、reCAPTCHA Enterprise、またはベンダー固有のスタック)がセッションの信号ベクトルを読み取り、リスクスコアが閾値を渡したことを決定したことです。 CAPTCHAは、単一のルールに基づいて決定的ではなく、自信に基づいて、積極的に発行されます。

2つの影響:

1. 同じコードは月曜日に渡って、金曜日に失敗することができます モデルは、あなたのステルスシグネチャを使用して、または別のフリートがフラグが付けられているので、モデルが進化したためです。
2. 2つがオフの場合、1つの信号を固定することは十分ではありません。 検出システムは、組み合わせて信号を量ります。 フラグ付きIPを備えたきれいな指紋は、まだトリガーされます。 フラグ付き指紋付きのきれいなIPは、まだトリガーされます。

診断アプローチは順次です: どの信号があなたに対して現在最も重くされているかを識別し、それらを最初に修正し、再検証します。 下の信号は、公共のアンチボット研究で観察できる体重パターンに基づいて、リスクスコアへの典型的な貢献によって発注され、生産トラブルシューティングで最も一般的に報告された故障モード。

チェックする7つの信号、順序で

信号1:局部×タイムゾーン×IP地理誤差

これは、最も一般的なサイレント障害であり、検証する最も簡単です。 検出システムは3つの値を交差する:

• ブラウザの Accept-Language ヘッダーとヘッダー navigator.languages
• ブラウザの報告されたタイムゾーン()Intl.DateTimeFormat().resolvedOptions().timeZone)
• 接続のIP地理(データセンター、住宅、国、地域)

ベルリンの実ユーザー de-DE または en-DE, Europe/Berlin, ドイツのIP. フランクフルトの住宅のプロキシ提示を通した米国の英国のChrome en-US, America/New_York, と ドイツの IP — 特に探している検出システムの一貫性の失敗.

確認方法:

自動ブラウザを開き、検証ページをご覧ください browserleaks.com/ip そして、 browserleaks.com/javascript. IP 位置、タイムゾーン、言語の 3 つの値を比較します。 一貫性のある地理を 1 つ記述する必要があります。

修正方法:

プロキシと指紋を別々に設定している場合は、毎回3つすべてを手動で整列する必要があります。 構造的な修正は、プロファイル・バウンド・プロキシ・ルーティングです。プロキシがプロビジョニング時に指紋を束ねるランタイムなので、地理は自動的に一貫性を保ちます。 参照 ブラウザのランタイムガイド このレイヤーが重要な理由

信号 2: キャンバス、WebGL、および音声指紋再使用

これは、個々のセッションがきれいに見える場合でも、複数のアカウントのフリートを破壊する失敗だから、信号 #2です。同じマシン上の2つのセッションは、同じキャンバスの読み戻し、同じWebGLレンダラー文字列、および同一のAudioContext出力を生成します。検出システムには、「同じキャンバスハッシュと回転されたユーザーエージェントを持つ1,000セッション」は、多くのような見ようとしている1つのアイデンティティです。

確認方法:

ログイン creepjs 2つのセッションで(またはオープンソースの指紋検査官)を分離し、キャンバス、WebGL、およびオーディオハッシュを比較します。 2つのセッションが同じハッシュを生成した場合は、フリートは指紋再利用の問題を持っています。

修正方法:

各セッションは、エンジンレベルで生成された、異なる内部に一貫性のある指紋プロファイルを必要とします。 ページレベルのパッチ(ステルスプラグイン)は、キャンバスの読み戻りにノイズを追加できますが、通常はスケールで完全に異なる、一貫性のあるプロファイルを生成することはできません。 どのサーフェスの問題が私たちの中にある完全な在庫 ブラウザの指紋ガイド.

信号3: TLS/JA3/JA4指紋

これは、アプリケーションコードの下に動作するので、信号#3です。 TLS Client Helloは、HTTPS接続の開始時に送信される指紋の取れた形状を持っています。暗号注文、拡張リスト、サポートされている曲線 — JA3またはJA4ハッシュを生成します。異なるChromiumバージョンは異なるハッシュを生成します。 TLSをビルドする自動化ライブラリは、(Chromiumを通過するよりもむしろ)実際のブラウザに一致しないハッシュを生成します。

確認方法:

アクセス tls.peet.ws お使いの自動ブラウザから. このページは、あなたの接続のためにJA3とJA4ハッシュを返します. 同じOS上のバニラChromeのJA3/JA4と比較して、彼らは一致する必要があります. あなたのオートメーションライブラリは、独自のハッシュを生成している場合, これは、失敗です.

修正方法:

ブラウザのランタイムを使用して、別のHTTPクライアントではなく、Chromium TLSスタックを根本的に使用してください。 これは、ブラウザを迂回するHTTP /スクレイピングライブラリを使用している場合に最も関連性があります。 CDPによるフルブラウザベースの自動化は通常、ChromiumのネイティブTLS指紋を正しく継承します。

信号4: navigator.webdriver および他のオートメーションの旗

これは、最も基本的かつ最も一般的に対処されているため、シグナル#4です。しかし、patches自身が検出可能なものもあります。 デフォルトのPlaywright/Puppeteer Chromiumセット navigator.webdriver = true. Stealth プラグインはそれを上書きします false. 洗練された検出システムは、オーバーライドのmannerを読み取り始めています(定義されていない構成可能で、プロトタイプチェーンなど)、信号自体として。

確認方法:

自動ブラウザコンソールで、以下を実行します。

console.log(navigator.webdriver);
console.log(Object.getOwnPropertyDescriptor(navigator, 'webdriver'));

まずは、 false (または) undefined 実際のブラウザでは、2つ目は実際のブラウザの記述子パターンと一致する必要があります。

修正方法:

エンジンレベルのパッチ(Chromiumバイナリ内の変更)は、実際のブラウザから不利なプロパティディスクリプタを生成します。 JavaScriptインジェクションによるページレベルのパッチは、特徴的なパターンを持っています。 これは、バイナリパッチの実行時間アウトパーフォームプラグインベースのステルスのいくつかの理由の1つです。

信号5:ページの負荷の後の行動パターン

これは、指紋段階が通過した後にのみキックするので、信号#5です。 ページが読み込まれると、行動チェックが始まります。マウスの動きのエントロピー、スクロールパターン、アクション間のタイミング、フォーム入力のキーストロークの経度。 ゼロマウスパスで正確な座標をクリックし、文字ごとに正確に50msでタイプし、それらが現れた後にフォーム200msを提出する自動化は、単独で行動から検出することができます。

確認方法:

手動の相互作用から1つにあなたのオートメーションからアクショントレースを比較します。違いは通常明らかです。実際の動きは曲線、加速、簡単な一時停止、時々クリックを持っています。オートメーションは直線と均一なタイミングを持っています。

修正方法:

行動的な分散を追加します。: ビーザーカーブマウスパス, ジッタされたタイミング, 速度をスクロールし、減速, クリックする前にページ要素で時々一時停止. ライブラリ playwright-extra そして、このツールが助けを借りています。現実的な天井は「意図的ではなく、わずかにハリのある人間のように見える」ではなく、「任意のランダムなユーザーから区別できない」です。

信号6:WebRTC IPの漏出およびDNSの漏出

これは、特にプロキシされた自動化のサイレントキラーだから、信号#6です。 WebRTCのSTUNプロトコルは、ブラウザがプロキシの背後にある場合でも、ローカルIPアドレスを明らかにすることができます。 明示的な処理なしで、あなたの「Frankfurt住宅」セッションは、その実際のサンフランシスコデータセンターIPをICEの候補から漏れます。 DNS解像度は、ブラウザのDNSがプロキシを通過しながら、HTTPがプロキシを通過したときに同じことができます。

確認方法:

アクセス browserleaks.com/webrtc. このページでは、ローカルおよびパブリックIPs WebRTCが公開されています。どちらがプロキシと一致する必要があります。ローカルIPが実際のマシンのネットワークを表示する場合は、WebRTCリークがあります。 チェック browserleaks.com/dns DNS に相当する。

修正方法:

標準の緩和は、WebRTCをリレー専用モードに強制するものですが、それはプライバシー意識または自動設定として保守可能です。クリーナーの修正は、WebRTCとDNSルーティングをHTTPトラフィックと同じプロキシで処理するランタイムです。デフォルトでは、オペレータ構成は必要ありません。

信号7:ヘッドレスモードは指示します

これは、ヘッドレスのデプロイメントにのみ関連しているため、信号#7です。しかし、それは単一の最大の「devで動作し、生産で失敗します」障害です。ヘッドレスChromiumには、ヘッドフルの指紋の違いがあります:欠けているプラグイン(ゼロプラグインは疑わしいです)、異なるオーディオ出力、異なるデフォルトビューポート、サブタリー異なる出力を生成する特定のレンダリングパス、および(最近まで) 文字通り HeadlessChrome ユーザーエージェントのトークン。

確認方法:

ヘッドフルモードとヘッドレス生産環境で同じ指紋検査を実行します。すべての表面を比較します。あなたが見つけた違いは、生産検出システムが見えるものです。

修正方法:

ヘッドレス/ヘッドフルなパーシティをデザインで展示するランタイムを使用する — 指紋値は、モードに関係なく同じで、プラグインリストがポップアップされ、Chromeバージョンが報告されると一貫性があります。 スタックがステルスプラグインでストックヘッドレスChromiumを使用している場合は、各表面を個別にデバッグする計画。

15分診断ワークフロー

CAPTCHA がスパイクを率いるとき、これらを順番に動かします。ほとんどの失敗は最初の 3 つの信号の 1 つで解決します。

1. 自動ブラウザを開き、訪問 browserleaks.com/ip そして、 browserleaks.com/javascript. IPの地理、タイムゾーン、および Accept-Language. 一貫性のある国を記述しないと、問題は信号#1です。 今後、一貫性と再検証を修正します。

2. 「異なる」セッションの2つで同じ指紋検査を実行します。 キャンバス、WebGL、およびオーディオハッシュを比較します。 彼らが一致している場合は、問題は信号#2です。 指紋はセッション全体で再利用します。 艦隊はあなたがこれを修正するまでの1つのアイデンティティです。

3. 訪問客 tls.peet.ws JA3/JA4 を同じ OS でバニラChromiumに比較します。 Mismatch はシグナル #3 です。

4. コンソールチェック navigator.webdriver そしてその特性記述子。 非標準の記述子は信号#4です。

5. 自動インタラクションをトレースします。 直線マウスパスと均一なタイミングはシグナル#5です。 行動分散を追加します。

6. 訪問客 browserleaks.com/webrtc そして、 browserleaks.com/dns. プロキシにマッチしないローカルIPは、シグナル#6です。

7. ヘッドレスの場合:ヘッドフル(ローカル)とヘッドレス(プロダクション)の6つの信号をすべて比較します。 違いはシグナル#7です。

7 および CAPTCHA のレートがまだ高まると、残りの原因は通常、フリート(例えば、セッション全体で同期されたアクション)または速度関連で行動の相関です。つまり、ウィンドウが短すぎると、あまりにも少ない IP からあまりにも多くのトラフィックを送信しています。これらは、操作の問題ではなく、問題をスタックしません。

より深いCloudflare固有の故障モードについては、参照してください PlaywrightスクリプトがCloudflareによってブロックされる理由. どのブラウザツールがこのレイヤーをベストに扱うかを評価するために、当社の比較を参照してください。 AIエージェントの自動化に最適な7つのブラウザ.

CAPTCHA診断の一般的な間違い

ターン内のすべてのステルスプラグインを試してみる

それぞれの信号が無駄数週間を固定することなく、ステルスプラグインを介してサイクリング. 診断を実行します, 障害信号を識別します, その後、具体的にそれらに対処する修正を選択します. 「異なるステルスライブラリを乾燥」診断戦略ではありません.

スクリプトが変更されたと仮定

コードが変更されていない場合、回帰は環境です: ターゲットサイトの更新検出ルール、IPプールはブラックリスト、ステルスライブラリはパターンマッチ、またはコンテナのヘッドレスビルドが漂流しました。 環境をBisect、コードではありません。

検出障害として、CAPTCHA のあらゆる処理

一部のサイトでは、シグナルに関係なく、ポリシーとしてすべての新しいセッションにベースラインCAPTCHAを発行しています。 CAPTCHAレートがゼロではなく、安定的かつ控えめである場合、それは正当なものであってもよいです。 質問は、実際のユーザーが見るものとレートが一致しているかどうかです。

CAPTCHAを防止する代わりに解決する

CAPTCHA-solverサービスは存在し、正当な使用を持っています。 しかし、スケールでCAPTCHAを解決することは遅く、高価です。 アイデンティティコヒーレンスを修正することにより、トリガーを防止することは、ほとんどのワークフローのためにより速く、より安くなっています。 ソルバーは、診断の代替としてではなく、診断後の誤った残留率のために適切です。

CAPTCHA レートクリープを数週間以上無視

月に5%から15%から30%に登るCAPTCHA率は遅い漏れです。通常、指紋や行動パターンが増加して検出モデルが進化するにつれて増加します。 セッションが壊れるときに反応するだけで、レートをメトリックとして監視することで、この初期をキャッチします。

よくある質問

スクリプトがローカルで機能するのはなぜか、プロダクションでCAPTCHAをトリガーするのか?

最も一般的な原因は、環境の漂流です: ローカル開発は、あなたの住宅のIP、あなたの実際のタイムゾーン、およびあなたのデベロッパ・マシンの指紋を使用していますが、生産は、潜在的に異なるタイムゾーン、局面、指紋面とデータセンタープロキシの背後にあるLinuxコンテナで実行されます。 修正は、両方の環境で同一のアイデンティティを生成するランタイムです。 シグナル#1、#2、#7は、通常、すべて関与しています。

CAPTCHAをユニバーサルに迂回する方法はありますか?

いいえ。 ブラウザの設定、プラグイン、または実行時間がないため、CAPTCHAをユニバーサルに迂回します。 現実的な目標は、CAPTCHAがそれらを引き起こす上流信号を修正することによってトリガーされる速度を減らすことです。 退役または解決する必要がある後にCAPTCHAsがまだ受け取るセッション。

CAPTCHAソリューションサービスを使用する必要がありますか?

CAPTCHAsがまれな残留物であり、解決あたりの数セントが許容される低ボリュームのケースでは、はい。 CAPTCHAsがほとんどのセッションで出現する大量自動化のために、答えは診断信号を最初に固定することです - 高速度でCAPTCHAsを解決することは、通常ワークフローの経済性を破る十分な高価で低速です。

住宅のプロキシは、CAPTCHAトリガーだけを固定しますか?

いいえ。 住宅用プロキシは信号#1を部分的に固定します(IP地理部分)が、指紋、TLS、行動、およびヘッドレステル信号を非接触のままにします。 住宅用プロキシは、一部のサイトやほとんどのために、独自の不十分な場合に必要です。

検出モデルの更新はどのように迅速に行うのですか?

継続的に、練習中。主要なアンチボットベンダーは、少なくとも毎週、時々毎日モデルを更新します。これは、「6ヶ月前に働いたもの」が信頼できるベースラインではない理由です。すべてのスタックは、診断信号の継続的な測定を必要としますが、1回限りのセットアップではありません。

結論:診断は試行錯誤を打ちます

CAPTCHAは、症状が原因に関係なく同じであるため、単一の問題のように感じます。 現実は、個別に診断する必要がある7つの異なる原因です。 この井戸を処理するチームは、測定可能な信号でエンジニアリングシステムのようなスタックを扱います。 ランダムな修正を試みることによって解決するパズルのようにそれを扱うチーム。

構造パターンは、すべての7つの信号を渡って同じです。最高レベルの修正は、ブラウザのバイナリレベルで設計されたアイデンティティコヒーレンスであり、プロキシは指紋プロファイルとセッションごとに分離されたストレージにバインドされています。そのパターンは、シグナル#1、#2、#4、#6、#7を同時にアドレスし、#3(通常、Chromiumから継承されたTLS)と#5(行動的、オーケストレーションレイヤーの作業を必要とします)のみを残します。

Clawbrowser 構造層に対処するために構築されます。エンジンレベルの指紋生成、プロファイル・バウンド住宅のプロキシ、および命名セッション隔離は、一つの設計選択で診断のバルクを処理します。完全な統合パターンについては、参照してください Clawbrowser ドキュメント.