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

[アーティクル]
05/19/2023

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 パス
Interval	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 設定で定義されているプロトコルが使用されます
Host	プローブを送信するホスト名。アプリケーションゲートウェイでマルチサイトを構成する場合にのみ適用可能です。これは VM ホスト名とは異なります。
Path	プローブの相対パス。パスは、先頭が '/' である必要があります。プローブは、<protocol>://<host>:<port><path> に送信されます。
Interval	プローブの間隔 (秒)。 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" である必要があります。

BackendAddressPoolsText:

[{
    "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 証明書の CNAME が、HTTP ホストヘッダー要求でバックエンドに送られるホスト名と一致していることを確認することが必須です。

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

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

次に例を示します。

ドメイン www.contoso.com の HTTP 要求を処理する Application Gateway があるとします。ドメイン contoso.com を Azure DNS パブリックゾーンに委任し、そのゾーンの DNS レコードで www.contoso.com を要求に対応する特定の Application Gateway のパブリック IP にポイントできます。

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

規則の "サポートされた HTTP 設定" で HTTPS を有効にすると、Application Gateway インスタンスとバックエンドのサーバー間で発生する通信の 2 番目の部分で TLS が使用されるようになることはご存知の通りです。

バックエンドサーバーが CNAME www.contoso.com または *.contoso.com に対して発行された TLS 証明書を持っていない場合、要求は、上流の SSL 証明書 (バックエンドサーバーにインストールされている証明書) がホストヘッダーのホスト名と一致せず、TLS ネゴシエーションが失敗するため、「サーバーエラー: 502 - Web サーバーがゲートウェイまたはプロキシサーバーとして動作しているときに、無効な応答を受信しました」と表示されて失敗します。

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

解決策

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

次のステップ

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