アプリケーション ゲートウェイを構成すると、次のエラー メッセージが表示されます。

サーバー エラー: 502 - ゲートウェイまたはプロキシ サーバーとして動作する Web サーバーが無効な応答を受信しました。

これらの手順に従って、バックエンドプールが空であるかどうかを確認します:

  1. Azure Portal で、[すべてのリソース] を選択し、問題のあるアプリケーション ゲートウェイを選択します。

  2. [アプリケーション ゲートウェイ] ブレードで、[バックエンド プール]を選択します

  3. [ターゲット 値]を確認します。 値が 0 (ゼロ) の場合は、バックエンド プールが空であることを意味します。

バックエンド プールは空ですか?

バックエンド プールが空で、要求を転送するサーバーがない場合、アプリケーション ゲートウェイはクライアントに "HTTP 502" エラー メッセージを返します。

この問題を解決 するには、次の手順に従って バックエンド サーバーをバックエンド プールに追加します。

  1. Azure Portal で 、[すべてのリソース] を選択し、アプリケーション ゲートウェイを選択します。

  2. 左側のメニューで [バックエンド プール] を選択します。

  3. バックエンド プールを選択します。

  4. [ターゲット] で、バックエンド サーバーの種類を選択します。

    注: サーバーは、次のいずれかの種類になります。

    • IP Address/FQDN

    • 仮想マシン

    • 仮想マシン スケール セット

    • アプリ サービス

  5. 対象の仮想マシンまたはアプリ サービスを選択するか、IP アドレスまたは FQDN を入力します。

  6. [保存] を選択します。

問題は解決しましたか?

すべてのバックエンド サーバーが異常かどうかを確認します。

  1. すべてのリソースを選択し、アプリケーション ゲートウェイを選択します。

  2. [アプリケーション ゲートウェイ] ブレードで、[ルール] を選択します。 ルールによってリスナーに関連付けられている HTTP 設定バックエンド プールの値を識別します。

  3. [アプリケーション ゲートウェイ] ブレードで、[バックエンドの正常性] を選択します。

  4. 手順 2 で特定した HTTP設定とバックエンド プールの状態が [異常] であるかどうかを確認します。

  5. [詳細] フィールドに、表示される詳細なエラー メッセージを記録します。 これは、さらなるトラブルシューティングに使用されます。

     

すべてのバックエンド サーバーが異常ですか。

少なくとも 1 つのサーバーが正常な場合、リクエストのタイムアウトを増やしてから、問題が解決したかどうかを確認します。 これを行うには、次の手順を実行します。

  1. Azure Portal で、[すべてのリソース] を選択し、アプリケーション ゲートウェイを選択します。

  2. [アプリケーション ゲートウェイ] ブレードで、[HTTP 設定] を選択します。

  3. 作成した HTTP 設定を選択します。 [要求のタイムアウト (秒)] ボックスに、120 などの大きな値を入力します。 または、サーバーがすべての要求に対する応答を返すのにかかる秒数より大きい値を入力します。

  4. [保存] をクリックします。

注: サーバーの応答にかかる時間を確認するには、Access ログを確認します。 要求ごとに、timeTaken 値 (ミリ秒単位) は、アプリケーション ゲートウェイによって受信された最初のバイトからクライアントに送信される最後のバイトまでの要求の処理全体を示します。

アプリケーション ゲートウェイは、バックエンド プール サーバーに要求を転送するときに、応答の構成された期間を待機します。 この時間内にバックエンド サーバーからの応答がない場合、これはタイムアウトと見なされ、アプリケーション ゲートウェイは HTTP 502 エラーをクライアントに返します。 この場合は、HTTP 設定でタイムアウト値を増やすことを検討してください。

アクセス ログの例:

{"instanceId":"ApplicationGatewayRole_IN_1","clientIP":"13.83.18.255","clientPort":1984,"httpMethod":"GET","requestUri":"/","requestQuery":"X-AzureApplicationGateway-CACHE-HIT=0","userAgent":"-","httpStatus":502,"httpVersion":"HTTP/1.1","receivedBytes":45,"sentBytes":1646,"timeTaken":31020,"sslEnabled":"on","host":"www.consoto.com"}

リクエストのタイムアウトが timeTaken よりも大きい値に設定されていることを確認します。 ログを収集するには、診断ログを有効にして、ストレージ アカウントまたは Log Analytics にストリーミングする必要があります。 詳細については、 診断ログ を参照してください。


問題は解決しましたか?

基本的なルールとパスベースのルールの両方がある場合は、パスベースのルールが高い優先度に設定されていることを確認します。 ルールの優先度を変更するには、次の手順を実行します。

  1. Azure Portal で、[すべてのリソース] を選択し、[アプリケーション ゲートウェイ] を選択します。

  2. [アプリケーション ゲートウェイ] ブレードで、[ ルール] を選択します。

  3. マルチサイト リスナー ルールの上に一覧表示されている基本的な種類のルールがあるかどうかを確認します。 存在する場合は、基本型ルールを削除し、基本リスナーを持つルールを作成します。 新しいルールが一覧の一番下に配置されます。 この方法では、マルチサイト ルールに優先順位が付けられます。

今日では、ルールは作成順に処理されます。 これは、ポータル ならびに PowerShell および Microsoft Azure CLI のアプリケーション ゲートウェイ ルール構成に記載されている順序です。

ルールの一覧には、マルチサイト リスナーを使用するルールの上に記載されている基本的なリスナーを使用するルールがあります。 マルチサイト リスナーに記載されているホスト名のいずれかを使用してアプリケーション ゲートウェイにアクセスする場合、基本的なリスナーを持つルールは キャッチオールとして機能し、要求をインターセプトします。 このルールは、間違ったバックエンド プールまたは空のバックエンド プールに要求をルーティングする場合があります。

この問題を回避するには、基本リスナーを持つルールを一覧の一番下に移動して、マルチサイト リスナーを優先できるようにします。


問題は解決しましたか?

バックエンドの正常性状態で表示されている、次のいずれかのエラー メッセージを選択します。

カスタムプローブが設定されているかどうかを判断するには、次の手順を実行します。

  1. Azure Portal で、[すべてのリソース]を選択し、アプリケーション ゲートウェイを選択します。

  2. 左側のメニューで [HTTP 設定] を選択し、作成した HTTP 設定を選択します。

  3. [カスタム プローブを使用する] チェック ボックスがオンになっている場合は、カスタム プローブを使用しています。


アプリケーション ゲートウェイにカスタム プローブが構成されていますか。

問題のあるアプリケーション ゲートウェイで、[正常性プローブ] を選択します。 [バックエンドの正常性] セクションの [詳細] フィールドで受け取ったエラーに基づいて、カスタム プローブの設定を確認します。

Error

操作

サーバーに接続できません

TCP セッションを確立できませんでした。 [HTTP 設定] でポートを確認し、ポートでサーバーに接続できることを確認します。 また、ネットワーク セキュリティ グループまたはユーザー定義のルーティングがトラフィックに影響を与えているかどうかも確認します。

プローブ状況コードの不一致: 受領済み 401

バックエンド サーバーが認証を必要とするかどうかを確認します。 この時点では、アプリケーション ゲートウェイ プローブは認証用の資格情報を渡すことができません。 プローブ状況コードの "HTTP 401" を許可するか、サーバーが認証を必要としないパスにプローブします。

プローブ状況コードの不一致: 受付済 403

バックエンド サーバーでパスへのアクセスが許可されているかどうかを確認します。

プローブ状況コードの不一致: 受付済 404

バックエンド サーバーでホスト名のパスにアクセスできる場合は、そのパスを確認します。 ホスト名またはパス パラメーターをアクセス可能な値に変更します。

プローブ状況コードの不一致: 受付 405

サーバーが HTTP GET メソッドを許可しているかどうかを確認します。

カスタム プローブを使用していて HTTP エラーが発生している場合は、アプリケーション ゲートウェイがバックエンド サーバーのアクセス可能なパスをプローブできるようにプローブ設定を調整できます。 ホスト名、パス、受け入れ可能な状況コード、応答本文などのパラメーターの値を変更できます。

プローブの詳細については、[アプリケーション ゲートウェイ プローブの概要] をクリックしてください。


問題は解決しましたか?

サーバーがデフォルトのプローブ パラメーターにアクセス可能かどうかを確認します。

  • デフォルトのプローブは <protocol>://127.0.0.1:<port>/ にあり、ステータスコード 200-399 を受け入れます。

  • プロトコルとポートは、アプリケーション ゲートウェイ インスタンスの HTTP 設定セクションから継承されます。

  • localhost でサーバーにアクセスできない場合は、 適切なホスト名とプロトコルを使用してカスタム プローブを構成し、使用しているバックエンド HTTP 設定に関連付けます。

  • バックエンド サーバーが、許可する別の状態コード (401 など) を送信して応答する場合は、そのコードをプローブ一致条件に含めます。


問題は解決しましたか?

"バックエンド サーバー証明書をアプリケーション ゲートウェイでホワイトリストに登録する必要があります" SSL エラー メッセージが表示された場合は、次の手順を実行して問題を解決します。

  1. バックエンド プールで指定されているサーバーにアクセスします。 バックエンド プールで IP アドレスまたは FQDN が指定されている場合は、https://<ip-address>/ または https://<FQDN>/ を使用してサーバーにアクセスし、Web ブラウザーから証明書を確認します。

  2. [アプリケーション ゲートウェイ] ブレードに移動し、[HTTTP 設定] を選択して、同じ証明書がホワイトリスト登録用のアプリケーション ゲートウェイにアップロードされていることを確認します。 不一致が見つかる場合は、証明書の公開キーを 64 でエンコードされた基本 .cer ファイルにエクスポートし、同じキーを HTTP 設定にアップロードします。

    詳細については、「 Azure アプリケーション ゲートウェイを使用してバックエンドをホワイトリスト登録するための証明書を作成する」を参照してください。

注: バックエンド サーバーが SNI (サーバー名の表示) を持つるように構成されている場合は、バックエンド プールで FQDN を使用する必要があります。 これは、アプリケーション ゲートウェイ v1 SKU の場合、バックエンド サーバーのバインドと一致する必要があります。 これに対し、v2 SKU では、HTTP 設定の [ホスト名の上書き] セクションで SNI FQDN を構成できます。 それ以外の場合は、SNI をオフにしてフォールバック証明書を構成します。

HTTPS プローブを正常に実行するには、アプリケーション ゲートウェイでバックエンド サーバーの証明書のブロックを解除 (または "ホワイトリスト登録") する必要があります。 たとえば、サーバー証明書の公開キーを、基本 64 でエンコードされた .cer 形式の HTTP 設定にアップロードする必要があります。 アプリケーション ゲートウェイ v2 の場合は、バックエンド サーバー証明書のルート証明書を .cer 形式でアップロードする必要があります。 バックエンド サーバーが信頼された Azure サービスであるか、既知の CA によって署名されている場合は、ブロックを解除するために証明書をアップロードする必要はありません。

"バックエンド サーバー証明書をアプリケーション ゲートウェイでホワイトリストに登録する必要があります" というエラー メッセージが表示された場合は、アプリケーション ゲートウェイにアップロードされた証明書がバックエンド サーバーの証明書と一致しないことを意味します。


問題は解決しましたか?

HTTPS プローブ接続エラーが原因でプローブが失敗した場合は、以下の手順を実行します。

  1. [Azure ポータルのすべてのリソース] を選択し、アプリケーション ゲートウェイを選択します。

  2. [アプリケーション ゲートウェイ] ブレードで、[リスナーの場所] を選択します。

  3. アプリケーション ゲートウェイの SSL ポリシーを確認し、正しい TLS バージョンと暗号スイートが選択されていることを確認します。

  4. バックエンド サーバーが、接続で現在使用されている TLS バージョンと暗号スイートを識別して、同じ TLS バージョンと暗号スイートをサポートしていることを確認します。 これを行うには、Wireshark またはネットワーク モニタを使用してバックエンド サーバーでネットワーク パケット キャプチャを取得し、TLS クライアントパケットとサーバー Hello パケットを確認します。 例: 250 4.045574 10.171.40.80 40.126.18.38 TLSv1.2 268 Client Hello 254 4.075988 40.126.18.38 10.171.40.80 TLSv1.2 92 Server Hello, Certificate, Server Key Exchange, Server Hello Done

     

問題は解決しましたか?

おめでとうございます。 問題は解決しています。

問題が解決しない場合は、Azure サポートにお問い合 わせください。 

このガイドの内容

Azure アプリケーション ゲートウェイで発生する不適切なゲートウェイ (502) エラーのトラブルシューティングに役立ちます。

対象

アプリケーション ゲートウェイを使用して Web アプリケーションへのトラフィックを管理するシステム管理者。

内容

問題を特定し、解決策に到達するのに役立つチェックリストと一連の手順を示します。

推定完了時間:

15 ~ 30 分。

ヘルプを表示

スキルを磨く
トレーニングの探索
新機能を最初に入手
Microsoft Insider に参加する

この情報は役に立ちましたか?

翻訳品質にどの程度満足していますか?
どのような要因がお客様の操作性に影響しましたか?

フィードバックをお送りいただきありがとうございます!

×