HTTP 502と504は、ゲートウェイやプロキシなどの中継を含む構成で調査することのある応答です。どちらも5xxですが、示している状態は異なります。
502は上流から有効でない応答を受けたこと、504は必要な上流応答を時間内に受けられなかったことが標準的な意味です。コードだけでサーバー故障や設定ミスを断定せず、中継のどこで起きたかを調べます。
不正な応答と待ち時間を区別する
RFC 9110のサーバーエラーの定義を、最初の調査観点へ対応させます。
| コード | 標準的な意味 | 調査の出発点 |
|---|---|---|
| 502 Bad Gateway | 中継先から有効でない応答を受けた | 応答した中継層と上流通信の記録 |
| 504 Gateway Timeout | 必要な上流応答を時間内に得られなかった | 待っていた接続先と待ち時間の設定・実測 |
製品がどの条件を各コードへ対応させるかには実装上の詳細があります。利用しているプロキシやクラウドサービスのログ定義も併せて確認してください。
要求の経路を短く書き出す
まず「利用者→入口→アプリ→外部サービス」のように、関係する経路を描きます。実際の構成で存在しない段階を推測で足さず、担当や設定から確認できた範囲を記録します。
API Gatewayの役割やロードバランサーがある場合、入口の正常性だけでは後段の処理まで成功したと判断できません。どの層が今回のコードを返したかを特定することが先です。
一つの要求を時刻とIDで照合する
仮に入口で504が記録され、アプリではその後に処理完了が記録されていたとします。この場合、利用者へ結果を返せなかったことと、アプリ内の変更が確定したことを分けて扱う必要があります。
| 記録する場所 | 照合する情報 |
|---|---|
| 利用側 | 開始時刻・対象操作・応答までの時間 |
| 中継側 | 要求ID・接続先・応答コード・上流の時間 |
| アプリ側 | 同じ要求の開始・終了・結果 |
| 外部依存先 | 関連する呼出しの成否と所要時間 |
時刻のずれや、IDが引き継がれていない区間は調査上の限界として残します。機密値を除き、必要な担当へ共有できる形に整えます。
タイムアウトの延長だけで終えない
504が出たからといって、すべての待ち時間を長くすることを先に決めません。特定操作だけ遅いのか、全体が混雑しているのか、後段が応答しないのかを区別します。
待ち時間を変える場合も、利用側が待てる時間、同時処理数、残り続ける処理への影響を確認します。原因が分からない段階では、観測事実と原因仮説を分けて記録します。
再送前に業務の確定状態を確認する
更新要求では、中継側の失敗だけを理由に再送すると二重処理につながるおそれがあります。利用先の再試行条件に従い、処理IDや照会手段で結果を確認します。
502・504の切分けでは、応答した層、待っていた相手、業務の確定状態の三つを揃えることが、次の調査や復旧判断につながります。