トラブルシューティング ツール: Azure アプリケーション ゲートウェイで無効なゲートウェイ (502) エラー

適用対象: Virtual Network

このガイドの内容

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

対象

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

内容

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

推定完了時間:

15 ~ 30 分。

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

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

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

  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 値 (ミリ秒単位) は、アプリケーション ゲートウェイによって受信された最初のバイトからクライアントに送信される最後のバイトまでの要求の処理全体を示します。


問題は解決しましたか?

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

  1. Azure Portal で、[すべてのリソース] を選択し、[アプリケーション ゲートウェイ] を選択します。
  2. [アプリケーション ゲートウェイ] ブレードで、[ ルール] を選択します。
  3. マルチサイト リスナー ルールの上に一覧表示されている基本的な種類のルールがあるかどうかを確認します。 存在する場合は、基本型ルールを削除し、基本リスナーを持つルールを作成します。 新しいルールが一覧の一番下に配置されます。 この方法では、マルチサイト ルールに優先順位が付けられます。

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

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

  1. Azure Portal で、[すべてのリソース]を選択し、アプリケーション ゲートウェイを選択します。
  2. 左側のメニューで [HTTP 設定] を選択し、作成した HTTP 設定を選択します。
  3. [カスタム プローブを使用する] チェック ボックスがオンになっている場合は、カスタム プローブを使用しています。

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

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

Error

操作

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

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

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

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

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

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

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

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

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

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


問題は解決しましたか?

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

  • デフォルトのプローブは <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 プローブ接続エラーが原因でプローブが失敗した場合は、以下の手順を実行します。

  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 Hello254	4.075988	40.126.18.38	10.171.40.80	TLSv1.2	92	Server Hello, Certificate, Server Key Exchange, Server Hello Done

     

問題は解決しましたか?

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

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