CAPTCHAタスクにおけるCapSolverのプロキシエラーを修正する方法

要約

• まず、発生したエラーそのものを確認し、それが使用している HTTP クライアント、プロキシ、CapSolver、またはターゲットサイトのどこから返ってきたものかを特定する。
• プロキシのパラメータを追加する前に、選択した CAPTCHA タスクの種類を確認する。タスクタイプごとにプロキシ要件が異なる。
• ノート PC で動作しているプロキシでも、認証が呼び出し元 IP に紐づいている場合、ソルビングサービスからの接続は拒否されることがある。
• HTTP 407 はプロキシ認証エラーを示し、接続タイムアウトはホスト、ポート、ネットワーク経路、上流からの応答を調査する必要がある。
• スティッキーセッションというラベルだけでは、すべてのリクエストが同じ出口 IP を使用したとは証明できない。継続性が重要な場合は、プロバイダのセッション挙動を確認する。
• 問題を 1 つ特定して修正したら、許可されたテストを 1 回だけ実行し、アプリケーション側の結果を確認してから、大きな負荷を元に戻す。

プロキシを追加した後に CAPTCHA リクエストが失敗する一方で、同じプロキシはブラウザでは動作しているように見える場合、最も有用な次のステップはその 2 つの接続を比較することである。使用している認証情報が違う、到達している宛先が違う、または発信元マシンが違う可能性がある。これらの違いを確認せずにリクエストを繰り返しても、最初のエラーの原因を説明しないまま新たなエラーを増やすだけになり得る。

CapSolver は、サポートされている CAPTCHA タスクに対してプロキシ設定を受け付ける。その設定は、タスクインターフェースの仕様に合致し、到達可能で適切に認証されたプロキシでなければならない。本ガイドでは、すでに認可済みの連携においてよくある失敗パターンを順に解説する。追加のカスタムトラブルシューティングスクリプトを用意しなくても、何を確認し、各結果が何を意味するかに焦点を当てている。

実際にどの接続が失敗したかを特定する

CapSolver のプロキシエラーは、「CAPTCHA が失敗した」といった汎用的なメッセージからではなく、そのエラーを返した接続単位で診断する必要がある。

プロキシ は、別のクライアントに代わってトラフィックを転送する。ブラウザのワークフローでは、ページを読み込むためにブラウザ自身がプロキシを利用している一方で、CAPTCHA タスクはソルビングサービスに対して別途プロキシ設定を渡しているかもしれない。あなたのプログラム自身も CapSolver API への接続を必要とする。

必要であれば紙に接続関係を書き出してみる：アプリケーションから API へ、ブラウザからサイトへ、タスクリクエストから設定済みプロキシを経由したソルバーへ。ある 1 つの接続が成功したとしても、他の接続が正常であることの証拠にはならない。

HTTP ステータスコード、実行していた操作内容、そしてシークレット情報を除いたレスポンスボディを保存しておく。API レスポンスであれば、CapSolver エラーリファレンス にしたがって errorId、errorCode、errorDescription を確認する。タスク ID が返っている場合はそれも保持しておく。

次にどの確認を行うかは、以下の区別に従って選ぶ：

観察される事象	優先して調査すべき対象	避けるべき早計な結論
クライアントが API に到達できない	アプリケーションのネットワーク、DNS、外向きアクセス	ターゲットサイトが CAPTCHA を拒否した
プロキシが HTTP 407 を返す	プロキシの認証情報または呼び出し元 IP 認可	CapSolver の API キーが必ず間違っている
API がタスクデータの不正を報告する	正確なタスクタイプと送信フィールド	プロキシサービスが必ずダウンしている
接続が停滞またはタイムアウトする	ホスト、ポート、ネットワーク経路、応答時間	ソルバーの待ち時間を伸ばせば接続が直る
API が ERROR_PROXY_BANNED を報告する	報告されているターゲット側の拒否と許可されたアクセス条件	リクエストを繰り返せば制限が解除される
タスクは結果を返すがページ側が失敗する	セッション継続性とアプリケーション側の検証	プロキシ接続だけで完了が証明される

これらは診断の出発点である。レスポンスの詳細とそのレスポンスを発したコンポーネントによって、どの分岐が当てはまるかが決まる。

CAPTCHA タスクとプロキシパラメータを確認する

現在のタスクドキュメントが、プロキシの必須／任意やエンドポイントが受け付けるフィールドを定義している。

たとえば reCAPTCHA v2 タスクガイド には、プロキシなしとプロキシありの 2 種類のバリアントが記載されている。片方のバリアントで利用しているパラメータが、そのままもう一方のバリアントも自動的に設定してくれると決めつけてはならない。また、ブラウザのネットワーク設定と CapSolver に送信する task オブジェクトの設定は区別すること。

公式のプロキシパラメータガイド には、proxyType、proxyAddress、proxyPort、proxyLogin、proxyPassword などの構造化フィールドと、サポートされる結合済みプロキシ形式が記載されている。ドキュメント化された表現を 1 つだけ使い、最終的にシリアライズされたリクエストをそのリファレンスと比較する。デバッグ中に競合する 2 つの設定方法を同時に渡すのは避ける。

実際に送信されている値を確認する

意図した設定ファイルだけでなく、アプリケーションが実際に生成しているリクエスト内容を確認する。

デプロイ環境には依然として古いパスワード、空の環境変数、誤ったエンドポイントが残っている場合がある。あるライブラリにコピーした接続文字列が、CAPTCHA タスクに渡す際には別の表現が必要になることもある。プロトコル、ホスト、ポート、認証フィールドを個別に確認する。

スクリーンショットや一般的なログにはシークレット値を残さないこと。設定比較の目的であれば、「パスワードが存在するか」とシークレットのバージョン識別子を記録するほうが、パスワードそのものを晒すより実用的である。認証情報に予約文字が含まれる場合は、それを消費するインターフェース側のエンコーディングルールに従い、個別フィールドと URL 形式文字列に同じ変換を無差別に適用しないこと。

ブラウザ設定とタスク設定を分離する

ブラウザでプロキシが動いているという事実は、あくまでそのブラウザ接続についての証拠にすぎない。

たとえば Playwright は ブラウザ用の独自プロキシ設定 を持っている。それを設定しても、別の CapSolver API リクエスト内のプロキシフィールドが自動的に埋まるわけではない。逆に、CAPTCHA タスク内にプロキシを指定しても、別途起動したブラウザの設定が書き換わるわけでもない。

両者の設定を一致させる必要があるタスクでは、双方の有効な設定を比較する。結果が解釈可能なまま保てるように、1 回に 1 つの設定だけを変更する。

タイムアウトを増やす前に認証を修正する

HTTP 407 は、リクエストがプロキシに必要な認証を正常に供給していないことを意味する。

HTTP 407 の定義 は、プロキシ認証と、宛先サーバーでの認証を区別している。有効な CapSolver アカウントキーであっても、別サービスであるプロキシのパスワード間違いを修正することはできない。

プロキシの管理ダッシュボードやマネジメント画面で、認証情報のペアを確認する。サブスクリプションまたはトラフィック枠が有効であり、そのエンドポイントがその認証情報に紐づいているかどうかを確かめる。ユーザー名にプロバイダ固有のリージョンやセッションオプションが含まれている場合は、その値全体をプロバイダが提供する設定例と突き合わせる。

IP 認可型プロキシの場合は、実際に接続を行っているマシンを特定する。オフィスやノート PC の IP を許可しても、リモートのソルビングサービスは許可されない。CapSolver はこの用途向けに、現在の呼び出し元 IP 一覧をプロキシドキュメント内で公開している。別記事から古いリストをコピーするのではなく、設定時には必ずそのライブリストを確認する。

プロキシのアクセスルールには、明示的に必要な呼び出し元だけを追加する。正しい呼び出し元が認可されているか確認するために、認証を外したりアクセスを広く開放したりする必要はない。

CapSolver ボーナスコードのご利用方法

自動化の予算をすぐに増やしましょう！
CapSolver アカウントへのチャージ時にボーナスコード CAP26 を使用すると、すべてのリチャージ額に対して追加で 5% ボーナス が無制限に付与されます。
今すぐ CapSolver ダッシュボード から引き換えてください。

接続性とタイムアウトエラーを調査する

接続タイムアウトは「指定した時間内に操作が完了しなかった」ことを意味するだけであり、それ自体では根本原因を特定しない。

小さな許可されたチェックを使って、リクエストがどこまで進んでいるかを確認する。呼び出し元はプロキシホストの名前解決ができているか。設定されたポートに到達できるか。プロキシ認証は完了しているか。プロキシは許可された宛先からの応答を返しているか。パブリック IP チェックの成功は、プロキシ接続性の確認には役立つが、ターゲットページや CAPTCHA タスクの成功を保証するものではない。

504 Gateway Timeout にはより限定された意味がある。これは、ゲートウェイが上流サーバーから期限内に応答を受け取れなかったことを示す。クライアント側の接続例外や CapSolver タスクタイムアウトとは区別しておく。

関連する環境からテストする

失敗が発生している環境を自分で制御できる場合は、その環境から診断を実行する。

ローカルテストでは、クラウドワーカーの外向きファイアウォールルールを検証できない。失敗している接続がソルビングサービス内から発信されているのであれば、ラップトップテストでの再現を前提とするのではなく、タスクのエラー詳細とプロキシプロバイダ側の接続記録を利用する。両サービスが同じ試行を調査できるよう、タイムスタンプを保持しておく。

プロキシトラブルシューティングリファレンス には、追加の接続性・認証チェックが掲載されている。自分の構成に関係するチェックだけを適用すること。特定のプロキシ製品のエンドポイント形式やユーザー名形式は、すべてのプロバイダに共通のフォーマットではない。

テストは小さく保つ

失敗しているバッチ処理を一時停止し、1 つのタスクで問題を再現する。現在のサービス構成に対してホストとポートを確認し、不一致が明らかになればそれを修正するか、管理者に対して範囲を絞ったネットワーク変更を依頼する。

エラーが消えるかを試すために、セキュリティコントロールを広く無効化したり、同時実行数を増やし続けたりしてはならない。設定の異なる多くの試行が重なった状態より、1 件のきちんと記録された失敗の方が調査しやすい。

接続が動いている場合のセッション継続性の確認

プロキシ自体の接続は成功しているが、ワークフロー上、同じ出口を使い続けることが重要な場合には、次にセッション継続性を確認する。

セッション ID はプロキシプロバイダのルーティングシステムへの入力である。どのくらいの期間ルーティングが安定して維持されるのか、ノードが利用不能になったときに何が起こるのかは、プロバイダのドキュメントに従う。したがって、設定したスティッキー期間は、実際の接続挙動と照らし合わせて確認する必要がある。

プロキシゲートウェイで解決されるアドレスと、宛先から観測される出口 IP を混同しないこと。これらは経路上の異なるポイントを指している。テストしている接続について、どの観測点または診断エンドポイントが出口アドレスを表しているのか、プロバイダに確認する。

AntiCloudflareTask におけるダイナミック DNS や IP 変化に関する特定のメッセージについては、別途用意された dynamic DNS プロキシエラーガイド に従うこと。その記事ではセッション ID 問題が詳細に説明されている。ただし、すべてのプロキシエラーにその診断を当てはめてはならない。間違ったパスワードとダイナミックなゲートウェイは別の問題である。

ターゲット側がプロキシ IP を明示的に拒否しているのであれば、繰り返し試行はやめ、サイト所有者または関連プロバイダと許可されたアクセス条件を再確認する。ソルバーの結果は、アクセス制限を無視してよいという許可証ではない。

修正を確認し、サポート向けレポートを準備する

有効な修正は、あるエラーメッセージが消えたことではなく、本来意図したアプリケーション操作が成功したことによって確認すべきである。

1 つの修正をドキュメント化したら、適切であれば新しいタスクを 1 つ作成し、そのレスポンスを保持する。非同期タスクについては、タスク結果取得のドキュメント に従って、処理中・完了・エラーを区別する。そのうえで、許可されたページ遷移やアプリケーションアクションが完了したかを確認する。

問題が残っている場合は、タスクタイプ、利用可能であればタスク ID、概ねの発生時刻とタイムゾーン、シークレットを除いた正確なエラー、プロキシプロトコル、認証方式、すでに実施済みのチェック内容を含む簡潔なレポートをサポートに送る。障害がローカル、クラウドワーカー、ソルバータスクのどこで発生しているのかも説明する。

サポートが特に必要とする場合を除き、認証情報は適切なプライベートチャネルでのみ共有すること。API キー、プロキシパスワード、Cookie、ソリューショントークンを公開の Issue トラッカーに投稿してはならない。

この一連の手順により、CapSolver とプロキシプロバイダは、調査対象となる具体的な障害事例を得ることができる。重要なのは、同じ問題を次回すぐに認識できるだけの証拠とともに、修正された接続と検証済みのアプリケーション結果を得ることである。

FAQ

Q: Chrome ではプロキシが動作するのに、CapSolver タスクでは失敗するのはなぜですか？

タスク側が、Chrome とは異なる認証情報、フォーマット、呼び出し元 IP 認可を使用している可能性がある。2 つの接続が同等だと決めつける前に、タスクが実際に送信しているパラメータと、プロキシのアクセスルールを比較すること。

Q: プロキシなし（proxyless）タスクは、ブラウザで設定したプロキシを利用しますか？

そのように動作すると決めつけてはならない。ブラウザプロキシとソルバータスクは別々の設定である。利用しているタスクバリアントと連携方式のドキュメントを確認すること。

Q: タイムアウトを長くすれば HTTP 407 は解消しますか？

いいえ。HTTP 407 はプロキシ認証または呼び出し元認可の修正を必要とする。待ち時間を延ばしても不足している認証情報は補えない。

Q: スティッキーセッションを使えば、出口 IP が絶対に変わらないと保証されますか？

いいえ。ラベルだけから普遍的な保証は導けない。プロバイダのセッションポリシー、障害時の挙動、観測された出口 IP を確認すること。AntiCloudflareTask のそのエラーが出ている場合のみ、専用の dynamic DNS ガイドを利用する。

Q: プロキシエラーについてサポートに何を送ればよいですか？

利用可能であればタスク ID、時刻、タスクタイプ、シークレットを除いたエラー内容、プロトコル、認証方式、実施済みチェックの概要を送る。通常のログや公開スクリーンショットにはシークレットを含めないこと。