429/503で再試行が止まらない時の診断手順

429/503 の直後にクライアントが連続再試行すると、障害が長引くことがあります。Retry-After と実装挙動を同時に確認するのが最短です。

典型的な症状

診断ステップ

  1. 1) Response Headers Parser で status / Date / Retry-After の実値を採取する
  2. 2) Retry-After Inspect で delta-seconds か HTTP-date かを判定する
  3. 3) HTTP Status Inspect で 429/503 の返却意図を確認する
  4. 4) Server-Timing Inspect で過負荷区間を確認し、再試行集中と相関を見る
  5. 5) クライアント実装（待機単位・最大再試行・ジッター）を照合する

よくある原因

運用チェックリスト

修正後の再確認

使うツール

FAQ

Retry-After は秒と日時のどちらで返るのですか？
両方あり得ます。delta-seconds と HTTP-date のどちらかを必ず実値で判定してください。
再試行を止める最低要件は何ですか？
Retry-After 準拠、指数バックオフ、ジッター、最大再試行回数の4点を同時に入れることです。

参照仕様

site_map ルールに基づいて、次に確認すべきページを表示しています。

  1. HTTP Header Parser — 生ヘッダーを構造化して一覧化
  2. Response Headers Parser — レスポンスヘッダーを構造化解析
  3. Retry-After Inspect — Retry-After を解析して再試行待機を確認
  4. HTTP Status Inspect — HTTPステータスコードを解析して対処方針を確認
  5. Server-Timing Inspect — Server-Timing を分解して遅延指標を確認
  6. 症状別診断ガイド（入口） — キャッシュ/CORS/JWT/MIME系の実運用トラブルを、症状起点で最短導線に振り分ける総合ハブ
  7. 304が返らない時の診断手順 — ETag / Last-Modified と If-* の往復を確認して 304 不発を切り分ける
  8. 更新したのに反映されない時の診断手順 — HTML/API/静的アセット別にキャッシュ方針を確認し、反映遅延を短時間で切り分ける

事例クラスタ一覧

実運用トラブル別に、最短の診断ルートへ入るためのシナリオ集