プロキシプールのクールダウン：失敗を追跡し復旧を検証する

プロキシが1つの期限に間に合わない。プールはそれを削除する。1時間後、プロキシは再び正常だが、記録を捨ててしまったアプリケーションにはそれを知る方法がない。

削除は、取り消されたアカウントや運用者が引退させたエンドポイントには適切かもしれない。一時的な失敗には別の状態がふさわしい。

次の判断に足る履歴を残す

利用可能

現在のポリシーの下で通常の作業に使える。

クールダウン中

記録された期限まで一時的に保留される。

検査許可

1回の統制された試行で復旧を評価できる。

無効

運用者または持続的な条件によりサービスから外された。

遷移とともに理由と段階を保存する。接続拒否、資格情報の拒否、遅い応答本文、宛先の HTTP エラーが、すべて同じ「死んだプロキシ」カウンターを増やすべきではない。

プロセス内のクールダウンには経過時間の時計を使う。単調時計は、短い待機が壁時計の調整に依存するのを防ぐ。単調なタイムスタンプを、他のマシンと共有する可搬な日付であるかのように永続化してはならない。分散スケジューラには、別途定義された時間と所有権のモデルが必要である。

復旧は殺到を解き放つべきではない

期限が切れたら、待機中のキュー全体を一度に送るのではなく、小さな復旧試行を許可する。成功すれば適格性を回復でき、別の失敗なら有界なポリシーに従って停止を延長できる。

検査は、それが予測すべき作業に合わせて選ぶ。TCP 接続の成功は完全な HTTP や SOCKS のトランザクションではない。無関係な IP 確認ページは、必要な宛先に到達できるか許可されているかを立証しない。

プロキシという言葉から普遍的なクールダウン時間が導かれるわけではない。操作のレイテンシ予算、サービスの挙動、もう一度失敗した場合の結果から決める。一時的な中断が黙って恒久的な容量喪失にならないよう、エンドポイントの記録を保持する。