HTTP 500は要求の処理を妨げる予期しない状態、503は一時的な過負荷や計画保守などで現在要求を扱えない状態を表します。どちらもサーバー側の応答ですが、番号だけから故障箇所や復旧時刻を特定することはできません。
この記事では、応答を見た後に集める情報と、再試行を判断するための確認を整理します。
500と503が伝える状態を分ける
RFC 9110の500は、要求を完了できない予期しない状態を示します。503は、一時的な過負荷や計画保守などにより現在処理できず、時間がたてば緩和される見込みの状態です。
| コード | 仕様上の意味 | 調査で確かめること |
|---|---|---|
| 500 | 予期しない状態で処理できない | 例外・設定・依存先・直前変更 |
| 503 | 一時的に要求を扱えない | 負荷・保守・受付制御・復旧状況 |
調査項目は原因候補であり、そのコードが出た原因を断定する表ではありません。
どの層が応答したかを確認する
アプリ、プロキシ、ロードバランサーなど、利用者と処理本体の間には複数の層があります。エラーページの見た目だけで判断せず、要求IDや時刻を使い、どの層が応答を作ったかを確認します。
中継先の無効な応答や待ち時間に関するコードは、502と504として別に整理できます。500・503を見ても、まず経路を特定する考え方は共通です。
直前変更と発生範囲を分けて記録する
仮に一部のAPIだけで500が増えたなら、そのAPIの処理や依存関係を確認する材料になります。全体で503が出ているなら、保守情報や入口の受付状況も確認します。いずれも実測に基づいて調べるための仮例です。
- 発生日時と継続時間。
- URLのパス・メソッド・要求ID。
- 成功する処理と失敗する処理の差。
- 直前の変更と、観測できた負荷やログ。
利用者の認証情報や個人データは、調査用の共有記録から除きます。
Retry-Afterがあっても再送の安全性は別に判断する
503には、再試行まで待つ時間を示すRetry-Afterを付けられます。ただし必ず付いているとは限らず、指定時間後の成功を保証するものでもありません。
注文や決済などの更新操作では、元の処理が確定したか、重複を防ぐ仕組みがあるかを確認します。過負荷時に無制限の再送を行うのではなく、上限や待機条件をAPIの契約へ合わせます。
復旧確認を利用者の処理までつなぐ
コードの意味・応答した層・実際の処理結果を揃えて確認しましょう。200へ戻ったことだけで終わらず、失敗した業務の状態を確認し、必要な対応を整理します。