先に結論
エラー番号だけで再起動しません。レスポンスを返した主体を特定し、CDN→ロードバランサー→オリジン→アプリの時刻をそろえて確認します。
最初の5分で発生層を決める
- URL、発生時刻、502/504の全文、レスポンスヘッダー、リクエストIDを保存する。
- 外部監視と別回線から、全URLか特定パスだけかを確認する。
- CDN/LBのステータスと、同時刻の設定変更・デプロイ・スケールイベントを確認する。
- 健全性チェック、オリジンの接続数・CPU・メモリ・I/O・依存先遅延を見る。
- CDN/LBとオリジンのログを同じタイムゾーンへそろえ、1件のリクエストを追う。
結論：CDN/LBに記録があり、オリジンに到達記録がなければ経路・FW・TLSを優先します。到達し処理途中で切れていれば、アプリ・依存先・タイムアウトの順です。
502と504で優先する確認
| 観測 | 可能性 | 次の確認 |
|---|---|---|
| 502、上流TCP reset | オリジンが接続を切断 | 再起動・クラッシュ・keep-alive・接続数 |
| 502、応答形式が不正 | プロキシが解釈不能 | ヘッダーサイズ、HTTP形式、アプリ/プロキシログ |
| 502、TLS handshake失敗 | LB/CDNとオリジン間TLS | 証明書名、プロトコル、暗号、SNI |
| 504、接続自体が成立しない | FW/NACL/経路/ポート | 送信元許可、待受、ルーティング |
| 504、接続後に期限超過 | 処理遅延・依存先遅延 | DB、外部API、キュー、遅いパス |
| 一部リージョンだけ | 経路・エッジ・特定オリジン | POP/リージョン別ログと健全性 |
TCP接続前に止まる場合は接続タイムアウトの運営者向け手順も確認します。
「同じ1件」を時系列で追う
- CDNのリクエストID、時刻、エッジ拠点、オリジンIPを控える。
- LBログで同時刻のtarget status、接続時間、応答時間を確認する。
- オリジンのアクセス・アプリログで同じパスと追跡IDを探す。
- DB・外部API・キューの遅延を同じ時刻で重ねる。
- 成功リクエストとの差分を、リージョン・パス・ペイロード・認証有無で比較する。
避ける操作
- 証拠保存前に全オリジンを同時再起動する。
- 原因未確認のままCDN/LB/アプリの全タイムアウトを一斉に延長する。
- オリジンを公開してCDNやWAFを恒久的に迂回する。
- 過負荷中に無制限リトライを追加し、雪崩を悪化させる。
専門対応へ渡す判断
継続的な過負荷、メモリ枯渇、DB接続枯渇、未知の大量通信、複数リージョン障害は、単発の再起動で完了にしません。発生時刻、リクエストID、構成図、直前変更、CDN/LB/アプリの各ログ、暫定回避の有無をまとめて渡します。
外部監視で発生時刻を固定する
HTTPステータスと応答時間を複数地点から記録すると、利用者申告より前の発生時刻と範囲を残せます。要件と無料枠を比較してから選びます。
UptimeRobot公式の監視機能を見る公式情報
よくある質問
502と504の違いは何ですか？
一般に502はゲートウェイが上流から有効な応答を受け取れない状態、504は上流の応答を期限内に受け取れない状態です。ただし表示主体で意味が異なるため、レスポンスヘッダーとCDN・LBのログで発生層を確定します。
タイムアウト値を延ばせば直りますか？
遅い処理を隠すだけになることがあります。AWSもCloudFrontの504では、先にアプリ性能とオリジン到達性を確認するよう案内しています。処理時間が仕様上必要な場合だけ、影響を測って変更します。
CDNの障害ですか？
断定できません。Cloudflareは502/504をオリジン由来とCloudflare由来に分けています。エラーページの表示、Ray ID等の識別子、同時刻のオリジンログ、CDNを経由しない健全性確認を突き合わせます。