API接続とCAPTCHAプロキシは別物

Application server
  -> HTTPS api.solvethree.com/v1/tasks
     Authorization: Bearer <workspace API key>
     JSON: { "site": "accounts.example.com", "action": "login", "proxy": "http://USER:PASS@PROXY:PORT" }

solvethree solves through the proxy supplied in that JSON.

Application or browser
  -> the SAME successful proxy and pinned exit
  -> intended target, with the returned token/headers/cookie and browser identity

The API key belongs on the API request, never the target request.
Putting a proxy URL in task JSON does not configure the application's HTTP client.

サーバーは、認証付きの HTTPS リクエストを solvethree API に送信します。プロキシ URL は JSON 本文に含まれ、solvethree はそのプロキシを使って解決します。その後、アプリケーションまたはブラウザーが、対象サイトに別のリクエストを送信します。タスクのフィールドも SDK の呼び出しも、この最後の接続を自動で設定するものではありません。

例のホスト名、アクション、プロキシ認証情報を、ご自身の値に置き換えてください。そのサイトには、ワークスペースで利用可能な有効なプロファイルが必要です。ホスト名を送信してもプロファイルは作成されません。サイトプロファイルの設定を参照してください。

ワークスペースの API キーはサーバー上で保持してください。タスクのステータスを取得する場合も含め、その Bearer 認証ヘッダーは API ホストにのみ送信します。そのヘッダーを対象サイトへのリクエストにコピーしたり、プロキシ認証に使用したりしないでください。

ソリューションを送信する HTTP クライアントまたはブラウザーは、別途設定してください。成功したプロキシと、返されたブラウザー識別情報の userAgent および secChUa を併用します。ソリューションを、無関係なブラウザー識別情報、プロキシ、対象 URL と組み合わせないでください。

プロバイダーが接続ごとに出口 IP をローテーションする場合、同じプロキシ URL だけでは不十分です。プロバイダーのセッション機能または固定機能を使い、解決と対象サイトへの送信で同じ出口を共有してください。住宅用やモバイルという分類だけでは、対象サイトに受け入れられるかどうかは判断できません。

proxyCandidates を使用する場合は、リスト内の任意の項目ではなく、実際に成功したプロキシ経由で送信してください。候補を指定すると solvethree は別の出口を試せますが、ブラウザーを設定したり、受け入れを保証したりするものではありません。

タスクが ready であることは、ソリューションが利用可能であることを意味します。受け入れられたかどうかは別の結果です。そのソリューションを含むリクエストに対する、対象サイトのレスポンスを確認してください。

HTTP クライアントが HTTP_PROXY などのプロキシ環境設定を読み込む場合、それらの設定が api.solvethree.com へのリクエストもルーティングしていないか確認してください。対象サイトへの通信専用にするつもりだったプロキシを、API 接続も経由する可能性があります。タスクの JSON と一致すると決めつけず、クライアントで実際に有効なトランスポート設定を確認してください。

API 通信と対象サイトへの通信は別々に設定してください。環境変数のプロキシ設定は、必須のタスクフィールドの代わりにはなりません。reCAPTCHA リクエストには、引き続き proxy または proxyCandidates のどちらか一方だけが必要です。

タスクを受け取る前に API リクエストが失敗する。

HTTP レスポンスと、API クライアントが使用した経路を確認してください。環境変数のプロキシ設定も確認します。

試してみましょう： 成功時のペイロードを読み取る前に、HTTP エラーを処理してください。タスクのプロキシをむやみに変更するのではなく、意図しない API のルーティングを修正します。

HTTP 407 が返される。

プロキシ認証の失敗が発生したのが、API 接続なのか、タスクのプロキシを使用する接続なのかを特定してください。

試してみましょう： そのプロキシの認証情報を修正してください。URL 全体ではなく、ユーザー名とパスワードの各構成要素に含まれる予約文字をパーセントエンコードします。

タスクの作成がタイムアウトする。

タイムアウトしても、API がタスクの作成に失敗したとは限りません。

試してみましょう： タスク ID がある場合は、そのタスクを取得してください。requestId を指定していた場合は、新たな論理タスクを作成する前に、同じ ID で同じタスクリクエストを繰り返して復旧します。

タスクが failed になる。

その errorCode と error を確認してください。これは HTTP トランスポートエラーとは異なります。

試してみましょう： そのタスクのポーリングを停止し、報告された原因に対処してください。無効な入力を変更せずに再試行したり、API 接続のプロキシが失敗の原因だと決めつけたりしないでください。