ALB が 502 Bad Gateway を返す原因と診断手順 — ターゲットが Healthy でも発生するケース
ターゲットグループのヘルスチェックは全台 Healthy なのに、ALB が 502 を返し続ける。このパターンは本番障害の中でも特に混乱しやすい。ヘルスチェックが通っているという事実が「アプリは正常」という誤った確信を生み、実際の原因であるHTTPプロトコル違反やコネクション管理の問題を見落とさせる。 TL;DR — ALB 502 の主要原因と対処 原因カテゴリ 具体的な症状 対処の方向性 不正な HTTP レスポンス ステータス行・ヘッダーの形式違反 アプリのレスポンス形式を修正 Keep-Alive タイムアウトのミスアライン 断続的な 502、ピーク時に増加 アプリ側の idle timeout を ALB より短く設定 接続リセット (RST) ALB がレスポンス受信前に RST を受け取る アプリのクラッシュ・OOM を調査 プロトコルミスマッチ HTTPS ターゲットに HTTP で応答、またはその逆 ターゲットグループのプロトコル設定を確認 レスポンスヘッダーサイズ超過 特定リクエストのみ 502 レスポンスヘッダーを削減 ALB 502 の仕組み — なぜ Healthy でも発生するか ALB のヘルスチェックとリクエスト転送は独立したコネクションで動作する。ヘルスチェックは設定したパス（例: /health ）に対して単純な HTTP GET を発行し、期待するステータスコードが返れば Healthy と判定する。これはアプリが 生きているか を確認するだけで、任意のリクエストに対して正しい HTTP レスポンスを返せるかは検証しない。 502 は ALB がバックエンドから有効な HTTP レスポンスを受け取れなかったことを意味する。具体的には以下のいずれかが発生している。 バックエンドが接続を確立したが、整形式の HTTP レスポンスを返さなかった バックエンドがレスポンスを返す前に接続をリセット (TCP RST) した ALB がレスポンスを受信する前にバックエンドが接続を閉じた sequenceDiagram ...