プロキシローテーションのループを永遠に走らせない

プロキシプールは単純な障害をビジーループに変えてしまいます。アドレスを選び、失敗し、別のアドレスを選び、また失敗する。自分のネットワークが落ちているためにどのエンドポイントにも到達できないなら、アドレスを変えても原因は決して直りません。

プールや無料プロキシ一覧から最初のプロキシを選ぶ前に、操作に予算を与えます。試行回数の上限、接続と読み取りの待ち時間の上限、そしてタスク全体の期限です。Requests のタイムアウトは文書化された接続や読み取りの動作を制御しますが、それ自体は新しいリクエストを出し続けるループを制限しません。

もう一度試す価値があるものを決める

• プロキシ接続が拒否された場合は、別のエンドポイントを試す根拠になります。
• 宛先の応答には独自の解釈が必要です。HTTP エラーを受け取ったことは、何らかのリクエスト経路が完了した証拠です。
• プロキシ認証の失敗は、増え続けるリストに同じ資格情報を打ち込むのではなく、エンドポイントとアカウントを確認すべき合図です。

元の例外やステータスを試行記録と一緒に残す。「すべてのプロキシが失敗した」だけの最終メッセージでは、失敗が同じ原因だったのかさえ分かりません。

実際のリクエストのたびに各プロキシのヘルスチェックを行うと、リクエストがもう一つ増えるうえ、次が成功する保証にもなりません。最近のヘルス情報がタスクに合うところで再利用し、実際の操作に自分の結果を報告させます。

再試行は作業を繰り返すことがある

読み取り専用の取得なら、別のプロキシへ移るほうが送信をやり直すよりたいてい簡単です。購入やフォームの送信後に接続が切れた場合、宛先はすでに処理済みかもしれません。作業を繰り返す前に、サービスの冪等性の仕組みと HTTP の再試行ルールに従います。

予算を使い切ったら、役に立つ失敗を返します。証拠とともに止まるジョブは、誰かが気づくまで静かに回り続けるジョブより修理が容易です。