次の方法で共有


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

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

注意

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

概要

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

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

原因

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

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

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

解決策

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

  1. アプリケーション ゲートウェイ サブネットに関連付けられている NSG をチェックします。 バックエンドとの通信がブロックされていないことを確認します。 詳細については、「ネットワーク セキュリティ グループ」を参照してください。

  2. アプリケーション ゲートウェイ サブネットに関連付けられている UDR をチェックします。 UDR がトラフィックをバックエンド サブネットから離れるように方向付けていないことを確認します。 たとえば、ネットワーク仮想アプライアンスへのルーティングや、ExpressRoute/VPN 経由でアプリケーション ゲートウェイ サブネットにアドバタイズされる既定のルートをチェックします。

    $vnet = Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName
    Get-AzVirtualNetworkSubnetConfig -Name appGwSubnet -VirtualNetwork $vnet
    
  3. VM バックエンドとの有効な NSG と ルートをチェックします。

    Get-AzEffectiveNetworkSecurityGroup -NetworkInterfaceName nic1 -ResourceGroupName testrg
    Get-AzEffectiveRouteTable -NetworkInterfaceName nic1 -ResourceGroupName testrg
    
  4. VNet 内のカスタム DNS の存在をチェックします。 DNS は、出力内の VNet プロパティの詳細を調べることでチェックできます。

    Get-AzVirtualNetwork -Name vnetName -ResourceGroupName rgName 
    DhcpOptions            : {
                               "DnsServers": [
                                 "x.x.x.x"
                               ]
                             }
    
  5. 存在する場合は、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 サーバーがゲートウェイまたはプロキシ サーバーとして動作しているときに、無効な応答を受信しました」がスローされます

次のステップ

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