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

概要

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

注

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

Symptoms

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

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

原因

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

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

同様に、VNet にカスタム DNS が存在すると、問題が発生する可能性もあります。 VNet 用に構成された DNS サーバーで、バックエンドプールメンバーに使用される FQDN が正しく解決されない場合があります。

解決策

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

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

有効な NSG を確認し、バックエンド VM を使用してルーティングします。

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 に関連付けます。これらの各関連付けには既定のプローブが構成されており、Application Gateway は 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 ネットワークセキュリティグループが、構成されたポートでの着信または送信トラフィックをブロックしていないことを確認してください。
FQDN またはパブリック IP でクラシック VM または Azure クラウドサービスを使用する場合は、対応する endpoint を開きます。
Azure Resource Manager経由で VM を構成し、アプリケーションゲートウェイがデプロイされている VNet の外部にある場合は、目的のポートへのアクセスを許可するように Network セキュリティグループを構成する必要があります。

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

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

原因

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

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

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

解決策

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

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

ユーザーリクエストのタイムアウトや接続の問題

原因

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

解決策

この設定は BackendHttpSetting を使用して構成できます。これは、さまざまなプールに適用できます。バックエンドプールごとに、異なる BackendHttpSetting 構成と異なる要求タイムアウト設定を設定できます。

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

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

原因

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

解決策

インスタンスが正常であり、アプリケーションが正しく構成されていることを確認します。バックエンドインスタンスが同じ仮想ネットワーク内の別の 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パブリックゾーンに委任され、そのゾーン内の DNS レコードが、要求を処理する特定の Application Gateway のパブリック IP www.contoso.comを指している可能性があります。

その Application Gateway には、ホスト www.contoso.com のリスナーが必要であり、さらに、「Backed HTTP 設定」でプロトコルを HTTPS に強制し、エンドツーエンドの TLS を確保する規則が含まれている必要があります。この同じ規則により、IIS を実行する 2 つの VM を Web サーバーとして使用するバックエンドプールが構成されている可能性があります。

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

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

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

解決策

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

フィードバック

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

Last updated on 2026-03-27