502 Bad Gateway（不正なゲートウェイ）

症状

API 呼び出しのレスポンスで、クライアントアプリケーションが HTTP ステータスコード 502、「Bad Gateway」というメッセージを受け取ります。

HTTP ステータスコード 502 は、クライアントが、リクエストを実際に処理する必要があるバックエンドサーバーから有効なレスポンスを受信していないことを意味します。

エラーメッセージ

クライアントアプリケーションは、次のレスポンスコードを受け取ります。

    HTTP/1.1 502 Bad Gateway

さらに、次のエラーメッセージも確認できます。

    {
       "fault": {
          "faultstring": "Unexpected EOF at target",
          "detail": {
               "errorcode": "messaging.adaptors.http.UnexpectedEOFAtTarget"
           }
        }
    }

考えられる原因

502 Bad Gateway（不正なゲートウェイ）エラーの一般的な原因の 1 つは、次のような理由により発生する可能性がある [Unexpected EOF] エラーです。

原因	詳細	手順の対象
ターゲットサーバーが正しく構成されていない	ターゲットサーバーが、TLS / SSL 接続をサポートするように正しく構成されていません。	Edge Private Cloud と Public Cloud のユーザー
バックエンドサーバーからの EOFException	バックエンドサーバーが EOF を突然送信することがあります。	Edge Private Cloud ユーザーのみ

ターゲットサーバーが正しく構成されていない

ターゲットサーバーが、TLS / SSL 接続をサポートするように正しく構成されていません。

診断

Public Cloud ユーザーのみに適用される診断手順

API Monitoring では、問題領域を簡単に切り分けて、エラー、パフォーマンス、レイテンシの問題とその原因（デベロッパーアプリケーション、API プロキシ、バックエンドターゲット、API プラットフォームなど）を診断できます。

サンプルシナリオの説明に従い、API Monitoring を使用して API での 5xx 問題をトラブルシューティングしてください。たとえば、messaging.adaptors.http.UnexpectedEOFAtTarget エラーの数が特定のしきい値を超えた時点で、アラートを通知するよう設定することもできます。

Private Cloud と Public Cloud のユーザーに適用される診断手順

UI で、影響を受けた API のトレースを有効にします。
失敗した API リクエストのトレースで次のことが明らかになる場合があります。
1. ターゲットフローリクエストが開始されるとすぐに、502 Bad Gateway（不正なゲートウェイ）エラーが表示される。
2. error.class に messaging.adaptors.http.UnexpectedEOF が表示される。
  この場合、ターゲットサーバーの構成が正しくないことにより問題が発生した可能性が高いと思われます。

Edge 管理 API 呼び出しを使用してターゲットサーバー定義を取得します。

Public Cloud をご利用の場合は、次の API を使用します。

    curl -v https://api.enterprise.apigee.com/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

Private Cloud をご利用の場合は、次の API を使用します。

    curl -v http://<management-server-host>:<port #>/v1/organizations/<orgname>/environments/<envname>/targetservers/<targetservername> -u <username>

問題のあるターゲットサーバー定義の例:

    <TargetServer  name="target1">
      <Host>mocktarget.apigee.net</Host>
      <Port>443</Port>
      <IsEnabled>true</IsEnabled>
    </TargetServer >

示されたターゲットサーバー定義は、典型的な構成ミスの 1 つを示す例です。これについては以下で説明します。
ターゲットサーバー「mocktarget.apigee.net」がポート # 443 で保護された（HTTPS）接続を受け入れるように構成されていると仮定します。しかし、ターゲットサーバー定義を見ると、それが保護された接続用であることを示す他の属性 / フラグはありません。これにより、Edge は特定のターゲットサーバーに送信される API リクエストを HTTP（保護されていない）リクエストとして処理します。したがって、Edge はこのターゲットサーバーとの SSL Handshake プロセスを開始しません。

ターゲットサーバーは 443 で HTTPS（SSL）リクエストのみを受け入れるように構成されているため、このサーバーによって Edge からのリクエストが拒否されるか、接続が閉じられます。結果として、Message Processor で UnexpectedEOFAtTarget エラーが発生します。Message Processor から、クライアントにレスポンスとして「502 Bad Gateway」（不正なゲートウェイ）が送信されます。

解決策

常に、要件に応じてターゲットサーバーが正しく構成されるようにします。

上記の例では、保護された（HTTPS / SSL）ターゲットサーバーにリクエストを行う場合は、「enabled」フラグを true に設定して SSLInfo 属性を含める必要があります。ターゲットエンドポイント定義自体にターゲットサーバーの SSLInfo 属性を追加することは許可されていますが、混乱を避けるために SSLInfo 属性をターゲットサーバー定義の一部として追加することをおすすめします。

バックエンドサービスで一方向の SSL 通信が必要な場合は、次のようにします。

以下に示すように、「enabled」フラグを true に設定した SSLInfo 属性を含めることによって、ターゲットサーバー定義で TLS / SSL を有効にする必要があります。

    <TargetServer name="mocktarget">
      <Host>mocktarget.apigee.net</Host>
      <Port>443</Port>
      <IsEnabled>true</IsEnabled>
      <SSLInfo>
          <Enabled>true</Enabled>
      </SSLInfo>
    </TargetServer>

Edge でターゲットサーバーの証明書を検証する場合は、以下に示すように、トラストストア（ターゲットサーバーの証明書を含む）も含める必要があります。

    <TargetServer  name="mocktarget">
        <IsEnabled>true</IsEnabled>
        <Host>mocktarget.apigee.net</Host>
        <Port>443</Port>
        <SSLInfo>
            <Ciphers/>
            <ClientAuthEnabled>false</ClientAuthEnabled>
            <Enabled>true</Enabled>
            <IgnoreValidationErrors>false</IgnoreValidationErrors>
            <Protocols/>
            <TrustStore>mocktarget-truststore</TrustStore>
        </SSLInfo>
    </TargetServer>

バックエンドサービスで双方向の SSL 通信が必要な場合は、次のようにします。

以下に示すように、SSLInfo 属性に ClientAuthEnabled、Keystore、KeyAlias、Truststore のフラグが適切に設定されている必要があります。

    <TargetServer  name="mocktarget">

         <IsEnabled>true</IsEnabled>

         <Host>www.example.com</Host>

         <Port>443</Port>

         <SSLInfo>

             <Ciphers/>

             <ClientAuthEnabled>true</ClientAuthEnabled>

             <Enabled>true</Enabled>

             <IgnoreValidationErrors>false</IgnoreValidationErrors>

             <KeyAlias>keystore-alias</KeyAlias>

             <KeyStore>keystore-name</KeyStore>

             <Protocols/>

             <TrustStore>truststore-name</TrustStore>

         </SSLInfo>

      </TargetServer >

リファレンス

バックエンドサーバー間の負荷分散

バックエンドサーバーからの EOFException

バックエンドサーバーが EOF（ファイルの終わり）を突然送信することがあります。

診断

Public Cloud ユーザーのみに適用される診断手順

API Monitoring を使用して API での 5xx 問題をトラブルシューティングする方法を説明するサンプルシナリオに従ってください。たとえば、messaging.adaptors.http.UnexpectedEOFAtTarget エラーの数が特定のしきい値を超えた時点で、アラートを通知するよう設定することもできます。

Private Cloud ユーザーのみに適用される診断手順

Message Processor のログ（/opt/apigee/var/log/edge-message-processor/logs/system.log）を確認し、特定の API に対して「eof unexpected」が発生したかどうかを検索するか、API リクエストに一意の messageid があるかどうかを検索してから、それを検索できます。
Message Processor ログの例外スタックトレースの例
```
    "message": "org:myorg env:test api:api-v1 rev:10 messageid:rrt-1-14707-63403485-19 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onException() : SSLClientChannel[C:193.35.250.192:8443 Remote host:0.0.0.0:50100]@459069 useCount=6 bytesRead=0 bytesWritten=755 age=40107ms lastIO=12832ms .onExceptionRead exception: {}
    java.io.EOFException: eof unexpected
    at com.apigee.nio.channels.PatternInputChannel.doRead(PatternInputChannel.java:45) ~[nio-1.0.0.jar:na]
    at com.apigee.nio.channels.InputChannel.read(InputChannel.java:103) ~[nio-1.0.0.jar:na]
    at com.apigee.protocol.http.io.MessageReader.onRead(MessageReader.java:79) ~[http-1.0.0.jar:na]
    at com.apigee.nio.channels.DefaultNIOSupport$DefaultIOChannelHandler.onIO(NIOSupport.java:51) [nio-1.0.0.jar:na]
    at com.apigee.nio.handlers.NIOThread.run(NIOThread.java:123) [nio-1.0.0.jar:na]"
    
```
上の例では、「java.io.EOFException: eof unexpected」のエラーが、Message Processor がバックエンドサーバーからのレスポンスを読み取ろうとしているときに発生しました。この例外は、ファイルの終わり（EOF）か、予期せずストリームの終わりに達したことを示しています。

つまり、Message Processor は、API リクエストをバックエンドサーバーに送信し、レスポンスを待機していたか、読み取っていました。しかし、バックエンドサーバーは、Message Processor がレスポンスを受け取る前、または完全なレスポンスを読み取るまでに、突然接続を終了しました。
バックエンドサーバーのログを確認し、バックエンドサーバーの突然の接続終了を引き起こした可能性のあるエラーや情報がないかどうかを確認します。エラーや情報が見つかった場合は、「解決策」の手順に進み、バックエンドサーバーで問題を適切に修正します。
バックエンドサーバーでエラーや情報が見つからない場合は、Message Processor で tcpdump の出力を収集します。
1. バックエンドサーバーホストに単一の IP アドレスがある場合は、次のコマンドを使用します。
```
    tcpdump -i any -s 0 host <IP address> -w <File name>
    
```
2. バックエンドサーバーホストに複数の IP アドレスがある場合は、次のコマンドを使用します。
```
    tcpdump -i any -s 0 host <Hostname> -w <File name>
    
```
  注: Message Processor でこのコマンドを実行する場合は、バックエンドサーバーの IP アドレス / ホスト名を使用します。バックエンドサーバーで tcpdump を実行することもできます。バックエンドサーバーでコマンドを実行する場合は、上記の tcpdump コマンドで Message Processor の IP アドレスを使用します。
  
  通常、このエラーは、Message Processor がリクエストをバックエンドサーバーに送信するとすぐにバックエンドサーバーが [FIN,ACK] で応答することが原因で発生します。
以下の tcpdump の例を考えてみましょう。
502 Bad Gateway（不正なゲートウェイ）エラー（UnexpectedEOFAtTarget）が発生した場合に実行された tcpdump の例
TCPDump の出力から、次の一連のイベントに注目します。
1. Message Processor が API リクエストをバックエンドサーバーに送信します。
2. バックエンドサーバーがすぐに [FIN,ACK] で応答します。
3. これに続いて、Message Processor が [FIN,ACK] でバックエンドサーバーに応答します。
4. 最終的に双方から [ACK] と [RST] で接続が閉じられます。
5. バックエンドサーバーは [FIN,ACK] を送信するため、Message Processor で「java.io.EOFException: eof unexpected」の例外が発生します。
これは、バックエンドサーバーにネットワークの問題がある場合に発生します。この問題をさらに調査するために、ネットワーク運用チームに依頼してください。

解決策

バックエンドサーバーの問題を適切に修正します。

問題が引き続き発生し、502 Bad Gateway（不正なゲートウェイ）のエラーをトラブルシューティングするサポートが必要な場合、またはこれが Edge 内の問題であることが疑われる場合は、Apigee サポートにお問い合わせください。

502 Bad Gateway（不正なゲートウェイ）

症状

エラー メッセージ

考えられる原因

ターゲット サーバーが正しく構成されていない

診断

Public Cloud ユーザーのみに適用される診断手順

Private Cloud と Public Cloud のユーザーに適用される診断手順

解決策

リファレンス

バックエンド サーバーからの EOFException

診断

Public Cloud ユーザーのみに適用される診断手順

Private Cloud ユーザーのみに適用される診断手順

解決策

エラーメッセージ

ターゲットサーバーが正しく構成されていない

バックエンドサーバーからの EOFException