Squid retry_on_error: ステータスコードと代替ルート

Squid には retry_on_error というオプションがありますが、その名前は有用な解釈より広い意味を持ちます。ページが動くまで、失敗したすべてのリクエストが無期限に繰り返されるという意味ではありません。

このディレクティブをサポートするリリースでは、既定で無効です。文書化された再試行リストは 403、500、501、502、503、504 で、別の稼働中の宛先を通じてリクエストを試みます。これは代替の転送経路を持つ階層で特に重要です。同じソケットから同じサーバーへの時間指定の再試行だけではありません。

まず障害を名指しする

プロキシへの接続時の拒否、プロキシ認証の失敗、オリジンの HTTP エラー、配信開始後に切断された応答は、同じ再試行の機会を提供しません。1 つの設定が 4 つすべてを同じように扱うと期待しないでください。

プライベート出口では、代替経路が許容できるかも判断してください。別の親は別の公開ソースアドレス、認証ポリシー、ネットワーク上の位置を持つ可能性があります。その代替経由の成功は、最初の親を選んだ理由を損なうことがあります。

アプリケーション操作には別の懸念があります。リクエストを繰り返すとその効果も繰り返される可能性があります。クライアントとサーバーには適切な再試行セマンティクスが必要で、特にデータを作成・変更する操作では重要です。プロキシ設定は、不確実な結果に対するアプリケーション層の扱いを代替しません。

正確なリリースのディレクティブを読んでください。リファレンスには可用性と既定の動作が記載されています。リクエストの期限とユーザーに見える総待ち時間も考慮してください。追加の転送試行は、より良い結果を生まないまま残り時間を消費することがあります。

断続的な障害を調査するときは、ステータス、選択された親または宛先、試行の順序を記録してください。そうしないと、再試行によって繰り返し発生するルーティング問題が全体的に遅いウェブサイトのように見え、実際に失敗した経路が隠れてしまいます。