Application Gateway での無効なゲートウェイによるエラーのトラブルシューティング

2025-04-29

Azure Application Gateway の使用時に表示される無効なゲートウェイ (502) エラーをトラブルシューティングする方法について説明します。

注意

Azure を操作するには、Azure Az PowerShell モジュールを使用することをお勧めします。作業を始めるには、「Azure PowerShell をインストールする」を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。

概要

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

NSG、UDR、またはカスタム DNS が、バックエンドプールのメンバーへのアクセスをブロックしている。
バックエンド VM または仮想マシンスケールセットのインスタンスが既定の正常性プローブに応答しない。
カスタムの正常性プローブの構成が無効または不適切である。
Azure Application Gateway のバックエンドプールが構成されていないか、空である。
仮想マシンスケールセット内に正常な VM またはインスタンスがない。
ユーザー要求での要求のタイムアウトまたは接続の問題。

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

原因

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

NSG/UDR は、アプリケーションゲートウェイサブネットまたはアプリケーション VM がデプロイされているサブネットのいずれかに存在する可能性があります。

同様に、VNet にカスタム DNS が存在することが問題の原因になる場合があります。バックエンドプールメンバーに使用される FQDN が、VNet 用にユーザーが構成した DNS サーバーによって正しく解決されないことがあります。

解決策

次の手順によって、NSG、UDR、および DNS の構成を検証します。

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

VM バックエンドとの有効な NSG とルートをチェックします。

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

VNet 内のカスタム DNS の存在をチェックします。 DNS は、出力内の VNet プロパティの詳細を調べることでチェックできます。

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

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

既定の正常性プローブに関する問題

原因

既定の正常性プローブがバックエンド VM に到達できない場合にも、502 エラーがよく発生します。

アプリケーションゲートウェイインスタンスがプロビジョニングされると、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 以外のポートが指定されている場合、既定のサイトはポート 80 でリッスンするように構成する必要があります。
protocol://127.0.0.1:port の呼び出しで、HTTP 結果コード 200 が返されるようにする必要があります。このコードは、30 秒のタイムアウト期間内に返される必要があります。
構成されたポートが開いており、構成されたポート上の受信または送信トラフィックをブロックしているファイアウォール規則または Azure ネットワークセキュリティグループが存在しないことを確認します。
FQDN またはパブリック IP と共に Azure クラシック VM またはクラウドサービスを使用する場合、対応するエンドポイントを必ず開いてください。
Azure Resource Manager を介して VM を構成しており、アプリケーションゲートウェイがデプロイされた VNet の外側に VM がある場合、ネットワークセキュリティグループは、目的のポートにアクセスできるように構成する必要があります。

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

カスタムの正常性プローブに関する問題

原因

カスタムの正常性プローブを使用すれば、既定のプローブ動作の柔軟性を高めることができます。カスタムプローブを使用する場合、プローブの間隔、テスト対象の URL とパス、バックエンドプールインスタンスを異常とマークするまでの応答の失敗回数を構成できます。

次のプロパティが追加されます。

プローブのプロパティ	説明
名前	プローブの名前。この名前は、バックエンドの HTTP 設定でプローブを参照するために使用されます。
プロトコル	プローブを送信するために使用するプロトコル。プローブでは、バックエンドの HTTP 設定で定義されているプロトコルが使用されます
ホスト	プローブを送信するホスト名。アプリケーションゲートウェイでマルチサイトを構成する場合にのみ適用可能です。これは VM ホスト名とは異なります。
経路	プローブの相対パス。パスは、先頭が '/' である必要があります。プローブは、<protocol>://<host>:<port><path> に送信されます。
インターバル	プローブの間隔 (秒)。 2 つの連続するプローブの時間間隔。
タイムアウト	プローブのタイムアウト (秒)。このタイムアウト期間内に正常な応答が受信されなかった場合は、プローブが「失敗」とマークされます。
異常のしきい値	プローブの再試行回数。プローブの連続失敗回数が異常のしきい値に達すると、バックエンドサーバーは「ダウン」とマークされます。

解決策

カスタムの正常性プローブが前の表に示すとおりに正しく構成されていることを確認します。前のトラブルシューティングの手順を実行したうえで、次のことも必ず行ってください。

プローブがガイドのとおりに正しく指定されていることを確認する。
アプリケーションゲートウェイを単一のサイトで構成する場合、既定ではホスト名を 127.0.0.1 と指定する必要があります (カスタムプローブで構成する場合は除く)。
http://<host>:<port><path> の呼び出しで HTTP 結果コード 200 が返されることを確認する。
間隔、タイムアウト、異常のしきい値が許容される範囲内であることを確認する。
HTTPS プローブを使用する場合は、バックエンドサーバー自体にフォールバック証明書を構成して、バックエンドサーバーが SNI を必要としないようにしてください。

要求のタイムアウト

原因

アプリケーションゲートウェイは、ユーザー要求を受信すると、構成済みの規則をその要求に適用し、その要求をバックエンドプールインスタンスにルーティングします。 Application Gateway は一定時間バックエンドインスタンスからの応答を待ちます。この時間間隔は構成できます。既定では、この間隔は 20 秒です。 Application Gateway v1 では、アプリケーションゲートウェイがこの間隔の間にバックエンドアプリケーションから応答を受信しない場合、ユーザー要求で 502 エラーが発生します。 Application Gateway v2 では、アプリケーションゲートウェイがこの間隔でバックエンドアプリケーションから応答を受信しない場合、要求は 2 番目のバックエンドプールメンバーに対して試行されます。 2番目の要求が失敗した場合、ユーザー要求に 504 エラーが発生します。

解決策

Application Gateway では、ユーザーは BackendHttpSetting でこの設定を構成し、別のプールに適用できます。バックエンドプールごとに異なる BackendHttpSetting を構成できるため、異なる要求タイムアウトを構成できます。

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

空の BackendAddressPool

原因

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

解決策

バックエンドアドレスプールが空ではないことを確認してください。これには、PowerShell、CLI、ポータルのいずれかを使用できます。

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 のすべてのインスタンスが異常である場合、アプリケーションゲートウェイにユーザー要求のルーティング先となるバックエンドがありません。これは、バックエンドインスタンスは正常であるものの、必要なアプリケーションがデプロイされていない場合に発生することもあります。

解決策

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

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

原因

バックエンドサーバーにインストールされている TLS 証明書が、Host 要求ヘッダーで受信したホスト名と一致しません。

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

注意として、HTTP ではなくプロトコル HTTPS のオプションである "バックエンド HTTP 設定" で有効にした場合の影響は、Application Gateway のインスタンスとバックエンドサーバーの間で発生する通信の 2 番目の部分が TLS で暗号化されていることです。

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

次に例を示します。

ドメイン www.contoso.comの https 要求を処理する Application Gateway があるとします。ドメイン contoso.com を Azure DNS パブリックゾーンに委任し、そのゾーン内の A レコードを特定の要求を処理するアプリケーションゲートウェイのパブリック IP にwww.contoso.com指すように設定できます。

その Application Gateway では、ホスト www.contoso.com のリスナーと、プロトコル HTTPS を強制的に使用する "バックエンド HTTP 設定"（エンドツーエンド TLS を確保する）を持つルールが必要です。同じ規則で、Web サーバーとして IIS を実行する 2 つの VM を使用してバックエンドプールを構成できました。

規則の "サポートされる HTTP 設定" で HTTPS を有効にするとわかっているとおり、Application Gateway インスタンスとバックエンド内のサーバーの間で発生する通信の第 2 の部分で TLS が使用されます。

バックエンドサーバーに DNS 名 www.contoso.com または *.contoso.com に対して発行された TLS 証明書がない場合、サーバー エラー 502 - Web サーバーがゲートウェイまたはプロキシサーバーとして機能しているときに無効な応答を受け取りました 。これは、アップストリーム SSL 証明書 (バックエンドサーバーにインストールされている証明書) がホストヘッダー内のホスト名と一致しないためです。そのため、TLS ネゴシエーションは失敗します。

www.contoso.com --> APP GW フロントエンド IP --> "バックエンド HTTP 設定" でプロトコルとしてHTTPではなくHTTPSを使用するように構成したルールを持つリスナー --> バックエンドプール --> Web サーバー (www.contoso.com用にTLS証明書がインストールされている必要があります)

解決策

バックエンドサーバーにインストールされている TLS 証明書の DNS 名が、HTTP バックエンド設定で構成されているホスト名と一致する必要があります。それ以外の場合は、Application Gateway とバックエンドのインスタンス間で発生するエンドツーエンド通信の 2 番目の部分が "Upstream SSL 証明書が一致しない" で失敗し、サーバーエラーがスローされます。 502 - Web サーバーがゲートウェイまたはプロキシサーバーとして機能しているときに無効な応答を受信しました

次のステップ

前の手順で問題を解決できない場合は、サポートチケットを開きます。