Azure Application Gatewayでの無効なゲートウェイ (502) エラーのトラブルシューティング

概要

Web アプリへの信頼性の高いアクセスをすばやく復元できるように、Azure Application Gatewayで無効なゲートウェイ (502) エラーのトラブルシューティングを行う方法について説明します。

注

Azure Az PowerShell モジュールを使用して Azure と対話します。作業を開始するには、「Install Azure PowerShellを参照してください。 Az PowerShell モジュールに移行する方法については、「AzRM から Azを参照してください。

Symptoms

アプリケーションゲートウェイを構成すると、"サーバーエラー: 502 - Web サーバーがゲートウェイまたはプロキシサーバーとして機能しているときに無効な応答を受信しました" というエラーが表示されることがあります。このエラーは、次の理由で発生する可能性があります。

ネットワークセキュリティグループ (NSG)、ユーザー定義ルート (UDR)、またはカスタムドメインネームシステム (DNS) の問題
既定の正常性プローブがバックエンド VM に到達できない
バックエンド要求のタイムアウトを超えました
Application Gateway のバックエンドプールが構成されていないか、空です
BackendAddressPool の異常なインスタンス
アップストリーム SSL 証明書が一致しない

ネットワークセキュリティグループ、ユーザー定義ルート、またはカスタム DNS の問題

原因

NSG、UDR、またはカスタム DNS がバックエンドへのアクセスをブロックしている場合、アプリケーションゲートウェイインスタンスはバックエンドプールに到達できません。この問題によりプローブエラーが発生し、502 エラーが発生します。

アプリケーションゲートウェイサブネットまたはアプリケーション仮想マシン (VM) がデプロイされているサブネットのいずれかに NSG または UDR がある場合があります。

同様に、仮想ネットワーク (VNet) にカスタム DNS が存在すると、問題が発生する可能性もあります。 VNet のユーザー構成 DNS サーバーが、バックエンドプールメンバーに使用される完全修飾ドメイン名 (FQDN) を正しく解決できない場合があります。

解決策

NSG、UDR、DNS の構成を検証します。そのためには、次の手順に従います。

アプリケーションゲートウェイサブネットに関連付けられている NSG を確認します。バックエンドへの通信がブロックされていないことを確認します。詳細については、「ネットワークセキュリティグループ」を参照してください。
アプリケーションゲートウェイサブネットに関連付けられている UDR を確認します。 UDR がバックエンドサブネットからトラフィックを転送していないことを確認します。たとえば、Azure ExpressRoute または Azure VPN を使用して、アプリケーションゲートウェイサブネットにアドバタイズされている既定のルート、またはネットワーク仮想アプライアンスへのルーティングがあるかどうかを確認してください。 Azure PowerShellで次のコマンドを実行します。
```
$vnet = Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName
Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
```

バックエンド VM で有効な NSG とルートを確認します。 Azure PowerShellで次のコマンドを実行します。

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

VNet にカスタム DNS が存在するかどうかを確認します。出力内の VNet プロパティの詳細を確認して、DNS を確認します。

Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName 
DhcpOptions            : {
                           "DnsServers": [
                             "x.x.x.x"
                           ]
                         }

存在する場合は、DNS サーバーがバックエンドプールメンバーの FQDN を正しく解決できることを確認します。

既定の正常性プローブがバックエンド VM に到達できない

原因

502 エラーは、既定の正常性プローブがバックエンド VM に到達できないことを示す場合もあります。

アプリケーションゲートウェイインスタンスをプロビジョニングすると、BackendHttpSettingのプロパティを使用して、各BackendAddressPoolに既定の正常性プローブが自動的に構成されます。

このプローブを設定するために入力を指定する必要はありません。具体的には、負荷分散規則を構成するときに、 BackendHttpSetting を BackendAddressPoolに関連付けます。これらの各関連付けには既定のプローブが構成されており、アプリケーションゲートウェイは、BackendHttpSetting要素で指定されたポートでBackendAddressPool内の各インスタンスへの定期的な正常性チェック接続を開始します。

次の表に、既定の正常性プローブに関連付けられている値を示します。

プローブのプロパティ	価値	[説明]
プローブの URL	`http://127.0.0.1/`	URL のパス
インターバル	30	プローブ間隔 (秒単位)
タイムアウト	30	プローブのタイムアウト (秒単位)
健康に害を与えるしきい値	3	プローブの再試行回数。プローブの連続失敗回数が異常のしきい値に達すると、バックエンドサーバーは「ダウン」とマークされます。

解決策

次のガイダンスを使用して、既定の正常性プローブのトラブルシューティングを行います。

要求のホスト値は 127.0.0.1 に設定されます。既定のサイトが構成され、127.0.0.1 でリッスンしていることを確認します。
BackendHttpSetting プロトコルは、要求のプロトコルを決定します。
URI パスは /* に設定されます。
BackendHttpSettingが 80 以外のポートを指定する場合は、そのポートでリッスンするように既定のサイトを構成します。
protocol://127.0.0.1:portの呼び出しは、HTTP 結果コード 200 を返す必要があります。このコードは、30 秒のタイムアウト期間内に返されます。
設定されたポートが開放されており、そのポートでの受信または送信トラフィックをブロックするファイアウォール規則や Azure NSG が存在しないことを確認してください。
FQDN またはパブリック IP でクラシック VM または Azure クラウドサービスを使用する場合は、対応する endpoint を開きます。
Azure Resource Manager (ARM) を使用して VM を構成し、アプリケーションゲートウェイがデプロイされている VNet の外部にある場合は、目的のポートへのアクセスを許可するように NSG を構成します。

詳細については、「Application Gateway インフラストラクチャの構成」を参照してください。

カスタム正常性プローブの構成が無効または不適切である

原因

カスタム正常性プローブを使用すると、既定のプローブ動作よりも柔軟性が高くなります。カスタムプローブを使用する場合は、プローブの間隔、URL、テストするパス、バックエンドプールインスタンスを異常としてマークする前に受け入れる失敗した応答の数を設定できます。

次の表では、設定できる追加のプロパティについて説明します。

プローブのプロパティ	[説明]
氏名	プローブの名前。バックエンド HTTP 設定でプローブを参照するには、この名前を使用します。
プロトコル	プローブを送信するために使用するプロトコル。プローブは、バックエンド HTTP 設定で定義されているプロトコルを使用します。
ホスト	プローブの送信先のホスト名。このホスト名は、VM ホスト名とは異なります。 v1 SKU では、Application Gateway はこの値をプローブ要求のホストヘッダーとしてのみ使用します。 v2 SKU では、ホストヘッダーとサーバー名表示 (SNI) 値の両方として値が使用されます。
経路	プローブの相対パス。有効なパスは '/' から始まります。プローブは、 <protocol>://<host>:<port><path> に送信されます。
インターバル	プローブの間隔 (秒)。この値は、2 つの連続するプローブ間の時間間隔を設定します。
タイムアウト	プローブのタイムアウトの時間（秒単位）。このタイムアウト期間内に有効な応答が受信されない場合、プローブは失敗としてマークされます。
健康に害を与えるしきい値	プローブの再試行回数。プローブの連続失敗回数が異常のしきい値に達すると、バックエンドサーバーは「ダウン」とマークされます。

解決策

前の表に示すように、カスタム正常性プローブを正しく構成したことを確認します。上記のトラブルシューティングガイダンスに加えて、このガイダンスにも従ってください。

ガイドに従ってプローブを正しく指定してください。
1 つのサイトに対してアプリケーションゲートウェイを構成する場合は、カスタムプローブで構成しない限り、既定のホスト名を 127.0.0.1として指定します。
http://<host>:<port><path>の呼び出しで HTTP 結果コード 200 が返されることを確認します。
Interval、Timeout、およびUnhealthyThresholdの値が許容範囲内にあることを確認します。
v2 SKU で HTTPS プローブを使用する場合、Application Gateway はプローブホスト名も SNI 値として送信します。 RFC 6125 で説明されているように、ホスト名がバックエンド証明書のサブジェクトの別名 (SAN) または共通名 (CN) と一致していることを確認します (証明書に SAN がない場合)。ホスト名が IP アドレス (既定の 127.0.0.1を含む) の場合、Application Gateway は SNI を送信しません。プローブホスト名と証明書を比較する手順については、「Azure Application Gatewayでの HTTP 502 エラーのトラブルシューティング」の解決策 F を参照してください。バックエンド証明書を変更できない場合は、バックエンドの HTTPS 検証設定を調整して、特定の SNI 値を使用するか、サブジェクト名の検証をスキップします。

バックエンド要求のタイムアウトを超えました

原因

アプリケーションゲートウェイは、ユーザー要求を受信すると、構成された規則を要求に適用し、バックエンドプールインスタンスにルーティングします。バックエンドインスタンスからの応答の構成可能な間隔を待機します。既定では、この間隔は 20 秒です。 Application Gateway v1 では、アプリケーションゲートウェイがこの期間内にバックエンドアプリケーションから応答を受信しない場合、ユーザー要求は 502 エラーを受け取ります。 Application Gateway v2 では、アプリケーションゲートウェイがこの期間内にバックエンドアプリケーションから応答を受信しない場合、要求は 2 番目のバックエンドプールメンバーに対して試行されます。 2 番目の要求も失敗した場合、ユーザー要求は代わりに 504 エラーを受け取ります。ユーザーが 502 エラーではなく 504 エラーを受け取る場合は、Azure Application Gatewayでの HTTP 504 エラーのトラブルシューティングを参照してください。

バックエンドアプリケーションが応答するために構成された間隔 (実行時間の長いクエリやレポートなど) よりも定期的に時間がかかる場合は、そのバックエンドプールで使用されるバックエンド HTTP 設定の要求タイムアウトを増やします。

解決策

要求タイムアウトはバックエンド HTTP 設定のプロパティであるため、異なるバックエンドプールに異なる要求タイムアウト値を設定できます。 Azure ポータル、Azure CLI、またはAzure PowerShellを使用して増やします。許容される範囲は 1 ~ 86400 秒です。詳細については、「要求のタイムアウト」を参照してください。

Azure portal

次の手順に従います。

Azure ポータルで、アプリケーションゲートウェイに移動します。
[ 設定] で、[ バックエンド設定] を選択します。
影響を受けるバックエンドプールで使用されるバックエンド設定を選択します。
要求 のタイムアウト (秒) の値を増やして、バックエンドが応答する時間を増やします。
保存を選びます。

Azure CLI

Azure CLI で、次のコマンドを実行します。

az network application-gateway http-settings update \
  --gateway-name <application-gateway-name> \
  --resource-group <resource-group-name> \
  --name <backend-http-settings-name> \
  --timeout <time-out-in-seconds>

Azure PowerShell

Azure PowerShellで次のコマンドを実行します。

New-AzApplicationGatewayBackendHttpSettings -Name 'Setting01' -Port 80 -Protocol Http -CookieBasedAffinity Enabled -RequestTimeout 60

注

要求のタイムアウトを増やすと、CPU またはメモリの負荷の高さ、データベースの競合、非効率的なクエリなど、基になる問題が原因でバックエンドが遅い場合にのみ症状がマスクされます。タイムアウト値を上げる前に、バックエンドアプリケーションの応答時間も調査します。

Application Gateway のバックエンドプールが構成されていないか、空です

原因

アプリケーションゲートウェイがバックエンドアドレスプールに構成されている VM または仮想マシンスケールセットがない場合、顧客の要求をルーティングして、無効なゲートウェイエラーを送信することはできません。

解決策

バックエンドアドレスプールが空でないことを確認します。この条件は、Azure PowerShell、Azure CLI、またはポータルで確認できます。 Azure PowerShellを使用してバックエンドアドレスプールを確認するには、次の例を参照してください。

Get-AzApplicationGateway -Name "SampleGateway" -ResourceGroupName "ExampleResourceGroup"

前のコマンドレットからの出力には、空でないバックエンドアドレスプールが含まれている必要があります。次の例は、バックエンド VM の FQDN または IP アドレスで構成された 2 つの返されたプールを示しています。 BackendAddressPoolのプロビジョニング状態はSucceededする必要があります。

[{
    "BackendAddresses": [{
        "ipAddress": "10.0.0.10",
        "ipAddress": "10.0.0.11"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool01",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool01"
}, {
    "BackendAddresses": [{
        "Fqdn": "xyx.cloudapp.net",
        "Fqdn": "abc.cloudapp.net"
    }],
    "BackendIpConfigurations": [],
    "ProvisioningState": "Succeeded",
    "Name": "Pool02",
    "Etag": "W/\"00000000-0000-0000-0000-000000000000\"",
    "Id": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Network/applicationGateways/<application gateway name>/backendAddressPools/pool02"
}]

BackendAddressPool の異常なインスタンス

原因

BackendAddressPoolのすべてのインスタンスが異常な場合、アプリケーションゲートウェイには、ユーザー要求をルーティングするバックエンドがありません。この状態は、バックエンドインスタンスが正常であるが、必要なアプリケーションがデプロイされていない場合にも発生する可能性があります。

解決策

インスタンスが正常であり、アプリケーションが正しく構成されていることを確認します。バックエンドインスタンスが同じ仮想ネットワーク内の別の VM からの ping に応答できるかどうかを確認します。パブリックエンドポイントを構成する場合は、Web アプリケーションに対するブラウザー要求がサービス可能であることを確認します。

アップストリーム SSL 証明書が一致しない

原因

バックエンドサーバーにインストールされているトランスポート層セキュリティ (TLS) 証明書が、HTTP ホスト要求ヘッダーで受信したホスト名と一致しません。

エンドツーエンド TLS が有効になっているシナリオでは、適切な バックエンド HTTP 設定を編集して構成を実現します。必要に応じて、 バックエンドプロトコル 設定の構成を HTTPS に変更します。バックエンドサーバーにインストールされている TLS 証明書の DNS NAME が、HTTP ホストヘッダー要求でバックエンドに送信されるホスト名と一致していることを確認します。

この手順を完了すると、Application Gateway とバックエンドサーバーで行われる通信の 2 番目の部分は TLS で暗号化されます。

既定では、Application Gateway は、クライアントから受信したのと同じ HTTP ホストヘッダーをバックエンドに送信します。バックエンドサーバーにインストールされている TLS 証明書が、HTTP ホストヘッダーでバックエンドサーバーによって受信されたホスト名と一致する DNS NAME で発行されていることを確認します。このホスト名は、クライアントから受信したホスト名と同じである必要があります。

解決策

プローブホスト名と SNI を証明書の SAN または CN に合わせる手順については、「Azure Application Gatewayでの HTTP 502 エラーのトラブルシューティング」の解決策 F を参照してください。 バックエンドターゲットからホスト名を選択および特定のドメイン名でオーバーライドの各バックエンド設定が、Application Gateway で想定される証明書名にどのように対応するかについては、「共通名 (CN) が一致しない」を参照してください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-09-02