はじめに
本記事の目的
本記事は、AWS環境で発生する「502 Bad Gateway」エラーの原因と対策をわかりやすく解説することを目的としています。初めて502エラーに直面する方でも理解できるよう、基本から具体的な調査手順、予防策までを丁寧に説明します。
対象読者
・WebサイトやAPI運用に携わるエンジニアや運用担当者
・AWSを使っているが502エラーの対処に不安がある方
・トラブルシューティングの基本を学びたい方
本記事で扱う内容（概要）
第2章で502エラーの意味を説明し、第3章〜第5章でAWS特有の発生ケースや原因、対策を紹介します。第6章で実際の調査手順を示し、第7章で再発防止の方法をまとめます。
読み方のコツ
まずは第2章で502エラーの基本を押さしてください。現象の確認とログの見方を優先すると、原因特定が速くなります。
502 Bad Gatewayエラーとは？
概要
502 Bad Gatewayエラーは、ゲートウェイ（中継役）がバックエンドから正しい応答を受け取れなかったときに返されるHTTPステータスコードです。AWSに限らず、インターネット上の多くのシステムで見られます。
どのように表示されるか
ブラウザでは「502 Bad Gateway」と表示されます。サイト独自のエラーページや、サーバー名と一緒に簡単なメッセージが出ることがあります。
何が起こっているのか（例）
中継役を郵便局に例えると、配達員（ゲートウェイ）が配達先（バックエンド）から不正な荷物（応答）を受け取った状態です。内容が壊れている、時間内に届かない、あるいは全く届かない場合に発生します。
他のエラーとの違い
500はサーバー内部の問題を示します。503は一時的な停止（メンテナンスや過負荷）です。502は中継に対する“無効な応答”が原因だと考えてください。
発生時の影響
ユーザーはページを表示できません。APIならリクエストが失敗します。原因が切り分けにくく、フロント側・バックエンド両方を確認する必要があります。
AWSで502エラーが発生する主なケース
概要
AWS環境では、複数のサービスを組み合わせるために502 Bad Gatewayが起きやすくなります。ここでは代表的なケースを挙げ、具体的な原因と簡単な対処のヒントを示します。
1. CloudFront + ALB（またはALB + ELB）
- 症状: CloudFront経由でコンテンツ取得時に502が返る。
- 主な原因: ALBのターゲットが不健康、タイムアウト、ヘッダーサイズ超過。
- 対処例: ALBのヘルスチェックとタイムアウト設定を確認し、レスポンスタイムが長い場合はタイムアウト延長やバックエンド改善を行います。
2. ALB + EC2（アプリケーションサーバ）
- 症状: ALBが502を返す。EC2は起動しているが応答しない。
- 主な原因: アプリケーションクラッシュ、ポート未リッスン、プロセス過負荷。
- 対処例: EC2上のアプリログやプロセス状況を確認し、必要なら再起動やスケールアウトを行います。
3. API Gateway + Lambda / HTTPバックエンド
- 症状: API呼び出しで502が返る。
- 主な原因: Lambdaのタイムアウト、レスポンス形式の不一致、統合レスポンスの設定ミス。
- 対処例: Lambdaログ（CloudWatch）を確認し、ハンドラの例外やレスポンス形式を修正します。
4. ELB（Classic）やNLB経由
- 症状: バランサで502が発生する。
- 主な原因: セキュリティグループ、ネットワークACL、ヘルスチェックの失敗。
- 対処例: セキュリティグループとサブネット経路を確認し、ヘルスチェック設定を見直します。
5. ドメイン／SSL関連
- 症状: HTTPSアクセスで502やTLSエラーが発生する。
- 主な原因: 証明書の不整合、SNI設定ミス、ドメイン紐付けの誤り。
- 対処例: 証明書の有効期限とバインド先を確認し、CloudFrontやALBの証明書設定を合わせます。
各ケースではログ（ALBアクセスログ、CloudFrontログ、CloudWatch）をまず確認することをお勧めします。ログは原因特定を早めます。
502エラーの一般的な原因
502 Bad Gatewayが発生する一般的な原因を、分かりやすく項目ごとに説明します。原因ごとに簡単な確認方法と対策も付けています。
サーバーの過負荷
原因: 同時アクセスが増えCPUやメモリが枯渇すると応答できなくなります。例: バッチ処理とアクセスピークが重なる。
確認と対策: CPU・メモリ監視、プロセス数確認。短期的には再起動、長期的にはスケールアウトやキュー化を検討します。
バックエンドサーバーのダウン
原因: アプリやデータベースが落ちているとゲートウェイが応答を受け取れません。
確認と対策: ヘルスチェック、ログ確認、プロセスの再起動や自動復旧設定を行います。
タイムアウト設定のミス
原因: プロキシやロードバランサーのタイムアウトが短すぎると途中で切断します。
確認と対策: 設定値の確認、応答を早めるかタイムアウトを延長します。
プロキシ／ロードバランサー設定の誤り
原因: ルーティング先やポートが間違っていると正しいバックエンドに届きません。
確認と対策: ルール・ターゲットの設定を見直し、テストリクエストで動作確認します。
ネットワーク・ファイアウォールの誤設定
原因: セキュリティグループやACLで通信がブロックされると接続不能になります。
確認と対策: 該当ポートの許可状態を確認し、必要な通信を許可します。
DNS設定の誤り
原因: ドメインが正しいIPやロードバランサーに解決されないと接続先が違います。
確認と対策: nslookupやdigで名前解決を確認し、DNSレコードを修正します。
アプリケーションのバグやプラグイン問題
原因: 特定の処理や外部ライブラリで例外が発生すると正常応答できません。
確認と対策: アプリログや例外トレースを確認し、対象部分を修正や無効化します。
以上がよくある原因です。まずはログ、監視、ヘルスチェックを順に確認すると原因の特定が早くなります。
AWS特有の502エラー原因と対策
ALB/ELBのヘルスチェック失敗
ALBやELBはヘルスチェックで不健康と判定するとトラフィックを返さず502を返すことがあります。対策はヘルスチェックのパス・ステータスコード・間隔を見直すことです。例：/healthに200を返す軽いエンドポイントを用意します。
CloudFrontやリバースプロキシ経由のHost/SSL不整合
CloudFrontからオリジンに送るHostヘッダーやSNIが不一致だと502になります。証明書が合っているか、Origin設定のHostヘッダーを確認してください。自分で例を挙げると、カスタムドメインでOriginがデフォルトホストのままだと証明書エラーが起きます。
セキュリティグループ／ネットワークACLの制限
必要なポートがブロックされていると502が発生します。ALB→EC2やECSタスクの間で通信が許可されているか、アウトバウンドも含めて確認してください。簡単な対策は一時的に通信を許可して動作確認することです。
タイムアウト設定の問題
ALB、CloudFront、アプリのいずれかのタイムアウトが短いと途中で切れて502になります。各サービスのタイムアウト値を揃え、長い処理は非同期化することを検討してください。
アプリケーションサーバーのリソース不足やクラッシュ
メモリ不足やプロセスのクラッシュで応答できないと502になります。ログ、メトリクス（CPU、メモリ、スレッド数）を確認し、必要ならスケールアップや自動スケーリングを設定してください。
実践的なチェックリスト（短め）
- ヘルスチェックURLと期待コードを確認
- 証明書とHostヘッダーを照合
- セキュリティグループ／ACLの通信許可を確認
- タイムアウトを揃える／長時間処理を非同期化
- サーバーのリソース監視とスケール設定
以上を順に確認すると、AWS環境で発生する多くの502が解消できます。
502エラー発生時の調査・トラブルシューティング手順
準備
まず影響範囲を確認します。発生時刻、影響あるURL・ユーザー、再現手順をメモしておきます。ログのタイムスタンプと合わせると原因特定が速くなります。
1) サーバーリソースを確認
CPU・メモリ・ディスク使用率を確認します。例: top、free -m、df -h。負荷急上昇やスワップ多用があればプロセスを特定し止めます。
2) サーバーログを確認
Webサーバー（nginx/Apache）のエラーログ、アプリケーションログ、OSログを時刻順に追います。ALB/ELBのアクセスログやCloudFrontのログも確認します。
3) ネットワーク・セキュリティ設定の確認
セキュリティグループ、ネットワークACL、サーバーのファイアウォール（iptables/nft）で想定のポートやIPが塞がれていないか確認します。接続拒否やタイムアウトが出ていないかを見ます。
4) ALB/ELB・CloudFrontの設定を確認
Originドメイン、SSL証明書、ヘルスチェックのパスとタイムアウト、アイドルタイムアウト設定を確認します。ヘルスチェックが失敗していると502につながります。
5) アプリケーションの確認
例外・タイムアウト・依存サービス（DBや外部API）の障害を確認します。最近のデプロイやプラグイン追加が原因かもしれません。
6) 深堀り手順と対処例
・リアルタイム確認: tail -f でログを追う。
・再現時にcurlでヘッダとレスポンスを確認（–verbose）。
・必要ならパケットキャプチャ（tcpdump）で通信状況を調べます。
・緊急対応はターゲットを一時的に外す、旧バージョンへロールバック、スケールアウトです。
7) 記録と次の対応
発生時の調査結果、対応手順、再発防止案を記録し関係者へ報告します。ログ保存や監視アラートの見直しを行うと再発検知が早くなります。
502エラーの予防と再発防止策
負荷分散とオートスケーリング
トラフィックを複数のサーバーに分散すると、単一のバックエンド障害で502が起きにくくなります。AWSならALBやNLBとAuto Scalingを組み合わせ、正常なインスタンスにのみトラフィックを流す設計にします。
アプリケーションの健全性監視とアラート
ヘルスチェックを適切に設定し、応答時間やエラー率を監視します。例えば、HTTP 200以外やタイムアウトが続いたら即時アラートを上げ、運用チームが素早く対応できるようにします。
設定変更時の事前検証と段階的リリース
設定やデプロイはステージング環境で検証し、段階的に本番へロールアウトします。カナリアリリースやブルー／グリーンで問題の広がりを抑えます。
SSL証明書とDNS設定の定期点検
期限切れやミス設定で502になることがあります。証明書更新やDNSレコード（TTL含む）を定期的に確認し、自動更新を導入すると安心です。
トラフィック増加時のリソース計画
イベントやキャンペーン前に負荷予測を行い、インスタンス数やデータベース接続上限を事前に調整します。負荷試験で実際の挙動を確かめましょう。
運用手順とドキュメント化
障害時の切り分け手順を文書化し、エスカレーションルートを明確にします。定期的に手順を見直して、誰でも対応できる状態にしておくことが重要です。
定期的なテストと復旧訓練
障害対応のリハーサルを行い、監視やアラートの精度を検証します。実際に問題を再現して対応時間を短くする訓練を続けると再発防止に役立ちます。
まとめ
要点の振り返り
AWS環境での502 Bad Gatewayは、サーバー間通信の失敗、設定ミス、リソース不足が主な原因です。ロードバランサーやリバースプロキシとバックエンドの接続、タイムアウト、ヘルスチェックの結果、アプリケーションの例外をまず確認してください。
緊急対応のチェックリスト（短期）
- ELB/ALBのターゲットヘルスとログを確認
- バックエンド（EC2、ECS、Lambda）のログとプロセス状態を確認
- セキュリティグループやネットワークACLの通信許可を確認
- タイムアウト設定やプロセスの最大接続数を点検
- 一時的にトラフィックを切り替えて影響範囲を特定
再発防止（長期）
- CloudWatchで詳細な監視とアラートを設定
- ヘルスチェックを適切に調整し自動復旧を有効化
- オートスケーリングや負荷分散で冗長性を確保
- デプロイは段階的（ブルー/グリーン）で影響を小さくする
- インフラをコード化して設定ミスを防ぐ（CloudFormation/Terraform）
- 運用手順書（Runbook）と定期的な障害演習を用意
最後に
ログを丁寧に追い、原因の切り分けを段階的に進めることが迅速復旧の鍵です。短期対応でサービスを回復させつつ、監視・自動化・運用改善で再発を防いでください。
