Azure 502エラー(Bad Gateway)の原因と対策方法を解説！

Azure環境でWebアプリケーションやクラウドサービスを運用していると、502 Bad Gatewayエラーに遭遇することがあります。このエラーは、ゲートウェイやプロキシとして機能するサーバーがバックエンドから無効な応答を受け取った場合に発生し、ユーザーがサービスにアクセスできなくなる深刻な問題です。
502エラーはApplication Gateway、Front Door、App Serviceなど複数のサービスで発生し得るため、原因の特定と適切な対処が不可欠です。一時的なエラーで自然に解消されるケースもありますが、ヘルスプローブの設定不備やSSL証明書の不一致など、根本原因に対処しなければ繰り返し発生する可能性があります。

本記事では、Azure環境における502エラーの8つの発生原因とサービス別の対処法を解説します。4ステップのトラブルシューティング手順から予防のためのベストプラクティスまで、502エラーの発生を最小限に抑えるための実践的な知識を紹介します。

Azureの502エラー（Bad Gateway）とは

HTTP 502 Bad Gatewayは、ゲートウェイやリバースプロキシとして動作するサーバーが、上流（バックエンド）のサーバーから無効な応答を受け取った場合に返されるステータスコードです。Azure環境では、Application Gatewayがバックエンドプールのサーバーから正常な応答を得られないケースや、Front Doorがオリジンサーバーへの接続に失敗するケース、App Serviceのワーカープロセスがクラッシュするケースなど、さまざまな状況で発生します。

502エラーは同じ5xxエラーでも、504 Gateway Timeoutとは発生メカニズムが異なります。504はバックエンドからの「応答が遅い」ことが原因ですが、502はバックエンドからの「応答が無効」であることが原因です。つまり、502はバックエンドが何らかの応答を返しているもののその内容が不正である場合や、接続そのものが切断された場合に発生します。

以下の表は、Azure環境で発生する主要な5xxエラー4種を比較したものです。エラーコードごとの発生条件を把握することで、問題の切り分けが容易になります。

この比較から分かるのは、502と504はどちらもゲートウェイ経由で発生するエラーですが、502は「応答の内容」に問題があり、504は「応答の時間」に問題があるという点です。

さらに注目すべき点として、Application GatewayではSKUのバージョンによって502エラーの挙動が異なります。V1 SKUではリクエストタイムアウト（既定20秒）を超過した場合に502エラーを返しますが、V2 SKUでは同じ状況で別のバックエンドプールメンバーへの再試行を行い、それでも応答が得られない場合は504エラーを返します。V1 SKUは廃止が予定されているため、V2への移行計画を進めることが推奨されます。

Azure 502エラーの主な発生原因

Azure環境における502エラーの発生原因は多岐にわたります。以下では、サービス横断的に発生する共通の原因から、特定サービスに固有の原因まで、8つの主要な発生パターンを解説します。

バックエンドサーバーの障害または過負荷

バックエンドサーバーがオフラインになっている、またはトラフィックの急増によりリソースが枯渇してリクエストを処理できなくなると、502エラーが発生します。仮想マシンのCPU使用率が90%を超えた状態が続いたり、メモリが上限に達したりすると、サーバーは新しいリクエストに対して正常な応答を返せなくなります。

特にApplication Gatewayのバックエンドプールが空である場合や、バックエンドプール内のすべてのインスタンスが異常と判定されている場合は、ルーティング先が存在しないため必ず502エラーが発生します。バックエンドプールの構成をAzure PowerShellで確認し、ProvisioningStateがSucceededであること、BackendAddressesが空でないことを検証してください。

ヘルスプローブの設定不備

ヘルスプローブの設定不備は、本番環境における502エラーの最も一般的な原因の一つです。Application Gatewayは、バックエンドの正常性を定期的に確認するヘルスプローブを使用しており、プローブが失敗するとそのバックエンドインスタンスを異常とマークしてリクエストの転送を停止します。

以下の表は、Application Gatewayのデフォルトヘルスプローブの設定値を示しています。カスタムヘルスプローブを使用しない場合、これらの値が自動的に適用されます。

実務で特に問題になるのは、プローブパスの設定です。バックエンドアプリケーションに/healthエンドポイントが存在しないにもかかわらず、カスタムプローブで/healthを指定してしまうケースが頻発します。また、バックエンドがポート8080でHTTPを使用しているにもかかわらず、プローブがポート443のHTTPSで設定されている場合もプローブは必ず失敗します。プローブのプロトコルとポートが、BackendHttpSettingの設定と一致していることを確認してください。

NSG・UDR・カスタムDNSによるアクセスブロック

ネットワークセキュリティグループ（NSG）やユーザー定義ルート（UDR）、カスタムDNSの設定によってバックエンドへのアクセスがブロックされると、Application Gatewayインスタンスがバックエンドプールに到達できず、プローブ失敗から502エラーにつながります。

NSGはApplication Gatewayのサブネットとバックエンドが配置されたサブネットの両方に設定されている可能性があります。UDRについては、トラフィックがネットワーク仮想アプライアンスやExpressRoute/VPN経由で不必要にバックエンドから遠ざけられていないかを確認する必要があります。以下のPowerShellコマンドで、サブネットに関連付けられたNSGとルーティングの状態を確認できます。

$vnet = Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName
Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet

カスタムDNSサーバーが仮想ネットワークに設定されている場合は、そのDNSサーバーがバックエンドプールメンバーのFQDN（完全修飾ドメイン名）を正しく解決できるかも確認が必要です。

SSL/TLS証明書の不一致

End-to-End TLSを有効にしている環境では、バックエンドサーバーにインストールされたTLS証明書のDNS名が、HTTPホストヘッダーのホスト名と一致していない場合に502エラーが発生します。これはApplication Gatewayの「Upstream SSL certificate doesn't match」エラーとして知られています。

具体的には、BackendHttpSettingsでプロトコルをHTTPSに設定した場合、Application Gatewayとバックエンド間の通信はTLSで暗号化されます。このとき、バックエンドサーバーのTLS証明書のCommon Name（CN）またはSubject Alternative Name（SAN）が、ホストヘッダーで送信されるホスト名と一致しなければTLSネゴシエーションが失敗します。

証明書の期限切れも同様に502エラーの原因となります。Azure Key Vaultを利用した証明書の一元管理と自動更新を設定することで、期限切れによる障害を防止できます。自己署名証明書を使用する場合は、ルート証明書をApplication Gatewayにアップロードする必要がある点にも注意してください。

リクエストタイムアウト

Application Gatewayは、バックエンドからの応答を一定時間待機します。既定のリクエストタイムアウトは20秒で、この時間内にバックエンドが応答を返さない場合、V1 SKUでは502エラーが返されます。V2 SKUでは別のバックエンドメンバーへの再試行が行われ、それでも応答が得られなければ504エラーとなります。

リクエストタイムアウトはBackendHttpSettingで個別に設定可能で、1秒から86,400秒（24時間）の範囲で調整できます。バックエンドアプリケーションの処理時間に応じた適切な値を設定することが重要です。ただし、タイムアウトを不必要に長くすると、障害時のエラー検出が遅れるリスクがあるため、バランスの取れた設定が求められます。

Application GatewayのKeepAlive不整合

散発的に発生する502エラーの主な原因として、Application Gatewayとバックエンドサーバー間のHTTP KeepAliveタイムアウトの不整合があります。バックエンドサーバーがKeepAliveタイムアウトの期限切れによりTCP接続を閉じるタイミングと、Application Gatewayがその同じ接続で新しいリクエストを送信するタイミングが重なると、リクエストが破棄されて502エラーが発生します。

Application GatewayのKeepAliveタイムアウトはSKUごとに異なり、変更できません。

• V1 SKU
  バックエンド側120秒、クライアント側120秒
  
  

• V2 SKU
  バックエンド側60秒、クライアント側75秒
  
  

この問題を回避するには、バックエンドサーバーのKeepAliveタイムアウトをApplication Gatewayの値より長く設定します。V2 SKUの場合、バックエンドサーバーのKeepAliveTimeoutを90秒以上に設定することが推奨されます。バックエンドでKeepAliveを無効にする方法も有効ですが、パフォーマンスへの影響を考慮する必要があります。

App Serviceのアプリケーション障害

App Serviceでは、アプリケーション固有の問題が502エラーの主な原因となります。最も一般的なのはワーカープロセス（w3wp.exe）のクラッシュで、未処理の例外、スタックオーバーフロー、アクセス違反などによってプロセスが異常終了すると、処理中のリクエストが中断されて502エラーが返されます。

App Serviceのリクエストタイムアウトは230秒で、この値は変更できません。バックエンド処理が230秒を超える場合、App Serviceは502エラーを返します。長時間かかる処理については、バックグラウンドジョブやAzure Functionsを利用した非同期パターン（HTTP 202 Accepted）への移行を検討してください。

LinuxまたはカスタムコンテナでApp Serviceを運用している場合は、アプリケーションが待ち受けるポートにも注意が必要です。AzureはデフォルトでポートWEBSITES_PORT（規定値8080）にリクエストを転送するため、アプリケーションが異なるポートでリッスンしている場合はWEBSITES_PORT環境変数で正しいポートを指定する必要があります。

Front Doorのオリジン接続問題

Azure Front Doorでは、オリジンサーバーへの接続が確立できない場合や、オリジンからの応答が無効な場合に502エラーが発生します。代表的な原因として、オリジンサーバーのTLS証明書の期限切れがあり、Front DoorのエラーログにX-Azure-Externalerror: CertificateExpiredとして記録されます。

WAF（Web Application Firewall）がFront Doorに設定されている場合、WAFルールによるブロックが502エラーとして表示されることがあります。WAFログを確認し、どのルールがリクエストをブロックしているかを特定してください。また、プライベートオリジンへの接続にはFront Door Premiumのプライベートリンク機能が必要で、Standard SKUではパブリックアクセス可能なオリジンのみがサポートされます。

Azure 502エラーのサービス別対処法

502エラーの対処は、エラーが発生しているサービスによって手順が異なります。以下では、主要な3つのサービスごとの対処法を解説します。

Application Gatewayでの対処法

Application Gatewayで502エラーが発生した場合、まずAzure PortalのApplication Gatewayリソースから「バックエンド正常性」を確認します。すべてのバックエンドインスタンスが「異常」と表示されている場合、ヘルスプローブの設定を見直す必要があります。

対処の流れは以下のとおりです。

• バックエンドプールの確認
  バックエンドプールが空でないこと、IPアドレスまたはFQDNが正しいことを確認します。インフラストラクチャが再作成された環境では、IPアドレスが変更されているケースがあります
  
  

• ヘルスプローブの検証
  プローブのプロトコル・ポート・パスがバックエンドの実際の設定と一致しているか確認します。プローブパスが200 OKを返すことを、バックエンドサーバーに直接アクセスして検証してください
  
  

• NSGとUDRの確認
  Application GatewayサブネットのNSGで、バックエンドへの通信が許可されていることを確認します。以下のコマンドで有効なNSGルールとルートテーブルを確認できます

Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName nic1 -ResourceGroupName testrg
Get-AzEffectiveRouteTable -NetworkInterfaceName nic1 -ResourceGroupName testrg

• リクエストタイムアウトの調整
  バックエンドの処理時間に応じてBackendHttpSettingのリクエストタイムアウトを調整します。Azure CLIまたはPowerShellで設定変更が可能です
  
  

• SSL/TLS設定の検証
  End-to-End TLSが有効な場合、バックエンドサーバーの証明書のCN/SANがホストヘッダーと一致しているか確認します。自己署名証明書の場合はルート証明書がアップロードされているかも確認してください
  
  

Front Doorでの対処法

Front Doorの502エラーは、オリジンの正常性状態から調査を開始します。Azure Portalでオリジンの正常性を確認し、オリジンが応答しているかを検証してください。

• オリジン証明書の確認
  Front DoorはHTTPSでオリジンに接続するため、オリジンのTLS証明書が有効期限内であることを確認します。期限切れの証明書は即座に更新してください
  
  

• WAFルールの確認
  WAFが設定されている場合、WAFログでブロックされたリクエストを特定し、必要に応じてルールの除外設定を追加します
  
  

• オリジンドメインの検証
  Front Doorのオリジン設定でドメイン名が正しいことを確認します。古いドメイン名が設定されたままになっていないか、DNSの名前解決が正しく行われているかを検証してください
  
  

App Serviceでの対処法

App Serviceの502エラーは、Azure Portalの「問題の診断と解決」ブレードから調査を開始します。「可用性とパフォーマンス」セクションで、「Webアプリの再起動」と「アプリケーションのクラッシュ」の検出結果を確認してください。

• アプリケーションログの確認
  stdoutLogEnabledを有効にして、アプリケーションの起動ログとランタイムログを取得します。Kuduコンソール（高度なツール）からログファイルを直接確認できます
  
  

• リソースの確認とスケーリング
  CPU使用率やメモリ使用率が上限に近い場合は、App Serviceプランのスケールアップ（上位のプランへの変更）またはスケールアウト（インスタンス数の増加）を検討します
  
  

• ポート設定の確認（Linux/コンテナ）
  LinuxまたはカスタムコンテナのApp Serviceでは、WEBSITES_PORT環境変数がアプリケーションの実際のリッスンポートと一致しているか確認します
  
  

• 依存サービスの確認
  外部APIやデータベースなどの依存サービスが正常に応答しているか確認します。依存サービスの障害がアプリケーションのクラッシュを引き起こし、502エラーにつながるケースがあります
  
  

Azure 502エラーのトラブルシューティング手順

502エラーが発生した場合、以下の4ステップで体系的に原因を特定していきます。手順に沿って調査を進めることで、効率的に問題を切り分けられます。

Step 1 バックエンドヘルスの確認

最初に確認すべきは、バックエンドの正常性状態です。Azure Portalで対象のApplication GatewayまたはAzure Load Balancerのリソースを開き、「バックエンド正常性」を確認します。すべてのインスタンスが「異常」と表示されている場合、ヘルスプローブの設定不備やネットワーク接続の問題が疑われます。一部のインスタンスのみが異常の場合は、特定のサーバーの障害や設定の不整合が原因である可能性があります。

App Serviceの場合は「問題の診断と解決」ブレードの「Web App Restarted」と「Application Crashes」検出器で、プロセスのクラッシュや再起動の履歴を確認します。クラッシュのタイムラインとスタックトレースが表示されることがあり、根本原因の特定に役立ちます。

Step 2 診断ログの分析

次に、診断ログを有効化して詳細な情報を収集します。Application Gatewayのアクセスログには、各リクエストのバックエンド応答ステータス、応答時間、エラー情報が記録されます。502エラーが発生したリクエストのログを抽出し、バックエンドが応答を返しているか、どのような応答コードを返しているかを確認します。

App Serviceの場合は、stdoutLogEnabledを有効にしてアプリケーションログを取得するとともに、Kuduコンソールの「Process Explorer」でワーカープロセスの状態を確認します。Failed Request Tracing（FREB）を有効にすると、リクエスト処理のどの段階で問題が発生しているかを詳細に追跡できます。

Step 3 ネットワーク構成の検証

ログ分析でバックエンドへの接続が失敗していることが判明した場合、Azure Network Watcherを使用してネットワーク構成を検証します。IP フロー検証機能で、NSGルールがバックエンドへのトラフィックをブロックしていないかを確認できます。接続モニター機能では、Application Gatewayからバックエンドへの到達可能性をテストできます。

カスタムDNSが設定されている場合は、DNSサーバーがバックエンドプールメンバーのFQDNを正しく解決できるかも確認してください。DNS解決の失敗は、特にバックエンドプールにFQDNを使用している場合の一般的な障害原因です。

Step 4 サポートへの問い合わせ

上記の手順で問題が解決しない場合は、Microsoftサポートへの問い合わせを検討します。500 Internal Server Error（Application Gateway自体の内部障害）の場合は特に、Azureプラットフォーム側の問題である可能性があるため、サポートチケットの起票が推奨されます。問い合わせ時には、問題が発生した正確な日時、ゲートウェイのリソースID、クライアントのパブリックIPアドレスまたはVMリソースID、アクセスしたURL、受信したHTTP応答コードを記録して提供してください。Azureサポートプランの選択については、後述の料金比較セクションを参照してください。

Azure 502エラーを未然に防ぐベストプラクティス

502エラーの再発を防止するためには、事前の設計と監視体制の整備が不可欠です。以下では、実務で特に効果の高い4つの予防策を紹介します。

ヘルスプローブの適切な設計

ヘルスプローブは、バックエンドアプリケーションの正常性を正確に反映するように設計することが重要です。デフォルトの/パスではなく、アプリケーションの主要な依存関係（データベース接続、外部API接続など）もチェックする専用のヘルスチェックエンドポイントを実装してください。プローブのタイムアウトはバックエンドの通常の応答時間よりも十分に大きく設定し、一時的な遅延で誤って異常と判定されないようにします。

プローブが302リダイレクトを返す設定は避けてください。Application Gatewayのヘルスプローブは200 OKのみを正常な応答として扱うため、リダイレクト応答はプローブ失敗として処理されます。

Connection Drainingの有効化

Connection Drainingは、バックエンドプールからインスタンスを削除する際に、処理中のリクエストが完了するまで猶予時間を設ける機能です。この設定が無効な場合、スケールイン操作やデプロイ時にバックエンドインスタンスが即座に切り離され、処理中のリクエストが502エラーとなる可能性があります。

Connection Drainingのタイムアウトは、アプリケーションの最大処理時間に基づいて設定します。一般的には60秒から120秒の範囲が推奨されますが、長時間のリクエストを処理するアプリケーションではより長い値が必要です。

Auto-Healによる自動回復

App Serviceでは、Auto-Heal機能を使用して特定の条件（メモリ使用量の閾値超過、連続するHTTPエラー、リクエスト処理時間の超過など）に基づいてワーカープロセスを自動的にリサイクルできます。プロセスのリサイクルは、一時的な問題からの最も迅速な回復手段です。

Azure Monitorでアラートルールを設定し、502エラーの発生率が1%を超えた場合に通知を受けるようにすることも推奨されます。Microsoft Sentinelと組み合わせることで、セキュリティインシデントの兆候である異常な502エラーの急増も検知できます。

Application Insightsによるアプリケーション監視

Application Insightsを導入することで、アプリケーションの依存関係の障害、例外の発生、パフォーマンスの劣化を自動的に検知できます。依存関係の障害マップを活用すれば、どの外部サービスの障害が502エラーに直結しているかを視覚的に把握できます。

特にApp Serviceで稼働するアプリケーションでは、Application Insightsのスマート検出機能が異常な失敗率を自動的に検知してアラートを送信するため、502エラーの早期発見と対処に有効です。

Azure 502エラーの注意点と実務での落とし穴

これまで安定して稼働していたサービスが、ある日突然502エラーを返し始める——こうしたケースは珍しくありません。以下では、実務で特に見落としやすい4つの落とし穴を紹介します。

• 散発的502エラーの正体
  断続的に発生する502エラーの多くは、Application GatewayとバックエンドのKeepAliveタイムアウトの不整合が原因です。この問題は負荷が低い時間帯に特に発生しやすく、再現が困難なため原因特定に時間がかかるケースがあります。Application Gateway自体にはKeepAliveを無効にする設定がないため、バックエンド側での対処が必須です。V2 SKUの場合、バックエンドのKeepAliveTimeoutを90秒以上に設定することで解消されます
  
  

• SSL証明書のSAN不一致
  End-to-End TLSを有効にした環境で、ワイルドカード証明書を使用している場合でも、サブドメインの階層が異なると証明書の検証に失敗します。例えば*.contoso.comの証明書では、api.internal.contoso.comは保護されません。証明書のSAN（Subject Alternative Name）に必要なすべてのドメインが含まれていることを確認してください
  
  

• App Serviceの230秒ハードリミット
  App Serviceのリクエストタイムアウト230秒は変更できないため、長時間実行される処理（大量データの集計やレポート生成など）をそのまま同期リクエストで処理すると502エラーが避けられません。このような処理は、HTTP 202 Accepted応答で即座にレスポンスを返し、バックグラウンドで非同期に実行する設計に変更する必要があります
  
  

• V1 SKUの廃止に伴う移行リスク
  Application Gateway V1 SKUは廃止が予告されています。V1からV2への移行時には、502エラーの挙動が変わる点（V1では502だったタイムアウトエラーがV2では504になる）や、KeepAliveタイムアウトの値が変わる点（120秒から60秒へ）に注意が必要です。移行前にバックエンドのKeepAlive設定を見直し、V2のタイムアウト値に合わせた調整を行ってください
  
  

【無料DL】AI業務自動化ガイド（220P）

Microsoft環境でのAI活用を徹底解説

Microsoft環境でのAI業務自動化・AIエージェント活用の完全ガイドです。Azure OpenAI、AI Agent Hub、n8nを活用した業務効率化の実践方法を詳しく解説します。

▶ 無料でダウンロード

Azureサポートプランの料金比較

502エラーの調査でMicrosoftサポートへの問い合わせが必要になった場合、利用可能なサポートプランの選択が重要になります。以下の表は、2026年3月時点のAzureサポートプラン5種の比較です。

本番環境で502エラーが頻発している場合は、重大な障害に対して1時間以内の初回応答が保証されるStandard以上のプランが推奨されます。特に散発的な502エラーの調査にはパケットキャプチャの分析やApplication Gatewayの内部ログへのアクセスが必要になることがあり、Microsoftサポートの介入が有効なケースが多くあります。最新の料金や詳細については、Azureサポートプラン公式ページを確認してください。

まとめ

本記事では、Azure環境における502 Bad Gatewayエラーの発生原因と対処法を解説しました。502エラーはバックエンドの障害、ヘルスプローブの設定不備、NSG/UDRによるネットワークブロック、SSL証明書の不一致、KeepAliveタイムアウトの不整合、App Serviceのアプリケーション障害、Front Doorのオリジン接続問題など、多様な原因で発生します。

対処にあたっては、まずバックエンドヘルスの状態を確認し、次に診断ログの分析、ネットワーク構成の検証、アプリケーション診断と段階的に調査を進めることが効果的です。予防策としては、ヘルスプローブの適切な設計、Connection Drainingの有効化、Auto-Healの設定、Application Insightsによる監視が有効です。

まずはAzure PortalでApplication GatewayまたはApp Serviceのバックエンド正常性を確認し、異常なインスタンスがないかチェックしてみてください。散発的な502エラーに悩んでいる場合は、バックエンドサーバーのKeepAliveTimeoutの値がApplication GatewayのSKUに応じた推奨値（V2では90秒以上）を満たしているかを確認することをお勧めします。Azureの障害事例や可用性ゾーンの活用と合わせて、安定したサービス運用を実現してください。